- Code is compiled on a GCC toolchain, this means at least a libc is available.
HTTP GET revealed a libhttp mention in user agent, this could mean shared libraries.
On pulic pages from Metrowerks, one could read of some PRX and elf formats.
Compression tests could hint for compressed executables (or ciphered).
Hexdumps on PARAM.SFO, showed binary data associated to file list, and params on same offsets.
The Wipeout Pure update shows a .WAD file not "managed" from the .SFO file, but a simple 16 byte, DATA.BIN
The EBOOT.PBP url, carries a md5 hash for the file on the url - It's the first hashing I saw matched.
.SFO file have structure, an header, offsets and sizes. Maybe the not yet decoded fields are types/string direction, endianess?
What decompression tests have been done, there should be some know structure, maybe the binary data on .SFO are tables for decompression, or hashes to sign. Following the GNU way... zlib anyone?
Given the savegames, several saves with a game that doesn't changes any parameters (another thread showed an adventure game that changed time), one could try to compare in order to brute force the criptography. Isn't this ilegal in a lot of countries? :)
The block like repetion observed by some on the PSAR file could lead to be just common code (maybe firmware graphics headers) and due to compression showed almost the same over the file.
The download.pspdif file is another clue in the deck... Isn't 16 bytes padded, doesn't have a .SFO to "key" it in some kind of encryption, at least in a proper Initialization Vector. I also suggest there should be there the downloaded filename, data.pspdat. This file being a ZIP file, could indicate a, game encoded or PSP provided, compression library available.
Later findings...
Some believe that a public key (Or more a Diffie-Hellman) key exchange is done so the AES key varies with the publisher. If so, the AES key required is farther way in terms of finding it. Only a clever hardware based hack could break this... and after all the past consoles hacks it should be too hard, chips and buses can prove more dificult to bypass.
Test made to the several random bits of information on various files, showed no signs of being a AES-128 (or 256, or other ciphers) keys or IV's. Most of them using openssl gave a bad decode to all tries.
Bruteforcing an AES key, only by using some kind of distributed effort... and even then, we needed someway to validate the decode (either a message digest - some of the random data areas, or two equal data files, or some statistical string analysis). After that finding the public key variant or creating is equally impossible.
But rambling on public-key... The Sony press release that states AES 128, on the UMD disc encryption... does not mention a public-key implementation for the key exchange.
But... if Sony did really encoded a public-key, this could mean a simple and easy way for a public development community.
