Improved ROS patch algorithm

[kostirez1]

After comparing the previous algorithm to the latest version of bgtoolset, I found a few differences that should now make it a working solution. Most of the checks were reimplemented for VSH memory limitations, the rest is in TODOs.

Currently only tested on CECHK (NOR model, CFW 4.84 DEX), with USB flash drive as the target device to be patched. Using that, I was able to verify that both NOR and NAND modes don't corrupt flash contents in any way (at least PyPS3checker can't detect it).

Before patching (NOR):

******* Checking CoreOS_region *******
009.01   ROS0 Header : OK
009.02   ROS0 Hash : OK
  Size = 0x6FFFE0
  MD5 = 2C6791BAC0978B921CACAEBB1E827743
  Version = 4.89 CEX/SEX OFW/HFW

009.03   ROS0 unused 0xFF Filled Area : OK
009.04   ROS1 Header : OK
009.05   ROS1 Hash : OK
  Size = 0x6FFFE0
  MD5 = 8F4A63DC20F1EB54168478C814DF80C1
  Version = 4.87 CEX/SEX OFW/HFW

009.06   ROS1 unused 0xFF Filled Area : OK

Total number of checks = 155
Number of dangers = 0
Number of warnings = 0

After patching (NOR):

******* Checking CoreOS_region *******
009.01   ROS0 Header : OK
009.02   ROS0 Hash : OK
  Size = 0x6FFFE0
  MD5 = B9FEB4432ADB086D890472AB29B663A9
  Version = 4.89 CEX Patched (Evilnat based)

009.03   ROS0 unused 0xFF Filled Area : OK
009.04   ROS1 Header : OK
009.05   ROS1 Hash : OK
  Size = 0x6FFFE0
  MD5 = B9FEB4432ADB086D890472AB29B663A9
  Version = 4.89 CEX Patched (Evilnat based)

009.06   ROS1 unused 0xFF Filled Area : OK

Total number of checks = 155
Number of dangers = 0
Number of warnings = 0

Changes:

• Removed half/full write modes (not really sure what it does, so I couldn't reimplement it)
• Added flag to redirect all reads and writes to /dev_usb000/ (write NOR/NAND dump to USB flash drive in order to use it)
• ROS offsets are now aligned to sector size boundary
• ROS patches (or "overlays") are prepared as files on HDD before they are written (bypass RAM limitations)
• Preallocated memory segment is now unused
• Added faster check for NOR vs NAND (same one used by bgtoolset)

TODO:

• Add minver check for < 3.60
• Add sanity checks for every read and write return values
• Check that newly written overlay file is indeed 0x3800 sectors long, 7 340 032 bytes
• Verify ROS contents before and after writing them to flash

Credits:

• bguerville (for reference implementation in bgtoolset)
• TheRouletteBoi (for help with PS3 Debugger)
• TobinPS (for help with DEX firmwares and debugging in general)

[kostirez1]

Input from users with access to a hardware flasher required.

[kostirez1]

Successfully patched a NAND dump with 4.89 PS3HEN, using noFSM patch for 4.83.
Again, USB flash drive with NAND dump written to it being the target.

Before patching (NAND):

******* Checking CoreOS_region *******
009.00   ROS Header : OK
009.01   ROS0 Header : OK
009.02   ROS0 Hash : WARNING!
  Size = 0x6FFFE0
  MD5 = 5A0B494EBCAE8813AF930E9952E083B9
  Version = (unknown)

009.03   ROS1 Header : OK
009.04   ROS1 Hash : OK
  Size = 0x6FFFE0
  MD5 = 50F75486F8C99B66ED4A3B9B5F3FF946
  Version = 4.89 Evilnat Cobra

******* Checks completed *******

Total number of checks = 113
Number of dangers = 0
Number of warnings = 1

Following check(s) returned a
WARNING!
  009.02   ROS0 Hash

After patching (NAND):

******* Checking CoreOS_region *******
009.00   ROS Header : OK
009.01   ROS0 Header : OK
009.02   ROS0 Hash : OK
  Size = 0x6FFFE0
  MD5 = 2284CFDB950D14CA199AD9469AAA1EC4
  Version = 4.83 CEX Patched (FERROX based)

009.03   ROS1 Header : OK
009.04   ROS1 Hash : OK
  Size = 0x6FFFE0
  MD5 = 2284CFDB950D14CA199AD9469AAA1EC4
  Version = 4.83 CEX Patched (FERROX based)

******* Checks completed *******

Total number of checks = 113
Number of dangers = 0
Number of warnings = 0

[aldostools]

That's great news. We still need developers with hardware flasher that test the software flasher on real conditions.

Thank you to all people involved for the improvements.

[kostirez1]

Now I got a hold of NOR dumps directly before and after patching with bguerville's toolset v1.2.004 (the last publicly released version) and the results are as follows:

Filename	SHA256
bgtoolset_before.hex	97F877AE789A7821C825653B47D21FCC6AB7407884F626A32E591671404C98DD
bgtoolset_after.hex	0EE3311E08804B111C3331EAE8D375107582225DAB6F54AD5E5963EB55F74E8D
webman_patch_usb.hex	0EE3311E08804B111C3331EAE8D375107582225DAB6F54AD5E5963EB55F74E8D

I don't think it can get any closer, honestly. 😅

Only questions I wasn't able to answer are:

1. Is there any reason why sys_storage_write() syscall would fail on PS3HEN, when writing to internal flash?
2. Is it necessary to patch more things than just ROS0 and ROS1 regions? Something like revocation regions (rvk)? PyPS3patcher supports it for some reason

[aldostools]

1. AFAIK sys_storage_write() should work without issues on HEN. It's the same syscall used by the ps3xploit flash writer and by the leaked source code of bgtoolset.

The major risk is the time that it takes to write 2 ROS regions. If there is a power failure while the current ROS region is written, can result in a bricked console. The official PUP writes to the non-active ROS, then switches the active ROS after a successful update. If we can find a way to detect and switch the active ROS would solve this issue.

2. AFAIK The ps3xploit flash writer and by the leaked source code of bgtoolset only write the ROS region. Apparently the latest bgtoolset doesn't write other regions either, since you got the same result with webMAN MOD.

This path of HEN => CFW was discussed earlier by Habib and bguerville. Benjamin prefers the ROP execution exploit: It saves steps, can be used directly on OFW and he has invested a good amount of time developing his own framework. Personally, I prefer the HEN path because the coding is more standard and versatile than ROP.

The following text is an explanation by bguerville of how PS3HEN exploit works:
https://www.psx-place.com/threads/ps3hen-exploit-technical-writeup.34807/#post-305556

There are 2 webkit exploits in PS3HEN.

The one you mention which is a read primitive used to leak browser memory data. It's a powerful read primitive allowing you to leak the amount of bytes of data you specify from a memory offset you specify.
The other one is based on a vulnerability in the NaN code & it is used to trigger ROP execution via a parseFloat call..
When you provide a specifically crafted NaN value to parseFloat, webkit interpreter execution jumps to the offset described in that NaN value. It's as straightforward a code execution exploit as you can get.

So roughly speaking we first use the memory leak exploit to determine the offset of the custom ROP stack frames we planted in memory.
Once we have that offset, we craft an appropriate NaN value with it, pass it to parseFloat as an argument & the custom ROP stack frames get executed..
The last custom ROP stack frame takes care of making the execution jump back to the original execution line as if the parseFloat call execution had not been diverted & returned a valid value, you could call that a "graceful return" from ROP.

The vulnerabilities exploited in PS3HEN were already used in Vita's henkaku years ago. When esc0rtd3w & I started ps3xploit, xerpi had already ported the memory leak exploit to ps3 but nobody ever tried to leverage it. So we did & I ended up porting the NaN/parseFloat exploit implementation.
Technically speaking the old Vita henkaku webkit exploits & the PS3HEN webkit exploits are pretty much identical, it's mostly the memory layout & the ROP implementation that change.
It's the same thing with the kernel exploit, the ioctl exploit is an henkaku exploit developed for Vita which habib ported to ps3. At the time I wrote kernel ROP for that port.
Iirc there should be some write up available for all 3 vulnerabilities in henkaku documentation.
There is also a series of videos & posts on ps3 webkit exploitation in this forum, check the tutorial thread started by esc0rtd3w, you should find the information useful. The series of videos was left unfinished due to the absence of interest.
For once someone was ready to teach basic console exploitation skills to anyone interested, providing write ups, videos & software to test with, not a single person took advantage of it afaik... Disappointing to say the least, especially when you consider how rarely such an opportunity arises.

I don't work on the PS3HEN releases, those releases still rely on code I wrote over 3 years ago for the old ps3xploit tools, code that I don't use anymore.
On the other hand, as I wanted full OFW support for my PS3 Toolset project, I couldn't use the parseFloat exploit so I replaced it with a Flash 9 exploit I wrote that's working on OFW.
You may wonder why Flash 9, why not stick to webkit? Because Flash 9 offers an ideal read/write primitive candidate with the bytearray actionscript object whereas the ps3 webkit doesn't offer any decent candidate objects, strings are immutable, standard arrays impractical, it doesn't have typed arrays (or any vector-like objects) like the Vita webkit has. Also, a Flash 9 exploit is less "restricted" than a webkit exploit, it can be used in both silk & silk webkit browsers as well as any other OS or game/app feature using Flash 9.
For the moment the webkit memory leak exploit still works great on OFW so I kept it in the PS3 Toolset project so as not to burn an extra exploit for no reason however I already crafted an all-in-one replacement exploit that I really like actually. It leverages a Flash 9 type confusion vulnerability enabling you to customise an actionscript object internal data. Once you got control over its internals, the object public methods & properties can be used in the actionscript code both for memory leaking purposes & for ROP triggering. It's ready to deploy if ever s#ny decides to patch the vulnerabilities currently exploited in the PS3 Toolset.

[kostirez1]

The official PUP writes to the non-active ROS, then switches the active ROS after a successful update. If we can find a way to detect and switch the active ROS would solve this issue.

Looked into this by comparing NOR dumps from OFW 4.84 all the way to OFW 4.89. And after comparing them to each other with zero filled ROS regions (0xC0000 - 0xEC0000), they are exactly the same. I'm not really sure if there even is any "currently active ROS" flag stored in the flash. 🤔

[kostirez1]

I found the answer for that in a post by littlebalup on PSX-Place:

Another important thing to know about ROS : there are no way to determine what is the active ROS only looking inside a single flash dump data as that information is stored in the syscon (the eeprom memory) and not in the flash.

Cross-checking that with SC EEPROM - PS3 Dev wiki:

lv0 NVS region 3, offset 0x48C24, length 0x1 - Bank #0 OS-Flag (ros0 if 0xFF else ros1, for NOR consoles only) (os_bank_indicator)

SC Manager - PS3 Dev wiki:

With full HV rights you could patch Dispatcher Manager and enable access to SC Manager from GameOS.

Update Manager - PS3 Dev wiki:

Update Manager service is accessed by GameOS syscall 863.

Packet ID: 0x600B | Read EPROM, Packet ID: 0x600C | Write EPROM

Not really sure if we could access that from PS3HEN...

[aldostools]

I don't know if HEN can modify the active ROS in SYSCON. Maybe from the kernel payload could have access, like it was done for fan policy.

Anyway it would be a nice feature to be able to select the active ROS from CFW. One use is to have dual boot for overclocking without reinstall the firmware.