PS3 Hypervisor LV2 (GameOS) Dump Method is Revealed!

Category: PS3 Hacks & JailBreak By: ps3junkie2010 - (jaicrab.blogspot.com)
Tags: ps3 hypervisor lv2 ps3 gameos dump ps3 hypervisor dump method

163w ago - As promised, today JaicraB has revealed the PS3 Hypervisor LV2 (GameOS) dump method and circuit used to allow the PS3's memory to persist while booting into OtherOS, which then allows dumping of the memory.

This was apparently on a CECHG model system with board model SEM-001 1-875-384-21

To quote, roughly translated: DemonHades / JaicraB Extraction Method:

First of all, be careful if you're going to attempt this, I am not responsible.

It's about keeping the RAM alive when moving to OtherOS. To do this the ram must be fed at all times so as not to erase the data.

Overview map
Refer to the First Image below.

Zone A
http://4.bp.blogspot.com/_4rtVxQc9D6s/S7dexn30R7I/AAAAAAAAAFs/tpo2XxknPKs/s1600/Zona+A.JPG

This area is sensitive. At that point we had settled with two resistors together. You have to remove it (remove it, but you could also cause a short circuit). It has 4 legs. At this point it tells the RAM and the integrated MOSFET turns off.

Zone B
http://3.bp.blogspot.com/_4rtVxQc9D6s/S7deyC8VeyI/AAAAAAAAAF0/bGUuh1knvRA/s1600/Zona+B.JPG

From the point labeled we get the feed. You can put anywhere on the track.

Zone C
http://2.bp.blogspot.com/_4rtVxQc9D6s/S7deye-D8wI/AAAAAAAAAF8/1EeIUE6Keyw/s1600/Zona+C.JPG

At this point labeled we have to make a bridge to defeat the two resistors.

Zone D
http://2.bp.blogspot.com/_4rtVxQc9D6s/S7dYDoRKnRI/AAAAAAAAAE0/tp9grVoM5kQ/s1600/Zona+D.jpg

The original point of the exploit.

Mini Circuit
Refer to the Second Image below.

The Technique

It is possible that the first time you start count him to do for the recovery.

It Summarized a bit with the following steps:

• Log into XMB.
• Touching, ejectura, configure, filling the memory with more information.
• Run a game, insert a BD, etc, etc.
• Then boot to OtherOS.
• Dump memory to exploit.

Remember: The first 36 Megabytes are the "privileged memory" that contains LV00, LV1, LV2. The rest is waste memory of XMB (very interesting) and data from OtherOS.

The next thing to try is to start a tiny linux system and do a full dump. So we would get more data from the XMB and less disturbed memory (from OtherOS)

The bad thing is my two-week vacation is over

(I would have liked to have one more week to follow up).

Good luck to all and share!

Stay tuned for more PS3 Hacks and PS3 CFW news, follow us on Twitter and be sure to drop by the PS3 Hacks and PS3 Custom Firmware Forums for the latest PlayStation 3 scene updates and homebrew releases!

63 Comments - Go to Forum Thread »

#63 - moneymaker - 162w ago

Originally Posted by tragedy

At the end of the day, the vast majority of encrypted code runs on the PPU after decryption, so even considering the encrypted metldr block, the general principle is:

PPU: does basic initialisation

[B]

#62 - teusjuh - 162w ago

got an noob question

with all information what public is... how far is it away to get unsigned code running. i mean how far is it away for devs to make an first hello world or something?

edit: or is there still not enough dump information??

#61 - sapperlott - 162w ago

All valid points and a very good summary of the boot process and a possible attack vector. But the original argument was about whether or not the data inside the isolated SPU can be compromised.

#60 - tragedy - 162w ago

Originally Posted by sapperlott

I'd be interested in how you think this could be circumvented without the keys necessary to create own signed / encrypted binaries.

Well, that all depends if your goal is signing code so it can run on any console or just allowing unsigned code to run on your console. The latter will be possible, although still difficult.

At the end of the day, the vast majority of encrypted code runs on the PPU after decryption, so even considering the encrypted metldr block, the general principle is:

PPU: does basic initialisation
PPU: requests SPU to start up in isolation mode
SPU: decrypts lv0 and puts in somewhere PPU can access it
PPU: waits for SPU to finish decrypting lv0
*INSERT HACK HERE TO PATCH lv0 HERE*
PPU: executes decrypted lv0 code
...
PPU: lv0 sends message to still running metldr SPU to decrypt lv1
SPU: decrypts lv1 and puts in somewhere PPU can access it
PPU: waits for SPU to finish decrypting lv1
*INSERT HACK HERE TO PATCH lv1 HERE*
PPU: executes decrypted lv1 code
...
PPU: lv1 sends message to still running metldr SPU to decrypt lv2
SPU: decrypts lv2 and puts in somewhere PPU can access it
PPU: waits for SPU to finish decrypting lv2
*INSERT HACK HERE TO PATCH lv2 HERE*
PPU: executes decrypted lv2 code
...
*CHECK*
PPU: lv2 sends message to still running metldr SPU to decrypt self
SPU: decrypts self and puts in somewhere PPU can access it
PPU: waits for SPU to finish decrypting self
*INSERT HACK HERE*
PPU: executes decrypted self code

So, even without knowing the encryption keys, provided we can obtain the original metldr, we can always execute signed code so we can continue to run regular games with a modified lv2.

To run unsigned code, where I've written *CHECK*, we check to see if the code is unisgned, if so we just execute it directly without ever asking the SPU to decode the data.

#59 - sapperlott - 162w ago

Well - here's how I understand it after reading through the docs (and spufs sources):

When an SPU enters isolation mode, it fetches the encrypted / signed (with the hardware root key) binary (normally a loader) from memory (via DMA) into its Local Store, decrypts it there and runs it. When in isolated mode, only a very small window of its Local Store is accessible through DMA by the other components (other SPUs, PPU, RSX, etc) while outbound DMA requests aren't restricted.

The rest of the Local Store is protected and can only be accessed by the code running on the isolated SPU itself. So if the programmer of the isolated SPU code isn't a complete idiot and does perform proper sanity checks on the (probably malicious) data that enters the SPU through that window there's very little chance to mess with it.

The IBM isolation loader for example expects you to write the memory address where the encrypted binary (to be decrypted by the loader code already running) resides into the accessible Local Store window. After doing so the SPU fetches the encrypted binary via DMA, decrypts it into the inaccessible regions of its Local Store and runs it. It seems plausible that METLDR uses a similar mechanism.

I'd be interested in how you think this could be circumvented without the keys necessary to create own signed / encrypted binaries.

Originally Posted by SCE

So, any ideas how to start making a better dump? At least telling kernel to not to use first 36 MB of RAM?

As far as I see it, it's nearly impossible to tell the Linux kernel "not to use the first xx MB of RAM" since the Linux kernel uses LV1 calls to allocate memory. What looks like one big chunk of contiguous memory to the kernel might consist of many small parts (LPARs) spread over the entire physical memory range.

So in order to have such tight control over memory allocation I guess one would have to patch the hypervisor.