Hi,
It has been revealed elsewhere that eboot.bin is an encrypted version of boot.bin (left in by sloppy dev's or sloppy Sony). Given that we have examples of pairs of unencrypted and encrypted binaries, maybe we should look into crypto attacks on the encryption.
EBoot.bin seems to start with the string "~PSP" and is 344 bytes longer than Boot.bin. Its possible that the first 344 bytes are a header for the encryption (ive only seen one pair.) - if these 344 bytes are similar across different pairs, that would indicate that this was the case.
Also, there are several long runs on 0x00 within the supposed header region - the first 344 bytes, which you do not find in encrypted (random looking) data. After this region, the data definately 'looks' random
If so, we would need to know what encryption alog was used, and search for any known attacks. Is this known? i know several different types of crypto have been mentioned - any dev'ers know???
George
BOOT.BIN and EBOOT.BIN
Here is the problem: AES-128 (used for most of the encryption, RSA is the other used, but it is slow) is pretty strong against known plaintext attacks. There are multiple layers of dynamic movement in the AES cipher which make it resistant. For example, an encrypted block of all 00s will look rather random on the other end. It won't even appear to be connected too heavily to the key! That is because data is shifted around, and manipulated mathematically before the key is applied, and this is done 10 times. And it isn't the same key that is applied, it is an extended version of the key that in AES-128, extends the key out to 1280 bytes in size using a rather simplistic pseudo-random number generator (it has to be pseudo, otherwise you can't recreate it on the other end).
I mentioned this earlier myself, but researched the algorithm and stared in disbelief at the level of complexity that is introduced into the data block during encryption. There are still a couple of weak points that could be strengthened in the ciper to make it really nasty, but these weak points are not strong enough to introduce weakness (each particular step in each round is pretty weak by itself, but combined the encryption is almost ungodly, as the effect reinforces each other).
- The data shifts every round is really just added obfuscation, it doesn't add huge amounts of complexity into the cipher, but with the matrix mult, shifts bits around so completely that you don't really know how to pick out a byte from the block (because bits aren't anywhere near each other)
- The matrix multiplication sufficiently, but reversibly, mangles each data column in order to obfuscate data, obscuring it from pattern-sniffing attacks which attempt to decipher information about what traces the key leaves behind in the data, since it splits bytes apart.
- The key XOR is simple: modify the data based on the key so that the key is required to decrypt it.
- The substitution box by itself is rather weak, but it completely destroys plaintext attacks when combined with the other three. Data changes in rather unpredictable patterns based on the key in the form s-box(m xor k). It seems simplistic, but yeah... it is a nasty piece of work.
AES is just too strong right now, although there is one paper of a mathematician who seems to have found an algebraic weakness in the algorithm which can be exploited with a chosen plaintext attack. However, no feasible attack on the cipher has come of the research thus far. We wouldn't fare any better, to be honest, and even so, the search space is still 2^~72 in theory. That is still not quite good enough for a realistic attempt.
We need to know more about the certificate system, and /how/ the encryption works before deciding to attack the crypto. There is possibly a way that involves working /with/ the crypto to verify our code.
I mentioned this earlier myself, but researched the algorithm and stared in disbelief at the level of complexity that is introduced into the data block during encryption. There are still a couple of weak points that could be strengthened in the ciper to make it really nasty, but these weak points are not strong enough to introduce weakness (each particular step in each round is pretty weak by itself, but combined the encryption is almost ungodly, as the effect reinforces each other).
- The data shifts every round is really just added obfuscation, it doesn't add huge amounts of complexity into the cipher, but with the matrix mult, shifts bits around so completely that you don't really know how to pick out a byte from the block (because bits aren't anywhere near each other)
- The matrix multiplication sufficiently, but reversibly, mangles each data column in order to obfuscate data, obscuring it from pattern-sniffing attacks which attempt to decipher information about what traces the key leaves behind in the data, since it splits bytes apart.
- The key XOR is simple: modify the data based on the key so that the key is required to decrypt it.
- The substitution box by itself is rather weak, but it completely destroys plaintext attacks when combined with the other three. Data changes in rather unpredictable patterns based on the key in the form s-box(m xor k). It seems simplistic, but yeah... it is a nasty piece of work.
AES is just too strong right now, although there is one paper of a mathematician who seems to have found an algebraic weakness in the algorithm which can be exploited with a chosen plaintext attack. However, no feasible attack on the cipher has come of the research thus far. We wouldn't fare any better, to be honest, and even so, the search space is still 2^~72 in theory. That is still not quite good enough for a realistic attempt.
We need to know more about the certificate system, and /how/ the encryption works before deciding to attack the crypto. There is possibly a way that involves working /with/ the crypto to verify our code.
Most of this is being discussed in the PSP - file research thread ;)
http://forums.ps2dev.org/viewtopic.php?t=1463
Also the encrypted version is not always 344 bytes longer... it depends which boot / eboot combo you're looking at..
Thread gets my lock vote
http://forums.ps2dev.org/viewtopic.php?t=1463
Also the encrypted version is not always 344 bytes longer... it depends which boot / eboot combo you're looking at..
Thread gets my lock vote