Semi-Permanent Exploit(one time jig exploit)

[qwssop]

It seems like the ps3 runs startup processes via registry/xml files. Or at least defines the contents of the xmb menu though xml files in

/dev_flash/vsh/resource/explore/xmb/

I noticed the file category_game_tool2.xml which contains a 'seg_gamedebug' entry. The xml seems to tell the xmb to load certain tools. It seems the payload is patching a call to a certain xml so that category_game_tool2.xml is loaded. The '#root' bit may be a comment so that the rest of the preciously loaded xml is commented out.(spurious)

So the idea of the semi permanent hack is that you drop the contents of the category_game_tool2.xml into an xml that would get loaded normally and et voila no need to use a usb device to patch every boot time.

Will let you know if it works(i suspect the dev_flash is probably write protected(yep it was)).

But there you have it. Worth noting the 'category_networking_tool2.xml' as it might provide the debug network access.

[SifJar]

So if there were some way to disable the write protection, you could have a permenant "jailbreak"? Very intriguing. I assume it is unlikely to be possible to do this? Also, is this XML file by any chance what enables/disables Other OS? If its got to do with booting and the like...And if the payload of PSGroove et al and patch calls to this file, perhaps it could be modified to enable Other OS? (If the file even handles this...). Just an idea, dunno if its at all likely...

[Hellcat]

If this works (lets consider that for a moment) it might enable the "Install .PKG" option but will still not let you run hombrew/unsigned code as another patch is required to cancel out that check.

Also AFAIK OtherOS components are completely removed from the FW, so a simple fileedit will not bring it back.

[Dariusc7]

If this works (lets consider that for a moment) it might enable the "Install .PKG" option but will still not let you run hombrew/unsigned code as another patch is required to cancel out that check.

Also AFAIK OtherOS components are completely removed from the FW, so a simple fileedit will not bring it back.

I totally agree with you. Editing the registry in the ps3 wont do much since the pkg and the files insided have to be signed, unless we can somehow patch the memory on-booting so that it would load unsigned code.

As for the flash write protection, all you have todo is remount the flash and you can write to the flash.i

[qwssop]

If this works (lets consider that for a moment) it might enable the "Install .PKG" option but will still not let you run hombrew/unsigned code as another patch is required to cancel out that check.

Also AFAIK OtherOS components are completely removed from the FW, so a simple fileedit will not bring it back.

I totally agree with you. Editing the registry in the ps3 wont do much since the pkg and the files insided have to be signed, unless we can somehow patch the memory on-booting so that it would load unsigned code.

As for the flash write protection, all you have todo is remount the flash and you can write to the flash.i

Yep, I forgot about the signed/unsigned patch. But, regarding the otherOs feature. As soon as richdevx releases the 3.15 jailbreak version we should be able to get both the xml entry and the sprx resources. The sprx will already have been signed so the only thing we would need after that is to edit the xml.

At least that's the way it seems at the moment, it doesn't look like there are hash checks/size checks on the xml.

[w3s]

or maybe...
like x360

another rebooter for PS3

i think.

[vxer]

they can update all EEPROM and FW from updates except the one in CELL presumably..

nothing permanant is possible unless variants of chip hacking come along which given the state of silicon RE its not likely. Just look for more shellcode exploits that manipulate structures dealing with disk authentication. Ive heard from a respectable RCE community there have been methods of putting Linux back on the PS3 but they all involved distributing modified SCE code tethered to shellcode based loaders. Given the design of the PS3 this seems to be the destiny of the PS3 scene..

I actually suspect the real reason geohot left was because he couldnt deliver on his public promises without major legal issues. Also like 95% of his iproduct work was under contract, something he let slip once publicly but nokia and apple probably never took interest in because of PR even though then they had a good standing in a court room with just what was public. What makes me think this is because he magically rebuilt lv1 inside a week and fully reversed and used all crypto protocols. Its likely but kind of improbable given he was also working on other stuff then including school.

[qwssop]

they can update all EEPROM and FW from updates except the one in CELL presumably..

nothing permanant is possible unless variants of chip hacking come along which given the state of silicon RE its not likely.

I think you misunderstood. I certainly didn't mean a cross firmware exploit. Just that once a unit had been jailbroken we could patch the xml files so that the resources got loaded each time the ps3 booted without the jig exploit. It was pointed out that that might be true but you would still be unable to run unsigned code. Still there is scope for getting otherOs back and possibly enabling developer features like the developer console.

I'd need to sit down with the shell code and alter the payload so that it patches network_tools2.xml too. I looked at the xml files them selves and didn't get a great clue as to what it would add.

It might well be possible to cut and paste resources from different versions, it depends on whether there are version checks on the sprx modules. I assume that by 3.41 there would be but I've not seen anything to thoroughly convince me.

[vxer]

Yeah I was just pointing out there is no way to keep SCE from fixing exploits.

I dont think there is a question as to wether you can modify signed code to do a simple high level loader. SCE firmware and the CELL ROM do all unwrapping and sig checking. The ROM can easily be fooled since SCE left so much in XDR. They would have to rewrite firmware using the encrypted DMA model between SPE just to secure their system for a while. Still SPE RAM is even easier to do memory overwrites than XDR is though cause it wraps around, this means they would have to leave a lot of code and data in XDR on a low-privalage LPAR, mostly just codecs, applets and 3D data and code though.

Nobody has yet to do anything but backups though. The whole dongle event has yet to produce anything worth mentioning unless you are a mindless software consumer.

[qwssop]

[quote=Hellcat;19831]
As for the flash write protection, all you have todo is remount the flash and you can write to the flash.

How would you remount the flash?

Looking through the trendmicrofilter xml, the downloadable datatypes can be altered. ergo you end up with a wii homebrew channel running through the web browser. Silly but perhaps worth developing on before the dh douche's open up their homebrew store.

Should infact be able to add a HomeBrew section, say between TV and Games and have the custom browser(just have it link to the HB site). Have homebrew content download here in folders.

There are quite a few fun and funky things to play with. The Jaicrab usb dev_flash thing should allow for testing of these theories... meh

[qwssop]

O.K changed the mem patch to patch in the network_tool2.xml I mentioned earlier. On selecting a user the system resets to safe mode(insert usb cable into ps3 controller etc etc).

I worked under the assumption that '_tool2.xml' was being appended to a system config_game.xml call and that I had to patch the previous memory locations to add the full 'network_tool2.xml' to the mem patch. Juggling hex bytes is fun, the AerialX fork of the psgroove git hub effort is awesome. Really worth looking into if you want to test patches easily.

Need to review my patch code.

For reference:

memory_patch_table_3:
PATCH_DATA(0x0022B884, 0x6E657477)
PATCH_DATA(0x0022b888, 0x6F726B5F)
PATCH_DATA(0x0022b88c, 0x746F6F6C)
PATCH_DATA(0x0022b890, 0x322E786D)
PATCH_DATA(0x0022b894, 0x6C23726F)
PATCH_DATA(0x0022b898, 0x6F740000)
.long 0
memory_patch_table_4:
PATCH_DATA(0x000d68b4, 0x6E657477)
PATCH_DATA(0x000d68b8, 0x6F726B5F)
PATCH_DATA(0x000d68bc, 0x746F6F6C)
PATCH_DATA(0x000d68c0, 0x322E786D)
PATCH_DATA(0x000d68c4, 0x6C23726F)
PATCH_DATA(0x000d68c8, 0x6F740000)
.long 0

The first set of hex bytes in Patch_Data being the address, the second the value.
(p.s had to install fedora to get ppu-gcc working for compiling AerialX's psgroove fork).

I checked the patch values and it seems I missed out four bytes. Once I addressed them the system loads like normal but I cannot see any differences to the xmb layout.

(EDIT #4 by this point)

I was wrong. It seems I have spawned the network menu in place of the game menu(i.e all the items that are under the Network section are also present in the Game section. No new items, will need to look at those xml files again...

(Edit #5)
Enabling 'sysconf_shop.xml' spawns a couple of icons that don't link to anything(dead links to old resources I guess... may be good for putting something in their path.... i.e otherOs if we need a link on the main menu to it)


Bit of a long shot but I don't suppose any one has the otherOs inclusive sys config xml from the 3.15 days?