| View previous topic :: View next topic |
| Author |
Message |
sherpya

Joined: 03 Oct 2005 Posts: 61
|
Posted: Mon Jan 09, 2006 10:23 pm Post subject: An idea about kernel mode for 2.0 |
|
|
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 :) |
|
| Back to top |
|
 |
GameShark
Joined: 01 Dec 2005 Posts: 12
|
Posted: Tue Jan 10, 2006 12:50 am Post subject: |
|
|
you cant edit the prx's
This would remove the encription
Your Result would most likely be a bricked flash |
|
| Back to top |
|
 |
ryoko_no_usagi

Joined: 29 Nov 2005 Posts: 65
|
Posted: Tue Jan 10, 2006 4:47 am Post subject: |
|
|
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. |
|
| Back to top |
|
 |
TyRaNiD
Joined: 18 Jan 2004 Posts: 918
|
Posted: Tue Jan 10, 2006 4:53 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
 |
ryoko_no_usagi

Joined: 29 Nov 2005 Posts: 65
|
|
| Back to top |
|
 |
sherpya

Joined: 03 Oct 2005 Posts: 61
|
Posted: Tue Jan 10, 2006 8:49 am Post subject: |
|
|
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 |
|
| Back to top |
|
 |
romero126
Joined: 24 Dec 2005 Posts: 200
|
Posted: Tue Jan 10, 2006 12:37 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
 |
Shine
Joined: 03 Dec 2004 Posts: 728 Location: Germany
|
Posted: Tue Jan 10, 2006 1:52 pm Post subject: |
|
|
| sherpya wrote: | | 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. |
|
| Back to top |
|
 |
sherpya

Joined: 03 Oct 2005 Posts: 61
|
Posted: Tue Jan 10, 2006 4:26 pm Post subject: |
|
|
| Shine wrote: | | sherpya wrote: | | 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 |
|
| Back to top |
|
 |
|