Sponsored Links

Sponsored Links

Page 1 of 2 12 LastLast
Results 1 to 10 of 13



Thread: SCE File Format

  1. #1
    Contributor HanSooloo's Avatar
    Join Date
    Mar 2007
    Posts
    33
    Sponsored Links

    Lightbulb SCE File Format

    Sponsored Links
    Since the ScanHdd analysis work has cooled off a little bit, I decided to turn my attention to the file format used by $ony. Specifically, I looked at the OtherOS.self and updater.sce files.

    Here are some findings:
    1. SCE file format has 0x90 bytes of header at the beginning of the file.
    2. There is a "SCE\0" magic marker at the beginning of the file.
    3. The SCE header length seems to be mentioned at 0x30.
    4. The file size is stored as 0x7bf bytes smaller than what it is at 0x40.
    5. There IS an ELF image in both files starting at exactly 0x90 bytes into the file (right after the header).
    6. ELF image checks out fine except for the following issues:
      1. OS ABI version is of unknown type (0x66)
      2. Segment header table's offset is waaay out of bounds relative to file size (0xDF2548 for the otheros.self file that is only 0x149D07 bytes)
      3. Therefore, we cannot determine what sections exist in the file (.text, .init, .data, etc.)
    There seems to be a lot of relative pointers within the file (offset values).

    Also, there are file size related values. I have not been able to decipher them yet, help is welcome.

    There is a 16 byte block that is exactly the same at the beginning of the ELF section, after (what seems to be) more program header/section header/segment header tables:

    [Register or Login to view code]

    Attached Files Attached Files

  2. #2
    Contributor nonomia's Avatar
    Join Date
    May 2007
    Posts
    2
    Sponsored Links

    Post SCE File format

    Sponsored Links
    HI, this is the simple description about the SCE file format.
    I'm not sure this informatin is correct or not.


    Typical Header


    00000000h 53 43 45 00 ID 'SCE/00'
    00000004h 00 00 00 02 xx
    00000008h 00 00 00 03 TYPE of FILE
    0x02 application
    0x03 firmware/system software
    0000000ch 00 00 00 00 xx
    00000010h 00 00 00 00 00 00 02 80 length of header
    00000018h 00 00 00 00 00 1E 01 10 length of data block

    00000280h 00 00 00 03 SAVING LOCATION00000284h 00 00 00 07 APPLICATION FORMAT
    00000288h 00 00 00 00 00 00 00 01 APPLICATION INDEX (Firmware)
    00000290h 00 01 00 60 VERSION or DATE
    00000294h 00 00 00 00 BUILD
    00000298h 00 00 00 00 00 1E 00 90 length of code
    000002A0h 00 00 00 00 00 1E 00 90 length of code - compressed
    000002A8h 00 00 00 00 00 00 00 00
    000002B0h 00 00 00 00 00 00 00 00
    000002B8h 00 00 00 00 00 00 00 00
    000002C0h 00 00 00 00 00 00 00 03
    000002C8h 00 00 00 00 00 00 00 40
    000002D0h 00 00 00 00 00 00 00 00
    000002D8h 00 00 00 00 00 1E 00 90 length of code
    000002E0h 00 00 00 00 00 00 00 01
    000002E8h 00 00 00 00 00 00 00 01
    000002F0h 00 00 00 00 00 00 00 00
    000002F8h 00 00 00 00 00 00 00 00


    There are couple of data format


    MASTER HEADER
    SIGNATURE 53 43 45 00 'SCE\x00'
    xx 00 00 00 02
    TYPE 00 00 00 03

    03 fireware/system software
    02 applicaton

    xx 00 00 00 00
    LENGTH_OF_HEADER 00 00 00 00 00 00 00 00
    LENGTH_OF_DATA 00 00 00 00 00 00 00 00

    DATA HEADER for TYPE = 2
    xx 00 00 00 04
    xx 00 00 00 01
    xx 00 01 00 00 00 00 00 00
    NUMBER_OF_BLOCK 00 00 00 00 ' LENGTH OF BLOCK = 20h
    xx 00 00 00 00
    xx 00 00 00 00 00 00 00 00


    DATA HEADER for TYPE = 3
    SECTION 00 00 00 03
    FORMAT 00 00 00 07
    INDEX 00 00 00 00 00 00 00 01
    format 8 00 00 00 00 00 00 0B 8E

    FORMAT 7
    VERSION_MAJOR 00 01
    VERSION_MINIOR 00 60
    VERSION_BUILD 00 00 00 00
    LENGTH_OF_CODE 00 00 00 00 00 00 00 00
    LENGTH_OF_CODE_COMPRESSED 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 03
    xx 00 00 00 00 00 00 00 40
    xx 00 00 00 00 00 00 00 00
    LENGTH_OF_CODE_DECOMPRESSED 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 01
    xx 00 00 00 00 00 00 00 01
    xx 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 00

    FORMAT 3 or 4
    DATE 20 07 03 25 ' BCD
    BUILD 02 50 21 00 ' BCD
    LENGTH_OF_CODE 00 00 00 00 00 00 00 00
    LENGTH_OF_CODE_COMPRESSED 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 03
    xx 00 00 00 00 00 00 00 40
    xx 00 00 00 00 00 00 00 00
    LENGTH_OF_CODE_DECOMPRESSED 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 01
    xx 00 00 00 00 00 00 00 01
    xx 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 00

    FORMAT 8
    DATE 20 07 03 25 ' BCD
    BUILD 02 50 21 -- ' BCD
    LENGTH_OF_CODE 00 00 00 00 00 00 00 00
    LENGTH_OF_CODE_COMPRESSED 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 03
    xx 00 00 00 00 00 00 00 40
    xx 00 00 00 00 00 00 00 00
    LENGTH_OF_CODE_DECOMPRESSED 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 01
    xx 00 00 00 00 00 00 00 01
    xx 00 00 00 00 00 00 00 00
    xx 00 00 00 00 00 00 00 00

  3. #3
    Toucan Sam CJPC's Avatar
    Join Date
    Apr 2005
    Posts
    2,174
    Sponsored Links
    Sponsored Links
    Added and Merged, thanks!

  4. #4
    Contributor HanSooloo's Avatar
    Join Date
    Mar 2007
    Posts
    33

    Lightbulb Updates on SCE File Format

    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:
    1. SCE header has a "file size" type field that was ALWAYS 0x7bf bytes smaller than the real file size.
    2. 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:
    1. 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".
    2. Between the OtherOS.self file and the Updater.SCE files, the Section Header Tables look EXACTLY the same.
    3. 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.
    Attached Files Attached Files

  5. #5
    Contributor HanSooloo's Avatar
    Join Date
    Mar 2007
    Posts
    33
    UPDATE: Just a quick update to the file format map combining the SCE, ELF and relocated Section Header Table.
    Attached Files Attached Files

  6. #6
    Contributor courier's Avatar
    Join Date
    May 2005
    Posts
    14
    Great work hansooloo!

  7. #7
    Contributor nonomia's Avatar
    Join Date
    May 2007
    Posts
    2
    Great!!! hansooloo.

    I guess id_unk_01 is the file format/type of SCE.
    I believe SCE stucture is changed by this code.

  8. #8
    Contributor HanSooloo's Avatar
    Join Date
    Mar 2007
    Posts
    33

    Post SELF File Loading Process

    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.

    So, enjoy!
    Attached Thumbnails<br><br> Attached Thumbnails

    SELF File Loading.PNG  

  9. #9
    Contributor HanSooloo's Avatar
    Join Date
    Mar 2007
    Posts
    33

    Post Updates on SCE File Format

    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):
    Dxxxxxxx xxxxxxxE
    |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.

    Take care all
    [/FONT]

    Han Sooloo
    Attached Files Attached Files

  10. #10
    Contributor nikkelitous's Avatar
    Join Date
    May 2007
    Posts
    7
    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 [Register or Login to view links]). 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.
    Attached Files Attached Files

 

Sponsored Links
Page 1 of 2 12 LastLast
Advertising - Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News