Cracking PSP Encryption
word
...and those 2 million computers will be nop'ing into oblivion because no one has any worthwhile code for them to run... I'd trade all that for a single bunnie. I think modrobert is right and PspPet is right, and until some hardware guys get in there and start getting some real data, we're all just wanking off. I'm all for spirited discussion, but I'm also for efficient use of resources.
Bruteforcing a crypto algorithm should always be seen as a last resort, when no "shortcuts" were found, i.e. exploits, leak or weakness in the protection scheme or hardware hack, attacking AES-128 could certainly be accomplished by a small government with enough processing power (US, Japan, China, Russia or any EU country) but certainly not by individuals, even in a distributed.net way. AES-128 is "too hard to break" for our workstations (even x100.000) at this point.
I doubt Sony didn't introduce any 'bug' in their code, that we could take advantage of, they're good, but they're not THAT good.
I doubt Sony didn't introduce any 'bug' in their code, that we could take advantage of, they're good, but they're not THAT good.
Hey fellas,
Ive been looking though this thread.. and you cant even imagine how lost i am.. so i did some research and found this interesting article on the AES encryption..
heres an interesting little part they had on cracking something like this
heres the link to the article:
http://csrc.nist.gov/CryptoToolkit/aes/aesfact.html
Ive been looking though this thread.. and you cant even imagine how lost i am.. so i did some research and found this interesting article on the AES encryption..
heres an interesting little part they had on cracking something like this
I highly doubt anyone is going to get even close to cracking this... The article also goes on to say that the U.S. Govt. uses this to encrypt important files ..... so im guessing this is some real complex stuff..heheh# What is the chance that someone could use the "DES Cracker"-like hardware to crack an AES key?
In the late 1990s, specialized "DES Cracker" machines were built that could recover a DES key after a few hours. In other words, by trying possible key values, the hardware could determine which key was used to encrypt a message.
Assuming that one could build a machine that could recover a DES key in a second (i.e., try 255 keys per second), then it would take that machine approximately 149 thousand-billion (149 trillion) years to crack a 128-bit AES key. To put that into perspective, the universe is believed to be less than 20 billion years old.
heres the link to the article:
http://csrc.nist.gov/CryptoToolkit/aes/aesfact.html
-
originalself
- Posts: 9
- Joined: Sat Apr 09, 2005 3:53 am
-
ChaosKnight
- Posts: 142
- Joined: Thu Apr 14, 2005 2:08 am
- Location: Florida, USA
I wonder if hardware modification really is the only way.
Lately, I (among others i'm sure) have been looking carefully and the PSP and PSAR files. Both of them seem to share some things in common:
1) They are both suspected of being encrypted. This is a perfectly valid assumption IMHO due to how few runs of similar bytes are in the file as a whole. (Don't believe me? Tack .RAW onto the end of a file and open it in Photoshop, look at the histogram, then do the same to an unencrypted file. You will see a huge difference.)
2) They both seemto have a header. Aside from the general lack of runs, if you only look at the top portion of the file there seems be be quite a few 00 runs, indicating an unencrypted header.
How does this header help us? Possibly not at all. However I seem to remember someone saying there's a possibility that Sony uses a public key to unencrypt a private key in the main executable. If that's the case then the header would undoubtedly contain said private key.
Just something I thought of this morning. It may be of little consequence or it may help someone. Just putting it out there.
PSP: Header seems to end around 0xd2
PSAR: Header seems to end much earlier (maybe 0x0f?)
Lately, I (among others i'm sure) have been looking carefully and the PSP and PSAR files. Both of them seem to share some things in common:
1) They are both suspected of being encrypted. This is a perfectly valid assumption IMHO due to how few runs of similar bytes are in the file as a whole. (Don't believe me? Tack .RAW onto the end of a file and open it in Photoshop, look at the histogram, then do the same to an unencrypted file. You will see a huge difference.)
2) They both seemto have a header. Aside from the general lack of runs, if you only look at the top portion of the file there seems be be quite a few 00 runs, indicating an unencrypted header.
How does this header help us? Possibly not at all. However I seem to remember someone saying there's a possibility that Sony uses a public key to unencrypt a private key in the main executable. If that's the case then the header would undoubtedly contain said private key.
Just something I thought of this morning. It may be of little consequence or it may help someone. Just putting it out there.
PSP: Header seems to end around 0xd2
PSAR: Header seems to end much earlier (maybe 0x0f?)
w00t
-
ChaosKnight
- Posts: 142
- Joined: Thu Apr 14, 2005 2:08 am
- Location: Florida, USA
Quick Test Results:
Control Test:
1) Created PBP with Firmware Updater SFO + Custom Icon. No PSP, PSAR, or anything else.
2) Ran it.
Result: Error code 80020130
Modified Test:
1) Extracted header from PSP file from firmware updater (0x00 - 0xd2 [210 bytes])
2) Injected it into PBP with firmware updater SFO + Custom Icon
3) Ran it
Result: Error code 80020001
Second Control Test
1) Injected a PNG file where the PSP was supposed to be in the modified test.
2) Ran it
Result: Error code 80020001
Summary:
That 210 bytes doesn't seem to be enough to trick the PSP into thinking the file is executable. It's more likely that the PSP's OS does some more extensive checking in order to determine if the file format is valid or not.
I wish I had a sheet that told me what the error codes mean, but for now this is my assumption:
80020130 - Executable is 0 length.
80020001 - Executable is invalid.
Of course this brings up another interesting point. If the firmware does contain mini-programs (APIlets?) perhaps the offset trick with the text might be modified so that we can make the PSP read code. Of course that would require the firmware to have .PSP files as code modules and also wewouldn't be able to run anything other than what we already know the offsets for.
Interesting.
or not.
Control Test:
1) Created PBP with Firmware Updater SFO + Custom Icon. No PSP, PSAR, or anything else.
2) Ran it.
Result: Error code 80020130
Modified Test:
1) Extracted header from PSP file from firmware updater (0x00 - 0xd2 [210 bytes])
2) Injected it into PBP with firmware updater SFO + Custom Icon
3) Ran it
Result: Error code 80020001
Second Control Test
1) Injected a PNG file where the PSP was supposed to be in the modified test.
2) Ran it
Result: Error code 80020001
Summary:
That 210 bytes doesn't seem to be enough to trick the PSP into thinking the file is executable. It's more likely that the PSP's OS does some more extensive checking in order to determine if the file format is valid or not.
I wish I had a sheet that told me what the error codes mean, but for now this is my assumption:
80020130 - Executable is 0 length.
80020001 - Executable is invalid.
Of course this brings up another interesting point. If the firmware does contain mini-programs (APIlets?) perhaps the offset trick with the text might be modified so that we can make the PSP read code. Of course that would require the firmware to have .PSP files as code modules and also wewouldn't be able to run anything other than what we already know the offsets for.
Interesting.
or not.
w00t
Interesing tests ChaosKnight..... :)
What i find most interesting is that the modified test with the PSP header amd the second control test with the PNG a an "executable" (if i get it right) both wield to the same errorcode....
I would have thought that with a correct header and missing data part you'd get a different error (CRC-error) then with a non valid exe file.....
What i find most interesting is that the modified test with the PSP header amd the second control test with the PNG a an "executable" (if i get it right) both wield to the same errorcode....
I would have thought that with a correct header and missing data part you'd get a different error (CRC-error) then with a non valid exe file.....
-
ChaosKnight
- Posts: 142
- Joined: Thu Apr 14, 2005 2:08 am
- Location: Florida, USA
That was my feeling as well, which is why I performed the second control test before posting my results. Last night I was looking at the file again and the "header" area does seem to contain some offsets, including what looks like a file length value. Although it may be purely coincidental. It would really pay off to have at least two programs that run from the memory stick.
w00t
Indeed there is the file size in the header. Its 0x28 to 0x2b....
For some header info you can check also here:
http://www.psp-linux.org/forums/index.p ... #entry1748
Hope this is helpfull.... and keep up the good work ChaosKnight
For some header info you can check also here:
http://www.psp-linux.org/forums/index.p ... #entry1748
Hope this is helpfull.... and keep up the good work ChaosKnight
-
ChaosKnight
- Posts: 142
- Joined: Thu Apr 14, 2005 2:08 am
- Location: Florida, USA
Thanks Mel. The discussion got carried over to this thread http://forums.ps2dev.org/viewtopic.php?t=1462, and then finally ended up here http://forums.ps2dev.org/viewtopic.php?t=1463.
Please feel free to use the PSP File Research thread for anything you find.
Please feel free to use the PSP File Research thread for anything you find.
w00t
