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

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

Stay tuned for more PS3 Hacks and PS3 CFW news, follow us on Twitter, Facebook and drop by the PS3 Hacks and PS3 Custom Firmware Forums for the latest PlayStation 3 scene and PlayStation 4 scene updates and fresh homebrew PS3 Downloads. Enjoy!


  • Sponsored Links




#43 - Keninishna - 263w ago
Keninishna's Avatar
I know there has been customer linux loaders for otheros. Why not make a customer loader that just directly dumps the ram? Should be a very small footprint.

#42 - korn16ftl3 - 263w ago
korn16ftl3's Avatar
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

#41 - sapperlott - 263w ago
sapperlott's Avatar
Quote Originally Posted by DemonHades View Post
hi, is posible build a bld whith the ps3sdk,but the problem is the store dump file.

The sdk ps3 dont have include for mount and storage.

the best is using ethernet cable for dump,using a otheros whith it support but need included the exploit files

1saludo and yes that dump have parts linux,remember when rst don't volatilice the ram the old data mix with the new.
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:

http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-kboot.legacy/
http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-petitboot/
http://git.kernel.org/?p=linux/kernel/git/geoff/petitboot-dev.git

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.

#40 - moneymaker - 263w ago
moneymaker's Avatar
Quote Originally Posted by DemonHades View Post
hi, is posible build a bld whith the ps3sdk,but the problem is the store dump file.

The sdk ps3 dont have include for mount and storage.

the best is using ethernet cable for dump,using a otheros whith it support but need included the exploit files

1saludo and yes that dump have parts linux,remember when rst don't volatilice the ram the old data mix with the new.

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.

Quote Originally Posted by laggmaster View Post
hmm... so if i understand what i've been reading right, the hypervisor dump that we got was polluted with linux code, the solution to this would be to try to rework the otheros bootstrap which would just dump the same data without the linux code mixed into it, this would require the bootstrap to load from somewhere in the memory after the 36mb of code that we actually want (possibly by moving the bootstraps load location to the hardware on a HWBC console), this should give us our golden key right?... well ok, a map to the golden key but you know what i'm saying.

another option is to figure out how to build an external chip, aka MODCHIP (i know everyone cringes at the mention as they require hardware modification but this dose too), that would somehow record and output all everything thats loaded into the ram or other chips be recoded and outputted to a computer. but this is a very complicated process and could take years.

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..)

#39 - IanJ - 263w ago
IanJ's Avatar
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?)

#38 - CodeKiller - 263w ago
CodeKiller's Avatar
Quote Originally Posted by laggmaster View Post
hmm... so if i understand what i've been reading right, the hypervisor dump that we got was polluted with linux code,

actually it is the lv2 right now.. the hypervisor have been done a few weeks back.
yes, some part of it has been overwritten but hey, there is at least something to start with!
Quote Originally Posted by laggmaster View Post
another option is to figure out how to build an external chip, aka MODCHIP (i know everyone cringes at the mention as they require hardware modification but this dose too), that would somehow record and output all everything thats loaded into the ram or other chips be recoded and outputted to a computer. but this is a very complicated process and could take years.

well, it's not the cross-dump, but the content of the ram what has the problems: AFAIK the ram can be decoded by the runnung sys (thus it's encrypted)

#37 - laggmaster - 263w ago
laggmaster's Avatar
hmm... so if i understand what i've been reading right, the hypervisor dump that we got was polluted with linux code, the solution to this would be to try to rework the otheros bootstrap which would just dump the same data without the linux code mixed into it, this would require the bootstrap to load from somewhere in the memory after the 36mb of code that we actually want (possibly by moving the bootstraps load location to the hardware on a HWBC console), this should give us our golden key right?... well ok, a map to the golden key but you know what i'm saying.

another option is to figure out how to build an external chip, aka MODCHIP (i know everyone cringes at the mention as they require hardware modification but this dose too), that would somehow record and output all everything thats loaded into the ram or other chips be recoded and outputted to a computer. but this is a very complicated process and could take years.

#36 - DemonHades - 263w ago
DemonHades's Avatar
Quote Originally Posted by sapperlott View Post
Nice catch! The only problem is that the bootloader used on the PS3 is a small Linux system itself so by the time this parameter is evaluated the bootloader Linux system is already loaded into memory without any contstaints. It would be possible to re-build the bootloader image with the same parameters, though.

hi, is posible build a bld whith the ps3sdk,but the problem is the store dump file.

The sdk ps3 dont have include for mount and storage.

the best is using ethernet cable for dump,using a otheros whith it support but need included the exploit files

1saludo and yes that dump have parts linux,remember when rst don't volatilice the ram the old data mix with the new.

#35 - moneymaker - 263w ago
moneymaker's Avatar
Quote Originally Posted by sapperlott View Post
Nice catch! The only problem is that the bootloader used on the PS3 is a small Linux system itself so by the time this parameter is evaluated the bootloader Linux system is already loaded into memory without any contstaints. It would be possible to re-build the bootloader image with the same parameters, though.


Nice point, beside the LILO/GRUB he catched as an example is our case petiteboot/kboot that's better to rebuild..

Building a kernel image as small as possible and running it into the highest memory space avaliable coul make the thing easier..

Even better could be to find a way to run a minimal linux in the backward compatibility reserved memory (32MB) of some models but this, even if possible, could envolve quite more work...

#34 - sapperlott - 263w ago
sapperlott's Avatar
Quote Originally Posted by fhwk View Post
First of all, there's a few linux kernel boot options which may be useful in making sure that the kernel doesn't overwrite the first 36MB of RAM. From the kernel documentation:

memmap=nn[KMG]$ss[KMG]
Mark specific memory as reserved. Region of memory to be used, from ss to ss+nn. Example: Exclude memory from 0x18690000-0x1869ffff:
memmap=64K$0x18690000
or
memmap=0x10000$0x18690000
Nice catch! The only problem is that the bootloader used on the PS3 is a small Linux system itself so by the time this parameter is evaluated the bootloader Linux system is already loaded into memory without any contstaints. It would be possible to re-build the bootloader image with the same parameters, though.

 











Advertising - Affiliates - Contact Us - PS4 Downloads - PS4 Forums - Privacy Statement - Site Rules - Top - © 2015 PlayStation 4 News