We thought that we really “owned” our PS3 console this time, but we technically aren’t. Why is that? Isn’t Geohot did the right thing by releasing his very first jailbreak CFW for the PS3 which leads to the signing of 3.41 homebrews?
Well, the issues has been discuss lately with the lack of NPDRM infos, keys etc from Geohot, the devs has been facing a hard time to touch the “important” part of the PS3 security. That part also happens to be the area where you can lighten up the pirates.
So, we had a few respected people in the scene looking at ways to find Geohot’s best kept secret including stoker25 from PSX-Scene forum.
Can somebody upload the geohot-patched nas_plugin.sprx? His PS3UPDAT.PUP doesn’t contain it, seems that his custom ps3swu.self file does all that magic. If we compare the normal 3.55 nas_plugin to his patched one we should be able to figure out what he changed, maybe finding the original NPDRM keys in the process ;D
Then NTAuthority with his “attack”
I’ve been trying a hybrid between a dictionary attack and a bruteforce attack on the NPDRM keys today — sadly no result has been turned up in the first few files I expected.
As geohot released both a plain text key (for the AES implementation to use) and an encrypted key (for the PS3 to decrypt), and as it’s known Sony has the key used for decrypting this in some of the data, I used an application (messy C# code) to interpret every 48-byte pair in various files as a 32-byte key/16-byte IV, encrypt the plain text, and compare the encrypted data to geohot’s key.
Sadly, this has resulted in nothing when ran on (decrypted, obviously) SELFs in a) CORE_OS_PACKAGE.pkg and b) /sys/internal/ in dev_flash, which might be for one of the following reasons:
1) the IV doesn’t immediately follow the key, like with the normal key/IV pairs (in appldr, for instance) — this could increase processing time anywhere from *2 to ^2.
2) the key isn’t in any of the locations I checked — for instance, Waninkoko mentioned (regarding the PSP keys) a file named ‘spu_handler.isoself’, which I can’t find in any of those 2 locations.
3) there’s an implementation bug in my code, though I tested it by encrypting a random set of plaintext data with the appldr 3.15 key/IV (using the openssl command line, with similar parameters to geohot’s commented out code) and running appldr through my code — it found the key/IV. it could be geohot’s commented code is intentionally wrong to hamper people going from it for finding out the key… which would be annoying.
well, not going to go try IV offsets, as I assume it’s in some SELF I don’t know about
Hermes, Naima, and Waninkoko also had a few discussions in Elotrolado forum about this NPDRM thingies.