PS4 News on Facebook! PS4 News on Twitter! PS4 News on YouTube! PS4 News RSS Feed!

Home PS4 News - Latest PlayStation 4 and PS3 News

265w 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!

PS3 Hypervisor LV2 (GameOS) Dump Method is Revealed!

PS3 Hypervisor LV2 (GameOS) Dump Method is Revealed!

Follow us on Twitter, Facebook and drop by the PS3 Hacks and PS3 CFW forums for the latest PlayStation 3 scene and PS4 Hacks & JailBreak updates with PlayStation 4 homebrew PS4 Downloads.


  • Sponsored Links




#63 - moneymaker - 264w ago
moneymaker's Avatar
Quote Originally Posted by tragedy View Post
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 - 264w ago
teusjuh's Avatar
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 - 264w ago
sapperlott's Avatar
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 - 264w ago
tragedy's Avatar
Quote Originally Posted by sapperlott View Post
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 - 264w ago
sapperlott's Avatar
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.
Quote Originally Posted by SCE View Post
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.

#58 - SCE - 264w ago
SCE's Avatar
So, any ideas how to start making a better dump? At least telling kernel to not to use first 36 MB of RAM?

#57 - moneymaker - 265w ago
moneymaker's Avatar
Quote Originally Posted by sapperlott View Post
SPU Isolation is a hardware feature - not much you can do about it in software (even if it's written in Assembler ).

Hehe... "isolated"... this means no data "enters" the SPU and no data "exits" from there ? NO!

Isolated my rear, let we say it only executes fixed tasks (among which there is also one task we could like to show Kanna her's system is not forced to be unbreakable cause everyone thinks it's unbreakable...

By "hardware" it means it should not be any bus connections between the SPU and the rest of the processor and you have to connect directly on the SPU bus to reach it... and this is not true...cause actually it performs action (de/cypher) on data that runs "through" it... if it were truly isolated it could act only as an hardware replacement protection...

Furthermore there is no hardware that runs by itself "without" software, and both of them could be initialized someway and what proprietary software can also self written LM can...

Yeah, it's a very secure system but's not WrathofGod-proof...

It CAN be found an appropriate use for it's potential, believe me or not, unfortunately I'm not at the level to gain more out of this my idea, specially in theese ones that are hard times for me.

#56 - sapperlott - 265w ago
sapperlott's Avatar
SPU Isolation is a hardware feature - not much you can do about it in software (even if it's written in Assembler ).

#55 - moneymaker - 265w ago
moneymaker's Avatar
Quote Originally Posted by SCE View Post
Actually Geo was talking about this in the beginning of his work on PS3. But since it required an expensive device , he didn't go that way...

Hehe, brain is the most expensive device...

However each system has it's own Achille's heel, if the isolated SPU cannot be manipulated in regular ways it doesn't mean it has not the ability to decrypt it's own content if it should be feeded to the SPU itself through the normal channel, it's "isolated" between quotes cause it actually decrypts everything is /needed/feeded ...if introduced in the right way....

Next step is to dump the SPU cache, it's a pain, I admit it... but bare metal assembler code it's really powerful... maybe it's not impossible...

#54 - SCE - 265w ago
SCE's Avatar
Quote Originally Posted by sapperlott View Post
It's the memory bus - you have to know how the system talks to the memory first before trying to tap it. Just forget about tapping into the XDR memory.


Actually Geo was talking about this in the beginning of his work on PS3. But since it required an expensive device , he didn't go that way...