Mounted games not showing

Just a quick question;

This could be done with the E3?

And if it was bricked, we could revive it using a E3?
 
@Joonie , you say not to install the update via the xmb or the recovery menu? how do I install the update?

I already told you what to do.

Once you're on FSM while 3.55, it will read lv2diag.self from USB and will install the pup named PS3UPDAT.PUP on the root of USB.

Lv2diag.self is lv2 for diagnosis


Sent from my iPhone using Tapatalk
 
I would like to ask about one syscalls related conversation as we already talk about cobra cfw and wmm. Is this a bug or such a feature?
Because not where I did not find it in the descriptions

in WMM
on Ferrox 4.82 Cobra 7.55 v1.01
syscalls off - CFW is off and homebrew dont work(with an error message).
syscalls on - CFW on all homebrew are working and we do not hide.
but on @habib 4.81 COBRA 7.50 v1.02
syscalls off - homebrew are working
syscalls on - homebrew are working



 
I would like to ask about one syscalls related conversation as we already talk about cobra cfw and wmm. Is this a bug or such a feature?
Because not where I did not find it in the descriptions

in WMM
on Ferrox 4.82 Cobra 7.55 v1.01
syscalls off - CFW is off and homebrew dont work(with an error message).
syscalls on - CFW on all homebrew are working and we do not hide.
but on @habib 4.81 COBRA 7.50 v1.02
syscalls off - homebrew are working
syscalls on - homebrew are working



I believe one of the later cobra versions prevents homebrew while signed in. that sounds like a bug though. you might ask @Alexander . he's the author of ferrox.
 
I would like to ask about one syscalls related conversation as we already talk about cobra cfw and wmm. Is this a bug or such a feature?
Because not where I did not find it in the descriptions

in WMM
on Ferrox 4.82 Cobra 7.55 v1.01
syscalls off - CFW is off and homebrew dont work(with an error message).
syscalls on - CFW on all homebrew are working and we do not hide.
but on @habib 4.81 COBRA 7.50 v1.02
syscalls off - homebrew are working
syscalls on - homebrew are working




Yes as pinky said, is due to the Homebrew blocker feature if i am not in wrong. Disabling Cfw (syscalls) enable the homebrew blocker. This feature has been added in Cobra 7.52, so in Habib Cobra 7.50 there isn't nothing blocking homebrew. [emoji4]


Inviato dal mio iPhone utilizzando Tapatalk
 
yeah, homebrew blocker. ;) I didn't even look at the second cobra version, so not a bug. lol it's meant to protect you online.
 
The homebrew blocker blacklisting/whitelisting was a fairly good idea by Aldo & implementation by KW but in practice it turned out to be harder for users to handle than expected, especially because except advanced users who can always refer to the Cobra source nobody understood how the feature worked & how to reenable something that was blocked by the feature by default.
There is no info given on screen or whatever when the feature is used so users never understood why some things were not running anymore, they never realised the homebrew blocker was blocking certain actions & they never knew that it was possible to use the config files to allow/block a game id.

The feature was introduced in Cobra 7.52. It relies on 2 files /dev_hdd0/tmp/blacklist.cfg" & "/dev_hdd0/tmp/whitelist.cfg" to decide whether or not a launched executable should be run or not..

The Homebrew Blocker feature only gets called when
1. Syscall 6 (peek) fully disabled (not partially disabled)
2. The app runs from /dev_hdd0
3. The app is launched from an EBOOT.BIN file.

The feature first tests if the launched app is whitelisted, then if it is, it will check whether it is blacklisted, if not the launched app can finally run.

The whitelist will check the launched app gameid against these partial gameids by default:
"NP", "BL", "BC", "KOEI3", "KTGS3", "MRTC0", "ASIA0", "GUST0". "_INST" & "_DEL" were also added to the list later when it was found that some pkg installations were affected by the Homebrew blocker due to the fact that the pkg installation was detected as a homebrew launch!
All gameids starting with one of the 10 strings above will be allowed, other gameids are not whitelisted & are blocked whenever the homebrew blocker feature is being used (syscall 6 disabled etc...).
The feature also opens whitelist.cfg to check the gameid against additional ids listed in the file.

The blacklist will check the launched app gameid against these partial gameids by default:
"BLES806" // Multiman and assorted tools are in the format BLES806**
"BLJS10018" // PSNPatch Stealth (older versions were already detected as non-NP/BC/BL)
"BLES08890" // PSNope by user
"BLES13408" // FCEU NES Emulator
"BLES01337"// Awesome File Manager
"BLND00001" // dev_blind
"NPEA90124" // SEN Enabler
All gameids starting with one of the 7 strings above will be blacklisted, other gameids are not blacklisted & are allowed by the Homebrew Blocker.
The feature also opens blacklist.cfg to check the gameid against additional ids listed in the file.

There is no need to disable this feature altogether to allow certain apps to run, one only needs to update the whitelist/blacklist files.
To help users do that, when an app gets blocked by the feature maybe a message containing the blocked gameid should be displayed as well as an option to add the gameid to the whitelist if required.
In the meantime, partial or full game id strings can manually be added to the whitelist.cfg & blacklist.cfg files in /dev_hdd0/tmp.

I hope this helps clarify the situation for all Cobra CFW users.
 
Last edited:
@bguerville I do not seem to have disabled this feature in 7.55. I only Fixed Bug in erasing Game Data / Applications / Homebrew with Disabled Syscalls, thanks also to the research for @aldostools e @Joonie
A lot of people were complaining about this problem. (At least in my pvt messages)

The homebrew blocker is included and running in 755 ferrox o_O
 
Last edited:
I would like to ask about one syscalls related conversation as we already talk about cobra cfw and wmm. Is this a bug or such a feature?
Because not where I did not find it in the descriptions

in WMM
on Ferrox 4.82 Cobra 7.55 v1.01
syscalls off - CFW is off and homebrew dont work(with an error message).
syscalls on - CFW on all homebrew are working and we do not hide.
but on @habib 4.81 COBRA 7.50 v1.02
syscalls off - homebrew are working
syscalls on - homebrew are working




ffc9b1c5189e28165320130821d21e67.jpg


It's not a bug, but a feature (since 7.52)



Sent from my iPhone using Tapatalk
 
The homebrew blocker blacklisting/whitelisting was a fairly good idea by KW but in practice it turned out to be harder for users to handle than expected, especially because except advanced users who can always refer to the Cobra source nobody understood how the feature worked & how to reenable something that was blocked by the feature by default.
There is no info given on screen or whatever when the feature is used so users never understood why some things were not running anymore, they never realised the homebrew blocker was blocking certain actions & they never knew that it was possible to use the config files to allow/block a game id.

The feature was introduced in Cobra 7.52. It relies on 2 files /dev_hdd0/tmp/blacklist.cfg" & "/dev_hdd0/tmp/whitelist.cfg" to decide whether or not a launched executable should be run or not..

The Homebrew Blocker feature only gets called when
1. Syscalls are fully disabled (not partially disabled)
2. The app runs from /dev_hdd0
3. The app is launched from an EBOOT.BIN file.

The feature first tests if the launched app is whitelisted, then if it is, it will check whether it is blacklisted, if not the launched app can finally run.

The whitelist will check the launched app gameid against these partial gameids by default:
"NP", "BL", "BC", "KOEI3", "KTGS3", "MRTC0", "ASIA0", "GUST0". "_INST" & "_DEL" were also added to the list later when it was found that some pkg installations were affected by the Homebrew blocker due to the fact that the pkg installation was detected as a homebrew launch!
All gameids starting with one of the 10 strings above will be allowed, other gameids are not whitelisted & are blocked whenever the homebrew blocker feature is being used (syscalls disabled etc...).
The feature also opens whitelist.cfg to check the gameid against additional ids listed in the file.

The blacklist will check the launched app gameid against these partial gameids by default:
"BLES806" // Multiman and assorted tools are in the format BLES806**
"BLJS10018" // PSNPatch Stealth (older versions were already detected as non-NP/BC/BL)
"BLES08890" // PSNope by user
"BLES13408" // FCEU NES Emulator
"BLES01337"// Awesome File Manager
"BLND00001" // dev_blind
"NPEA90124" // SEN Enabler
All gameids starting with one of the 7 strings above will be blacklisted, other gameids are not blacklisted & are allowed by the Homebrew Blocker.
The feature also opens blacklist.cfg to check the gameid against additional ids listed in the file.


Alexander disabled the feature in the Cobra he included in his release & bumped up the version number.
I mean no disrespect but imho that was a mistake that led to confusion, as if it was a bug fix & people insisted in updating Cobra in other fw for no good reason thinking it was a legitimate fix update & not realising that it only disabled a feature that works fine but that nobody knew anything about.

There is no need to disable this feature altogether to allow certain apps to run, one only needs to update the whitelist/blacklist files.
To help users do that, when an app gets blocked by the feature maybe a message containing the blocked gameid should be displayed as well as an option to add the gameid to the whitelist if required. In the meantime, partial or full game id strings can manually be added to the whitelist.cfg & blacklist.cfg files in /dev_hdd0/tmp.

I hope this helps clarify the situation...

Some small clarifications:
- I came with the original idea... KW coded it & eventually Joonie implemented it in Cobra due my insistence (Joonie is very prudent).
Here is the original conversation: http://www.psx-place.com/threads/pr...hed-after-disabling-the-cfw.12356/#post-68949

- Syscalls do not need to be fully disabled. The homebrew blocker is activated when syscall 6 (LV2_PEEK) is disabled:
int syscalls_disabled = ((*(uint64_t *)MKA(syscall_table_symbol + 8 * 6)) == (*(uint64_t *)MKA(syscall_table_symbol)));

- blacklist.cfg & whitelist.cfg are optional. I doubt that many users know about them or use these files. Almost everyone use the defaults coded internally which cover 99.9% of the ids.

- For Cobra 7.54, Joonie was considering removing the homebrew blocker due a bug installing updates reported by Alexander.
I found that the bug was caused because the blocker was blacklisting the temporary folders _INST_*. After the fix, Joonie decided to keep the feature and released Rebug with Cobra 7.54.
Issue reported & fix: https://github.com/Joonie86/COBRA-7.3/issues/9

- One day later, Alexander found another bug in the homebrew blocker similar to the one fixed but related to _DEL_* folders created when a pkg is deleted. He fixed the bug and included it in FERROX as Cobra 7.55. So, he didn't remove the feature, instead he improved it, but the move resulted in a mislead as FERROX had a more advanced Cobra than Rebug, when it really only had a small fix that Joonie and I helped to fix. The fix is included in all Rebug 4.82.

It's really sad to see that a feature that I suggested trying to protect the community from banning has caused so many confusion.
 
Ok my mistakes.
@Alexander & @aldostools, the post is fixed, you were both very prompt to correct me, I am impressed. Lol

Alex, you never disabled the homebrew blocker completely? Never? I must be getting old & my brain soft then..

Also Aldo the confusion is not my own doing.
This has been a constant problem for over a year & it's because nobody took the time to address that confusion properly.
This post of mine should have been made last year & probably not by me. From then on, enquiries should have been redirected to it.
Instead people have been left clueless which led to rumours & crap workarounds.
And now here we are, so many months later...
 
Last edited:

Similar threads

Back
Top