We will use this ongoing thread to discuss the recent zadow28 PS3 exploit / hacking developments.
Below is some information from zadow28 posted by tthousand via psx-scene.com/forums/content/doors-2088/:
Got this info in a PM, the *.a files from the sdk is actually elf files packed. you can rename all *.a files from the sdk to elf, and then run readelf on them. you would see where all the elf files write. Have been looking at the libsecure and found out where all the crypto is reading/writing.
These are the elf that Sony uses to encrypt/decrypt all there elf/bin/sprx, if you look at the libsecure there are 2 kind of *.a file normal and _d in the ending. I think one encrypt one decrypt. So I tried it and it worked from libsecure:
Well if you look at the thread the *.a files are archives with multiples elf within them. eussNL got this thred right thats why he found an extracter for *.a files thx euss so the libsecure.A have as many as 6 elf inside that where the good stuff is.
By the way also got his from (he knows himself) haven't check that yet but you could.. the *.a files turned out legit.
My first attempt at trying to decrypt the lv0 with a something so simple I knew it wouldn't work. But however here is the output I recieved metadataInfo:
Load ida pro then load any self/bin then file---->load---->pdb file then getheader.pdb. Then the header would turn up in any encrypted files.. both spu and ppc you can see for try.
The libsecure.a files one is where all the encryption is written the libsecure_d.a is where all the decrypted is written. Then there are 100 *.a files in the sdk with a lot of elf files inside all saying where everything is written and the *.a files they or used for base for making all softbto the ps3 that's why they can't change it.
And if you read the libsecure readelf you would notice that you can see where md5/sha215/aes/blowfish and a lot more is encrypted/decrypted.
Update: Here are the library files from libsecure extracted and put in the right folder
The offsets from the readelfin libsecure is acuelly quite usefull to get extra info out. The offsets have found 2000 more function in the lv1.elf from 3.56. Since i the private keys should be in that if am not wrong. Here is the strings after i use some of the offsets lv1elfstrings.rar notice there is something about master access. read idps etc i can upload the disassembled file also.
Consider the possibility that the "TB dongle updates" update only the game libraries (sprx) on the firmware or on the dongle (maybe it's a dev_flash mounted like dev_blind) ?
In the TB eboot you can see that it requests updated libraries like in this case 3.60 but they can masked to appear like 3.60 libraries if "TB modified the libraries" :
These "libraries" are needed to run games or new games that's why TB updates them !
That part is not encrypted as you can see but if you modify anything there in an self it will ruin the encryption as a whole (maybe after all it will not ruin anything).
In the PS3 Dev wiki page you can see that TB eboots are FSELF (fake signed elf) but someone (I can't mention his name until he gives me the permission to do , so RESPECT!) mentioned that they are recognized as FSELF (no encrypted metadata in fself when you run readself on it ) and are not true fselfs on his nature.
FSELF keys are given to game developers to not compromise their "true keys" when they are creating games on the debug stage (debug eboots).
When you run readself on a TB eboot there you see the "DevKit" SDK used (in which I have no info) but we could assume that there are the devkit (FSELF) keys used :
And the unself tools that are available doesn't decrypt tb eboots, even in some eboots they give no errors but when you look at them on hex editor you see them encrypted in which case people should look to create new unself tools.
With the theories until now you need 3 things : eboots decrypted ,updated libraries and the correct payload to patch lv2. Only the decrypted eboots will not suffice because they request updated libraries to run new games.
i would mention that i have nothing to do, with the fake CFW. so here some news for you.
There have always been problems debugging SPU elf files, since there are almost no debugger know to do this, except really slow terminal and anergistic. which is almost impossible to use.. and its in the spu files, the goodie stuff is.
normally in example ida pro, you could open spu, but not debug them, so almost useless.
you have to find the software, yourself but this little command in linux or cygwin
Below is another update from zadow (twitter.com/#!/zadow28) for those following:
The Lost files off Dev flash: One day i was looking at the dev flash and i noticed a pattern. Where SCE would turn up regularly. So i had hunch, i searched for all SCE in the hex and then extracted that hex and save it to some self files and that worked, so after investigating some more, i found that many off the files from the devflash, aren’t just elf ppc or spu files. like the lv1.self contains off 6 files both ppc and spu.
And best thing normally in ida pro when loaded a PPC file some areas are still “encrypted”. When extracted they come too there right meaning, and all codes are shown. Now the devflash files can contain self files, thats why i search for SCE. Thats the top of the header. But can also contain just elf files. The easiest way to locate them are ELF or search for hex string:
this works on all the debug objects files in debug build.
could be off use when looking at big builds
and when building you own
and one more thing the tuner can take alot off the extracted files that i posted,
and show there build too.
also some of the files if you used dev_blinds to copy intire dev flash/2/3 from ps3
some of the elf files there are debugs and the pic files are also shown and how there build there.
And work also if you take all the *.a files extract them with 7zip you have alot off *.o files they work there also.
so for exampel libguard.a extarcted there are alot of *.o inside
just one in the tuner with sources