192w 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.
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!
here is an interesting idea ive been curious about might be way off but just an idea
the dump is recovered by keeping the RAM live during a reboot into linux/otherOS on the PS3 linux loads or performs some task to retreive the dump because something else is loaded linux pushes certin data off the ram to retreive the space to load or do what ever it needs to do there for we collect polluted data containing both linux and XMB OS data when dumping
so my idea is this can the infectus chip be used some how? i know it can acess the NAND but if the RAM is live on the system and the PS3 as a whole is off than why cant we use something like the infectus that has many uses and flashable for multiple things to connect to the RAM rather than the NAND and possibly altering an app for the infectus to read what is live while the PS3 is off via USB
i'm no genious but im just curious if this is some how possable i know the infectus connects to the NAND acording to the directions but from the instructions to other consoles its uded for its connected to a lot of other parts of diffrent machines
another option unshure how much flash memory that infectus has would it be possible to get the infectus chip to load some kind of linux to retreive the dump from the ram with out even having to start the PS3 in Other OS or to get the app that retrives the dump from the PS3 to run in a console through the infectus recovering the dump as the RAM is still live during the reboot and/or shut off process still containg the data that were trying to receive
these are just all ideas and speculation any constructive comments or explenations as to how it may or may not work would be kool im just speaking my mind atm and have no true knollage of how these things work or what might be involved in what i mention but its something thats already out there and is already supported as cross platform and for other uses allthough mostly NAND
petitboot is based on OpenWRT which is a small embedded Linux system for routers etc. - you could put the whole dump environment into the OpenWRT image and put that into the PS3s flash instead of kboot / petitboot. If you restrict this image to say the upper 32MB of RAM you might have a chance to get most of LV2 uncorrupted. Of course this assumes that the memmap kernel parameter does work on the PowerPC platform. I'll check that out later.
Also I don't think that it makes a difference whether you write the dump to HDD or stream it out over the network in this case.
You don't need the Sony SDK to build your own version of kboot / petitboot. Any current version of GCC will do. The sources can be found on Geoff's kernel.ork homepage and Git repository:
Never checked what ps3sdk includes or not but a big problem is to not overwrite the memory too, if the memory remains clean in the switching process from xmb to linux then there is no trouble at storing it wherever you want, a removable device as an hdd, the network or whatelse...
Moreover I do not believe that's possible to boot linux onto a PS3 through the network as it were a PXE enabled machine, and even in that occurrence the NBP will be kicked onto RAM as it were loaded from the eeprom were our bootloader resides and this could be even more difficult to slide at the top of the memory.... but I'm sorry if I souldn't have understood what you meant...
However the smaller the kernel the bigger and cleaner the dump....same for the higher it's allocated (hopefully)..obviously a microkernel with network capability and able to let dd access a shared space onto remote would be great.
Or to find an assembler guru able to kick into the bootloder itself a piece of code that would dump the ram content somewhere before anything else... yup, please don't rocks at me... (just a bit of humor even if it's true..)
Does the ability still exist to install the test firmware on a retail box? (I know it didn't work 100%) and if is possible has anyone tried dumping it (or does the lack of otheros make this impossible?)