forums.ps2dev.org

baygins · Joined: 09 Jul 2005 Posts: 7

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 · Joined: 10 Jun 2005 Posts: 1179 Location: Boston

"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 · Joined: 09 Jul 2005 Posts: 7

J.F. · Joined: 22 Feb 2004 Posts: 2906

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 · Joined: 09 Jul 2005 Posts: 7

J.F. · Joined: 22 Feb 2004 Posts: 2906

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 · Joined: 09 Jul 2005 Posts: 7

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 · Joined: 07 Feb 2007 Posts: 2

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 · Joined: 09 Jul 2005 Posts: 7

mrbeans · Joined: 07 Feb 2007 Posts: 2

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?