Decoding "otheros.self" on PS3

baygins · Post by **baygins** » Tue Jan 30, 2007 12:57 am

I have been playing with the "otheros.self" file and have pretty much have figured out that the initial few bytes contain the Sony Computer Entertainment magic word "SCE". After that comes the standard-looking "0x7F-ELF" magic bytes.

I tried to decode the ELF header portion to find the Section Headers, however, the section header offset (0x0000000000DF2548) was pointing to an address much larger than the file size. My purpose in doing this is to figure out what "otheros.self" file is doing.

Any Linux experts out there? Help?

jimparis · Post by **jimparis** » Tue Jan 30, 2007 2:48 am

"otheros.self" is not a Linux program. It runs under the Game OS and as such it's most likely encrypted and signed by Sony. The majority of the file looks this way (high entropy, uncompressable).

baygins · Post by **baygins** » Tue Jan 30, 2007 2:55 am

jimparis wrote:"otheros.self" is not a Linux program. It runs under the Game OS and as such it's most likely encrypted and signed by Sony. The majority of the file looks this way (high entropy, uncompressable).

I would agree that there is some encryption, but if you take the "SCE" signed first few dozen bytes off, then you are left with what looks like a regular ELF file.

It has the proper ELF signature and it seems like it has proper ELF header info.

Most of the meta data (machine type, bit-width: 64, LSB/MSB stuff) looks right. So if most of the info on the ELF header is right, then why would the Segment Header offset data not be right (even the Program Header offset looks to be right)?

J.F. · Post by **J.F.** » Tue Jan 30, 2007 5:06 am

Seeing as the core processor is a PPC, it probably runs in big-endian mode. Make sure you aren't trying to read addresses in little-endian mode.

baygins · Post by **baygins** » Tue Jan 30, 2007 5:13 am

J.F. wrote:Seeing as the core processor is a PPC, it probably runs in big-endian mode. Make sure you aren't trying to read addresses in little-endian mode.

I believe the ELF header is endian-unaware? So, when we talk about the Section Header offset, which is supposed to be 8 words (since this is a 64 bit architecture), reading a byte stream of [0000000000DF2548] would translate to an address of 0x0000000000DF2548, right?

J.F. · Post by **J.F.** » Tue Jan 30, 2007 6:15 am

There should be a code in the header that tells the endianness as well as the size and processor. But yes, that looks like a BE 64bit value there. Maybe it's a virtual address as opposed to a physical address.

baygins · Post by **baygins** » Tue Jan 30, 2007 10:56 am

I am "totally" speculating that it could be a round-the-file-and-back wrap around offset. So if the file is 100 bytes, but the offset is 250 bytes, it literally means "go around the file twice and then 50 some more bytes".

Is there anyone who has coded on the PPC64 platform to comment on this?

mrbeans · Post by **mrbeans** » Wed Feb 07, 2007 4:19 am

Portions of the file are both compressed and encrypted. The compression of the file will make legitimate values in the ELF header to appear wrong (out of bounds.)

If you look at the qword at 0x0018 you'll find what appears to be the file size before signing, compression, encryption, etc. This value is something like 0x00DF2D08, which is larger than your section header offset above.

Any data after 0x03e0 is probably garbage without decoding, or in the wrong spot (~0x0149548 onwards -- the data pointed to by qword 0x0040)

So I guess I'm saying it's not going to wrap around the file ;)

baygins · Post by **baygins** » Wed Feb 07, 2007 7:46 am

mrbeans wrote:Portions of the file are both compressed and encrypted. The compression of the file will make legitimate values in the ELF header to appear wrong (out of bounds.)

If you look at the qword at 0x0018 you'll find what appears to be the file size before signing, compression, encryption, etc. This value is something like 0x00DF2D08, which is larger than your section header offset above.

Any data after 0x03e0 is probably garbage without decoding, or in the wrong spot (~0x0149548 onwards -- the data pointed to by qword 0x0040)

So I guess I'm saying it's not going to wrap around the file ;)

Sounds very logical actually. Are there methods/tools to figure out if/what kind of compression/encryption is being used in a file based on the byte stream?

mrbeans · Post by **mrbeans** » Wed Feb 07, 2007 1:06 pm

There are certainly methods to figure this out. It would help if there were a wealth of other files to compare it against.

It would make sense that compression would come before encryption (as encrypted data is usually harder to compress.) Figuring out what type of compression algorithm is difficult as there likely isn't any compressed non encrypted data. It can't be too shabby though, as it appears to have done a good job.

Because of the compression + encryption, there likely isn't any good plain text knowledge to take advantage of either. My encryption skills are out of date. Keys will likely not be in the file but be in the firmware; likewise decryption could easily be implemented with hardware for speed reasons. If we could create our own files this would be significantly easier.

I think the best bet is to figure out more of what is around the encryption to get a better idea of what to expect and where inside the encryption. For instance, is the entire elf header in plain text, is it duplicated in the encrypted data?