PS2 ProtoPwn (Protokernel Exploit by pcm720) - Now all PS2s are hackable via MemoryCard (MILESTONE)

Breaking News in the PS2 Scene, as a NEW MemoryCard Exploit for Protokernel PS2s (SCPH-10000, SCPH-15000, and DTL-H10000(S)) just got released!!! It took 25 years to reach this point, but NOW ALL PS2s including ALL special models (Arcade, Prototype, Debug, Consumer-model, "special/custom builds") can load Homebrew WITHOUT DISCS!

The exploit created by developer @pcm720 - who is known for "(H)OSDmenu" and NHDDL - has now titled the new MemoryCard Exploit as "ProtoPwn", This exploit will AUTOMATICALLY boots if present on the MemoryCard and it works from ANY MemoryCard so MagicGate support is not required for this Exploit to work!

You can even simply copy the Exploit "Save" to another MemoryCard, for example with the PS2's own "Browser"!

international.71e8126f72c944c3b2887685a6583cb0ef47bba48e421618b1e12bdfefff42ae.png


  • ProtoPwn
    An exploit for the Protokernel PlayStation 2 systems (SCPH-10000, SCPH-15000, and DTL-H10000(S)) that enables arbitrary code execution through a flaw in the OSDSYS Browser update code.
    Usage
    • Run make
    • Copy BIEXEC-SYSTEM to the root of your memory card
    • Copy the payload you want to run to BOOT/BOOT.ELF

    How it works
    ProtoPwn consists of a fairly simple two-stage payload and a packer tool:
    1. MBROWS replacement
      • Runs from 0x7a0000
      • Patches OSDSYS code to execute a custom function in the main thread
      • Applies the EELOAD kernel patch
      • Deinitializes OSDSYS
      • Finds the target ELF on mc0 or mc1
      • Executes the embedded ELF loader
    2. Embedded ELF loader
      • Cleans up after OSDSYS
      • Loads the target ELF
      • Resets the IOP
      • Executes the target ELF
    3. Simple packer script
      • Does the bare minimum required to get OSDSYS to accept and "decompress" our payload
      • Actually increases the file size
    The target ELF path can be modified at build-time by passing BOOT_PATH argument to make.
    BOOT_PATH must be relative to mc0/mc1, e.g. BOOT/BOOT.ELF

    Browser update
    During initialization, protokernel OSDSYS checks for a Browser (MBROWS) update manifest in mc1:/BIEXEC-SYSTEM/ and mc0:/BIEXEC-SYSTEM/.
    The manifest file is called OSBROWS and consists of just three lines:
    101 — module version, must be higher than 100
    PROTPWN — module filename, relative to `BIEXEC-SYSTEM`. Cannot exceed 7 characters
    007a0000 — module load address
    When this file exists, OSDSYS will parse it, load the specified file at 0x1000000 and decompress it to the specified load address. This module is then executed as the OSD Browser thread function.
    When this file exists, OSDSYS will parse it, load the specified file at 0x1000000 and decompress it to the specified load address. This module is then executed as the OSD Browser thread function.
    Similar to __mbr, this module must be headerless, with its entry point located at the beginning of the payload.
    For some reason, unlike system updates, the Browser update is completely unencrypted, has no intergrity or validity checks and uses a fairly unsophisitcated compression scheme that can be easily bypassed.
    Thus, it is possible to get code execution just by creating a custom payload that will run in the Browser thread.​

    Module compression
    OSD modules are always compressed. The compression scheme is block-based and structured as follows:
    <4-byte uncompressed payload length in little endian>
    <4-byte block descriptor>
    <30-byte block>
    <4-byte block descriptor>
    <30-byte block>
    ...
    The block descriptor marks whether the byte in this block is compressed and contains the byte shift and byte mask used to unpack the bytes.
    The block descriptor marks whether the byte in this block is compressed and contains the byte shift and byte mask used to unpack the bytes.
    The OSDSYS unpacker stops processing right after reaching the declared payload length, ignoring all trailing bytes.
    To bypass the compression, the uncompressed payload can be written as-is, with the length header at the start of the payload and four null bytes preceding each 30-byte block.
    See osdpack code for more details.​

    Credits


Sources & Additional Details:

.
 
Last edited by a moderator:
This is incredible. Thank you so much for further developing this. SCPH-10000 is my favorite model, and how this works is just unbelievable. Everyone clowns on Sony security, but this...
 
Everyone clowns on it, because of "Trophy: Keys achieved" or whatever and the 2 big known hacks PSN+SOE 2011 and Sony Pictures 2014.

They are not THAT bad (anymore) and others are not that much better either, nor where they back then.

Xbox Live was vulnerable as well, but MS did not stick their dick into a hornets nest and mess with the wrong people... THEIR BIGGEST FANS (from the Hacking-/Homebrew-Scene)!!!



Admittedly it is interesting though, that they left such a thing in consumer models.
 
Everyone clowns on it, because of "Trophy: Keys achieved" or whatever and the 2 big known hacks PSN+SOE 2011 and Sony Pictures 2014.

They are not THAT bad (anymore) and others are not that much better either, nor where they back then.

Xbox Live was vulnerable as well, but MS did not stick their dick into a hornets nest and mess with the wrong people... THEIR BIGGEST FANS (from the Hacking-/Homebrew-Scene)!!!



Admittedly it is interesting though, that they left such a thing in consumer models.

SCPH-10000 also released with a DVD player firmware that had broken region lock that (almost?) got them sued by the MPA. Both ProtoPWN and the DVD player region lock I can't tell if they are backdoors or just resulting from rushing to market due to the Dreamcast. Also it has the 80 minute CD-R regression that I can't tell if it was a bug or intentional.

Just in exploits alone for the 10000 you can pick from any of these now:
* Independence exploit (bug in parsing ps1 compatibility database due to strcmp)
* FreeDVDBoot (works if you update the DVD firmware, I've tried it).
* FreeMCBoot.
* ProtoPWN.
* FreeHDBoot.
* Maybe OpenTuna if anyone checks to see if it is exploitable.
* Save game exploits for PS1 (anyone ever try a PS2 game? Like Masterc0re for PS4 PS2 emu but real hardware?).
 
SCPH-10000 also released with a DVD player firmware that had broken region lock that (almost?) got them sued by the MPA.
Was it publiciced by mainstream media and known and heard of all over the world, just like those that I mentioned? No...!

Did the President of the US step on stage and talk about it, like in 2014? No...!
Also it has the 80 minute CD-R regression that I can't tell if it was a bug or intentional.
Oh? Can you elaborate what you mean?
Independence exploit (bug in parsing ps1 compatibility database due to strcmp)
It's the GPU-setting (per PS1 Game-ID in "TITLE.DB") which could exploit the non-terminated function AFAIR.
FreeDVDBoot (works if you update the DVD firmware, I've tried it).
Its NOT a "firmware", nor is it "updated" (as in "REPLACED with a newer version") but a newer version is loaded instead from for example a MemoryCard.
FreeHDBoot
Only works with the MemoryCard as Kickstarter, not directly.
Maybe OpenTuna if anyone checks to see if it is exploitable.
Already checked... No it doesn't work, because it does not have RLE and hence no RLE-Vulnerability to exploit.
Save game exploits for PS1 (anyone ever try a PS2 game? Like Masterc0re for PS4 PS2 emu but real hardware?).
There are some, but Network-exploits are more interesting IMO.
 
Was it publiciced by mainstream media and known and heard of all over the world, just like those that I mentioned? No...!.

* DVD Player Hack. (ad warning). But this was a huge thing back then Can't find the source because search engines are trash in current year, but there was a sony program to swap out the old dvd firmware install discs with new ones at 7/11 too at the time IIRC.

Did the President of the US step on stage and talk about it, like in 2014? No...!

Got me there...

Oh? Can you elaborate what you mean?

The webpage I linked sums it better but basically there was this issue on the original PS1 where it uses a static seek table for 71 minute CD-Rs/CD-ROMs no matter what the actual capacity of the CD-R is. This leads to slower seeking on 74 min and 80 min media due to overseeking beause the spiral windings of 80 minute media being way more densly packed. The craziest thing is every released game works fine on ps1, but on early ps2s they somehow handled it worse and many games are unplayable without patching or special seeking during loading the boot exe and system.cnf at least to prevent an overseek by doing it in small steps (Tonyhax International proved this was possible with software).

I say I don't know if it was intentional because even PS2 software that is CD-ROM is 71 minute density, and this is kinda a brilliant way to prevent piracy because you literally had to have that capacity of CD-ROM (or at least 74 minute which is closer) to make a working backup until I developed the patcher/tonyhax international workaround. This applies to PS2 CD-ROM games too, and even back in the day mod-chips would say "80 min PS2 CD-Rs not working" and whatnot, also they fixed this in SCPH-50000+.

It's the GPU-setting (per PS1 Game-ID in "TITLE.DB") which could exploit the non-terminated function AFAIR.

Yup, good old strcmp parsing.

Its NOT a "firmware", nor is it "updated" (as in "REPLACED with a newer version") but a newer version is loaded instead from for example a MemoryCard.

SCPH-10000 and SCPH-15000 are special. They shipped with no DVD firmware. It was only possible to play DVDs by first booting a Sony CD-ROM that installed a firmware to the memory card. Nothing on board. (Again, rush to beat dreamcast IMO). I guess the more correct term is "DVD Player" here.

Only works with the MemoryCard as Kickstarter, not directly.

Got me there.

Already checked... No it doesn't work, because it does not have RLE and hence no RLE-Vulnerability to exploit.

Thanks for verifying.
 
Last edited:
@TnA Hehe. I just remembered, the CD Player Swap Trick which is what inspired Tonyhax International. I guess we clown on sony security for different reasons. Also there anti-piracy detection stuff couldn't even work on launch consoles, and I actually used that as a backdoor to remove the protection on all later consoles!


They got wayyyy better with PS3, but still to this day we have the miracle that is BadUpdate for 360 and nothing comparable for any recent Microsoft console. As for sony, I'm in the market for a PS4 and PS5 on specific os versions:)
 
What does ProtonPWN help me do that I can't already do?

For example, I use Fortuna and OPL Loader loaded into my memory card to play PS2 backups stored in my computer hard drive. Additionally, once I get another lens for my PS2, I can play PSX backups and PS2 import games on my PS2. AND, additionally, I can play burnt PS2 backups that pass off as video DVDs from the patcher.

Looks like I already have what I need.
 
What does it actually do then? Wouldn't "arbitrary code execution" include playing out of region discs?

No the original intention is to run unsigned code first before backup launchers, that's just a consequence of maybe breaking DRM, remember modchips where based on executing code from disc or cartridge not firmware or save data exploitation an if your old enough to remember turbo loaders for tape & floppy disk.
 
No the original intention is to run unsigned code first before backup launchers, that's just a consequence of maybe breaking DRM, remember modchips where based on executing code from disc or cartridge not firmware or save data exploitation an if your old enough to remember turbo loaders for tape & floppy disk.
Is there any payloads that do anything useful for it yet then?
I don't want to modchip mine because that requires soldering and that's a major pain
 
Is there any payloads that do anything useful for it yet then?
I don't want to modchip mine because that requires soldering and that's a major pain

Use uLE as the BOOT.ELF it's the main way of launching other ELFs outside the OSD & a File Manager, once you have uLE running you can use it to run a backup launcher like OPL etc.
 
I've been following this exploit for a while, but I know that FMCB works on my SCPH-10000, 15000 & 18000 for like the past 8 years.

I'll be checking this out when I get a chance to pull one of my consoles out.
 
Advantage in these models over OSD Update is mainly one: no signing per card. User can freely copy exploit stuff to another card and stil will work. If you have working FMCB environment and doesn't care about what I written above and eventually OSDM unique features, then there is no reason for change.
 
Advantage in these models over OSD Update is mainly one: no signing per card. User can freely copy exploit stuff to another card and stil will work. If you have working FMCB environment and doesn't care about what I written above and eventually OSDM unique features, then there is no reason for change.

the signing thing is huge to me tbh. Does everyone remember Sony taking down PSCMCA-Tool? You have to go to sketchy websites to even get it because Sony used weak encryption and regretted it…They decided the appropriate response was legal action. At last we have a way to stick it to them with no legal recourse… You can't copyright something that literally accepts zeros as checksum because it's so broken. Maybe you shouldn't of rushed to kill the Dreamcast?

In some ways, this is kinda the same scenario for freepsxboot on the PS1. Yes it can be the easiest method but if you want to use the same memory card for well, memory card things you use a different exploit method that allows that beside Freepsxboot
 

Similar threads

Back
Top