An idea about kernel mode for 2.0

[sherpya]

My idea could be totally wrong, but I want to expose it so I can get comments about it.

Step 1
find a way to patch game_plugin or other involved prx to make load unencrypted eboots. This can be eventually tested using a firmware emulator.

Step 2
prx are encrypted and then compressed or vice-versa? anyway
we can find the point where the patch should be placed in the encrypted
prx, then we can brute force few bytes to make the correct encryption,
and check if the resulting file is correctly decrypted (I dunno much about the psp encryption, but excluding the compression it should be byte by byte encryption so the brute force method could work).

Step 3
make a patch to the encrypted prx so the unencrypted one will be correcly extracted and patched to load unencrypted eboots

Step 4
modify the corresponding prx in the flash by using the tiff exploit

Step 5
don't shot me if what I said is totally wrong :)

[GameShark]

you cant edit the prx's
This would remove the encription

Your Result would most likely be a bricked flash

[ryoko_no_usagi]

There are unencrypted PRXs though, no? And didn't someone here try to replace just such a PRX to get kernel access on 2.0, although the result was indeed a brick, but not because the concept itself is flawed I think.

Bruteforcing encryption is nonsense though.

[TyRaNiD]

The kernel doesn't like to load unencrypted prx files, and I think there is only one unencrypted prx in flash (at least in v1/1.5) and that is a user mode one anyway.

[ryoko_no_usagi]

Hrmm, seems I completely misremembered:

http://forums.ps2dev.org/viewtopic.php? ... fbf7849037

[sherpya]

I was not so clear... I don't want to use unencrypted prx, I was thinking about patch the unencrypted and see if it works, using an emulator, then
find (by brute forcing bytes) to make an "encrypted" patch to the prx.
So we can have a correctly encrypted patched prx, we don't known the private key, but we known the public to decrypt and the decryption algo, so we can test all combinations of few bytes (the bytes involved in the patch) until a correctly encrypted output is found

[romero126]

I just thought you should know that only Kernel mode allows the editing of PRX's within the Flash memory. Which means you are not allowed copy files over the existing PRX's since being in user mode does not allow this. I would suggest that idea for an emulation. But other than that, I would say its impossible without gaining Kernel mode before hand.

[Shine]

so we can test all combinations of few bytes (the bytes involved in the patch) until a correctly encrypted output is found

This won't work, because if you change one byte, the bytes after this byte have to be changed, too, to reproduce the same unencrypted bytes as before. Assuming a 64 byte block crypting, you have to test 64 bytes, which means 2^(64*8) possiblities, which is 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084096, which needs about 4*10^140 years, if you can test 1 million combinations per second.

[sherpya]

so we can test all combinations of few bytes (the bytes involved in the patch) until a correctly encrypted output is found

This won't work, because if you change one byte, the bytes after this byte have to be changed, too, to reproduce the same unencrypted bytes as before. Assuming a 64 byte block crypting, you have to test 64 bytes, which means 2^(64*8) possiblities, which is 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084096, which needs about 4*10^140 years, if you can test 1 million combinations per second.

Ok, I was searching for such info :) but I don't want the file to be encrypted like the original, I was thinking about a new encrypted prx,
but also a valid encrypted file. Anyway I think that your explanation applies also for this.
btw can we find the exact block size of psp encryption?

@romero126
yes, but this problem is secondary right now :), anyway it would be
intresting to find a way to make 2.0 handle non encrypted eboots
This can be usefull if someone finds a way to patch the startup code then
the module loader