PS3 [Research] Brick Resistant XMB Patch

DeViL303

DeViL303

Developer
PSX-Place Supporter
Few small things I've discovered that may not be known and are kind of interesting

This first patch I call the Brick Resistant XMB Patch. Normally when the XMB loads initially, if any of the category xmls are missing, or the icontex.qrc file is missing then the PS3 kicks you to recovery.

I have discovered that this is just some kind of security check and not a real crash, and the PS3 is perfectly capable of booting regardless of missing files. This uses a little trick and some bad coding of the check in the first place I guess. :)

Myself and @Joonie and @sandungas discussed this before a little when we were talking about the definition of a crash. I was saying that I don't consider this a crash when you get kicked to recovery due to missing xml/qrc, I think a crash is when the PS3 loses control and freezes or similar. I think in the case of kicking to recovery due to missing FW files its not a crash but a sub routine,

Basically if issue = missing files on /dev_flash then = kick to recovery. The way I see it the PS3 is still fully in control and able to accept commands, its just decided to do something different based on its conditions it found itself in


The trick here is that the ps3 only kicks to recovery if its looking for xmls or qrc on /dev_flash/ specifically...So if we edit the path to be for example //dev_flash/ , well then the ps3 no longer cares about missing files and just continues to load what it can.


Another handy thing I discovered is that you can do this with a simple 1 byte patch to explore_plugin.sprx that makes all xmls brick resistant, so you dont need to edit each path and xml individually, just edit it here:

unknown.png

upload_2019-10-10_21-37-6.png



With that patch applied you can delete all xml for example, and you just get empty categories. You can apply the same patch to icontex.qrc in the custom_render_plugin.sprx, this patch might work in other places too.

IMO really this should be applied to all CFW as there is no downside.

You can even remap all category xmls to other paths like usb/hdd by just editing that one place as that is where %flash is defined. Any other paths than the default dev_flash will not kick to recovery if files are missing.

unknown.png
 
Last edited:
MrMario2011 said:
This is a pretty impressive discovery. Solid work!
Click to expand...
Cheers, yeah simple and effective. I noticed when editing it to usb that it did not soft brick anymore, so then tried to come up with a path that would fool it but still link to dev_flash, It didnt take long. I think /dev_hdd0/../dev_flash/vsh/resource/explore/xmb/ probably would have worked too but its longer and space is limited, luckily enough // worked.
 
sandungas said:
I dont understand why it works, but yeah smart trick :D
Click to expand...
I kind of do understand it, think about it. If we add a query in xml to dev_hdd0/game/ then the PS3 does not care if it exists or not, But if we add exact same xml query to exact same xml but on flash then its a brick if file is deleted. So basically the PS3 has a rule: If file is on dev_flash then it must exist or else soft brick and demand FW reinstallation.

This means there is some simple integrity check or security check to stop you deleting files, or to make sure corrupt files get fixed. The check is very badly implemented a bit like the write protection on dev_flash. All you need to do is change the name and it does not think you are reading from or writing to dev_flash anymore so it treats the path like dev_hdd0 or dev_usb etc. The real trick was finding that double // lead to same path, as I know nothing about that kind of thing so that was a bit of luck.
 
Last edited:
DeViL303 said:
I don't think so, as any path other than dev_flash has same effect regardless of the //. That is just a way to get it to still look to flash, a bit of luck.
Click to expand...
Didn't really think so but as soon as I saw the two forward slashes that came to mind.
 
Nice job as usual, i realized that too, if u delete like e.g explorer_plugin_full.rco it will kick you to the recovery.

but if you leave a dummy file with the name of the missing rco it will boot normally.

the only file i see that works good even deleting it, is coldboot.raf if you unlink it in the custom_render.rco
 
My NAND with no patches , standard Rebug. and no icontex.qrc or xmls. Boots fine, can still use ftp and look at wave :)

upload_2019-10-10_23-54-2.png


LuanTeles said:
Nice job as usual, i realized that too, if u delete like e.g explorer_plugin_full.rco it will kick you to the recovery.

but if you leave a dummy file with the name of the missing rco it will boot normally.

the only file i see that works good even deleting it, is coldboot.raf if you unlink it in the custom_render.rco
Click to expand...


Yeah you can delete coldboot rafs and coldboot ac3 files and the ps3 does not care. Due to this I have an idea that I am using in my Rebug Mod. All xmls, all Coldboot ac3 files, and coldboot raf , and custom render plugin sprx and rco and xmb_plugin sprx and rco are read from dev_flash2/ and are not included in the PUP. this way when you update to Rebug Mod 4.85, Rebug Mod 4.86 etc your XMB setup stays intact. Really I want lines.qrc to read from dev_flash2 as well but having trouble with that patch so far. :) the cool thing is that dev_flash2 is not wiped in a format, and its not wiped in a FW reinstall, so you can have XMB permanently modded throughout FW updates. I think its the way forward and also its an extra 15MB that we can be using that is wasted.
 
Last edited:
You must log in or register to reply here.

Similar threads

Back
Top