otheros.self feel to be elf file ...
otheros.self feel to be elf file ...
it feels to be an elf file with an 0x90 header length....
titof
Yes, it is a sce + elf file
otheros.self <- "self" mean sce and elf
if you remove the sce header, the remain is a elf file. You can use readelf to read some headers information. (You must use ppu-readelf or spu-readelf to get the correct info)
Ps3 introduction some new sections to combine ppu bin and spu bin (CESOF), you can get more detail from CEBA handbook - "about Object" section.
otheros.self <- "self" mean sce and elf
if you remove the sce header, the remain is a elf file. You can use readelf to read some headers information. (You must use ppu-readelf or spu-readelf to get the correct info)
Ps3 introduction some new sections to combine ppu bin and spu bin (CESOF), you can get more detail from CEBA handbook - "about Object" section.
It was my understanding that the .self files were compressed/encrypted much like all the files that start with SCE as the first 3 bytes.
Still haven't spent much time looking at how it fits together, and my guess from looking at a couple of similar files is that there's a 256-bit random text which is decrypted using a private key in the PS3 firmware and then used as the seed for some kind of block cipher. The beginning of the file seems to be a variable length describing the encrypted and plain blocks and includes amongst other things an index to the random looking data and then some normal looking data.
I was wondering given that Sony have been promoting their CLEFIA system for only a matter of months whether it was an implementation of that, although I haven't found any technical description of that algorithm that could help key analysis.
Interestingly, if you look at unpacked firmware images, there are a couple of xml files in there, all encypted with a different key and presumably all starting with the plaintext <?xml which would make good material for brute force cryptanalysis. Obviously, this would be made substantially easier if we knew what algorithm is used... ;)
And if anyone actually ever managed to come up with a bootloader that enabled someone to dump the unecrypted firmware from the flash and/or memory, there's a good chance that most of the hard work could be avoided completely.
Still haven't spent much time looking at how it fits together, and my guess from looking at a couple of similar files is that there's a 256-bit random text which is decrypted using a private key in the PS3 firmware and then used as the seed for some kind of block cipher. The beginning of the file seems to be a variable length describing the encrypted and plain blocks and includes amongst other things an index to the random looking data and then some normal looking data.
I was wondering given that Sony have been promoting their CLEFIA system for only a matter of months whether it was an implementation of that, although I haven't found any technical description of that algorithm that could help key analysis.
Interestingly, if you look at unpacked firmware images, there are a couple of xml files in there, all encypted with a different key and presumably all starting with the plaintext <?xml which would make good material for brute force cryptanalysis. Obviously, this would be made substantially easier if we knew what algorithm is used... ;)
And if anyone actually ever managed to come up with a bootloader that enabled someone to dump the unecrypted firmware from the flash and/or memory, there's a good chance that most of the hard work could be avoided completely.
you can try readelf to decode the otheros.self without the "SCE header".
I dont have ppu-self or latest binutils , but my old readelf can give some correction information about the elf file (for examples, 64bit , big-endine, etc.) and these match the info from CEBA handbook. Of course some info are wrong (like entry point). Also the file doesn't look like under encrypted since the end of the file contain many non-zero value. (If the part after SCE header is encrypted, the end of the file should fill with zero padding, like ABFF0000 00000000, not ABFF0001 00010000)
I think, like psp, if the file is encrypted, it should be in other file format (prx for psp, pkg or somethings packed in pkg for ps3).
Also if the file is compress/encrypted, I dont know why there are a ELF section header. May be part of the file is encrypted, and the program run and load decrypt that part.
My wild guess is, may be that elf part load the linux loader (otheros.bld) into spu and run it under hypervisor.
Of course, the encrypt method may be different from PSP. Then this is out of my knowledge and we need to find it out)
I dont have ppu-self or latest binutils , but my old readelf can give some correction information about the elf file (for examples, 64bit , big-endine, etc.) and these match the info from CEBA handbook. Of course some info are wrong (like entry point). Also the file doesn't look like under encrypted since the end of the file contain many non-zero value. (If the part after SCE header is encrypted, the end of the file should fill with zero padding, like ABFF0000 00000000, not ABFF0001 00010000)
I think, like psp, if the file is encrypted, it should be in other file format (prx for psp, pkg or somethings packed in pkg for ps3).
Also if the file is compress/encrypted, I dont know why there are a ELF section header. May be part of the file is encrypted, and the program run and load decrypt that part.
My wild guess is, may be that elf part load the linux loader (otheros.bld) into spu and run it under hypervisor.
Of course, the encrypt method may be different from PSP. Then this is out of my knowledge and we need to find it out)
it's only because there is a data shift inside, but you can
it's only because there is a data shift inside, but you can SEE THE TWO START ADDRESS in the header, so it wan't to say that's not encrypted.
There is only a start addres for the ppu code and a start address for the spu code.
In one of these is the code (ppu) forcing to enable the hypervisor an in the second (spu) the check system. Then you can:
Modify it to disable the hypervisor (i don't think it's a good idea...)
add a range of address enabled to be accessed from the linux kernel...
An go to search the memory range of the cpu.
It's why after it will be important to recall this research with the ReNouveau projet to find the cpu area by comparison...
There is only a start addres for the ppu code and a start address for the spu code.
In one of these is the code (ppu) forcing to enable the hypervisor an in the second (spu) the check system. Then you can:
Modify it to disable the hypervisor (i don't think it's a good idea...)
add a range of address enabled to be accessed from the linux kernel...
An go to search the memory range of the cpu.
It's why after it will be important to recall this research with the ReNouveau projet to find the cpu area by comparison...
titof
Re: it's only because there is a data shift inside, but you
I can give you some interesting info about otheros.self
If you look for hex value "BC3F7A48AF45EF283A0598103F", you will find 3 sections which having same values for some bytes (hex values of above is the start of the section), and it look like a header.
What I guess about it is, 3 spe elf bins.
And if you unpack the firmware, you will get a file called "updater.sce". If you open it with hex editor, it is a file with sce header and elf header. Again search for the hex value above, you find 4 sections, and my guess is 4 spe elf bins.
And more, if you looking at the file called "UPL.xml.pkg", this is sure a encrypted file, and you will know that the sce header section is different.
Anyway, happy hacking of the files~
If you look for hex value "BC3F7A48AF45EF283A0598103F", you will find 3 sections which having same values for some bytes (hex values of above is the start of the section), and it look like a header.
What I guess about it is, 3 spe elf bins.
And if you unpack the firmware, you will get a file called "updater.sce". If you open it with hex editor, it is a file with sce header and elf header. Again search for the hex value above, you find 4 sections, and my guess is 4 spe elf bins.
And more, if you looking at the file called "UPL.xml.pkg", this is sure a encrypted file, and you will know that the sce header section is different.
Anyway, happy hacking of the files~
i don't want to hack the ps3 ...
I just wan't to be able to access to the gpu to start to realize a true opengl driver.
titof
Re: i don't want to hack the ps3 ...
You mean you intend on:titof49 wrote:I just wan't to be able to access to the gpu to start to realize a true opengl driver.
1. filling the holes in missing reverse engineered information obtained by the (re)nouveau project
2. bypassing the hypervisor protection (provided the RSX mmio is indeed protected which has not been proved right or wrong)
3. fitting the hardware into Mesa structure (I guess you won't write an OpenGL engine from scratch)
I hope you have plenty of time available :)