I hope everyone is doing well out there. I have seen some very exciting developments over the course of the last couple of days, and would like to add my own contribution.
If you remember, the 2 interesting points from the SCE file format analysis were:
SCE header has a "file size" type field that was ALWAYS 0x7bf bytes smaller than the real file size.
In the ELF portion of the file, the Section Header Table offset (Elf64_Off, e_shoff) was pointing to a non-existant location in the file.
Well, these were NOT really coincidental as our friends at $ony would like us to believe. Here is what it boils down to:
The "file size" type field (I will call it ELF RealSHT Offest from now on) is really the "Real offset of the Section Header Table in the SELF file".
Between the OtherOS.self file and the Updater.SCE files, the Section Header Tables look EXACTLY the same.
I also compiled a simple C program on my PS3 to output an ELF64 image. The SHTs look _very_ similar.
So, here's some editorial about these findings. In my opinion, $ony is trying to obfuscate things by re-arranging standard file formats and changing pointers and such. This is a typical case of "security through obscurity" and can only be maintained if people are not looking _deep_ into the data in front of them.
At the end of the day, they had a limited amount of time to _customize_ the PS3 and its ecosystem before launch. They also cannot invest in a totally new architecture and supporting bits, simply due to monetary and project timeline constraints. This is very typical of software/hardware development projects.
Do we know exactly what is in these files? Not yet. Do we know more than what we knew 2 months ago? ABSOLUTELY. I think if we go at this pace, it won't be long before we get some very interesting results.
Just keep one thing in mind: This is purely for fun. It is almost like solving a puzzle, no more, no less.
Hello again everyone. I have tried to put together my thoughts after discussing this with the geniuses we have back on our team and decided to put it out there. The purpose of this is to get some more comments from other people in the scene.
Well, I just couldn't hold myself and decided to add a very tiny bit of info on the SCE file format.
Offset 0x08 for 0x02 bytes hold a bit mask containing the status of whether the embedded ELF file image is Encrypted or Not.
To demonstrate (in binary):
|000000000000000+-> 1: Encrypted file
+-----------------> 1: Decrypted, in the clear file
[FONT=Verdana]D and E bits are mutually exclusive and cannot be set to 1 at the same time.
I am attaching an updated SCE File Format document here for everyone's enjoyment.
I noticed that of all the .selfs that we have analyzed so far all were direct from Sony so I went looking around for another self. I found it by looking at Warhawk's update. The same file we replace to provide the hack letting us put .selfs onto our system provided me with a .self made by Incognito Entertainment instead of Sony (found at http://download-prod.online.scea.com...3_release.self). The differences led me to a few very useful conclusions.
The first was the half at 0x78 (identified as ID_unk_20) instead of being 0x0001 was 0x0003 instead. This lead me to believe that it was some kind of Company ID with Sony as 0x0001 and Incognito as 0x0003.
The second thing I noticed is that the encryption flag was odd. In most situations it's either set to 10000000 or 00000001 in Warhawk's update it is set as 00000010. This stuck me as odd, and possibly a different flag (Possibly a different encryption or even a very flag) leaving neither of the known flags set.
Included is an updated .xls file with the new information along with a Hex Workshop .hls file. This file allows you to create "structures" in Hex Workshop showing you all the data we have found from the header so far.