sony can read pretty much anything they want. everytime you connect the ps3 to internet (NB: internet, non psn) it automatically uploads the log files
these files contains the all ps3 activity, sony's fw are 175MB of code (compressed) and they could put some checker everywhere in the firmware, if one of these checks finds out that your ps3 is running a non-original firmware sony'll know it.
the only thing we can do is locate these checks and find out a way to bypass all of them
auto-recognize if dump is normal or byte swapped and automanage them
If you byte-reverse your dump before using this application, remember to byte-reverse it back after the procedure.
From haz367: proper eid0 section/part conversion so the new idps at least has correct values after it (cex2dex offsets 002F090-2F14F//omac hash)
offset 2F077/2F07F (new idps)
offsets/block: 2F090-2F14F - new values calculated/added to have valid idps change? at least better then only changing IDPS line
offset 303D7/303DF (new idps)
offset 3F040-3F045 (new mac)
tested offline and trashed with my own dumps. not needed but people deserve second change right, only need to brick another PS3 to get new idps. great share for that.
Update: PS3 IDPS Changer v1.3 Changelog: Here is the latest version of this sweet little app. I had troubles using all versions prior and now I have permanently installed new IDPS on over 30 systems. Make sure you have openssl installed via cygwin, enable XP SP2 compatibility on openssl.exe. Then grant admin access to openssl.exe as well as IDPS Changer then drop these files in the cygwin directory to ensure all the needed dll files are present.
Name your eEID Root Key - eid_root_key.bin (obtained via FW 3.55)
Name your NOR/NAND dump - dump.bin
Then place these in the cygwin folder as well with the other stuff we just installed/added
Then simply run the IDPS Changer.exe and follow instructions, this also allows changing of your MAC address. After the app is done simply rename the dump_patched.bin to the following depending on your flash type NAND or NOR.
Nor model = CEX-FLASH.FULL.EID0.NORBIN
Nand model = CEX-FLASH.FULL.EID0.NANDBIN
Once you have named the file copy on to a flash drive and open mM and go to mMOS then open the drive with the newly patched dump. Double click on it and wait for it to install. Once done reboot your system and go back to mM and the settings and look at your new MAC/IDPS on your freshly unbanned PS3.
Update: IDPSTool become IDPSet v0.6 is now available (linked above) by Zar from the PS3Gunz French site.
With this new version, you can permanently change your console IDPS (NAND and NOR). You just have to run IDPSet on your CFW (with Eid Root Key and valid IDPS on your USB key).
Finally, Zarh made available IDPSet v0.62 PKG with the following updates:
added the default paths of FLATZ's eid_root_key dumpers
added a check of eid_root_key
and now it's display the region matching with the target ID
To quote: Ok guys, so here's something I have for you. This is an idps/psid changer.
This changes the idps in section 0 or section 6 and the psid in section B (not A sorry, i corrected that on the wiki) PERMANENTLY on flash. so, you know the drill. be VERY careful when using this tool and always take precautions with a flasher.
You're going to need 5 things: root_key, a backup of your nor flash (only nor is supported at the moment but you can easily make it compatible for nand consoles by changing the offsets at merge_section as well as change the name to whatever you wish to call your flash), a back up of eid (you can obtain this with flow rebuilder or using memdump) and, obviously, the idps and the psid you want to use on your console.
As for the final hash in each section, the libeeid creator was kind enough to take care of that, so don't worry about that but PLEASE use valid idps and psid files!!!
Any questions, please ask. and yes, that handles cex2dex too.
Anyways, i figured this might be easier to use than c2d, because you can take a look at the source yourself and see and do your own changes, in case there's anything wrong.
WARNING. IF YOU USE THIS AND SOMETHING BAD HAPPENS. IT'S YOUR RESPONSIBILITY.
Finally, in related news zecoxao has also made available a PPU Binary Backup Manager but it needs testing.
To quote: I have a binary of a backup manager precompiled a long time ago. I'm not sure if it's even possible to boot it but I'm convinced this binary is meant either for 3.41 or 3.55, but i need someone to test it.
Here's the binary.. please report if it works signed as disc eboot/npdrm eboot on 3.55 or 3.41. Thanks.
To avoid creating unnecessary new threads i'll just post this here. i need also someone who can test [Register or Login to view links].
PLEASE be careful about this one and keep a flasher with a backup of your flash with you! this is dump_flash from gitbrew in psl1ght v1.
This contains two changes. there's an aditional poking in the memory for NAND flash dumping to allow the bootldr unmasking (as per a specific wiki section on the Hardware flashing page), and there are no debug outputs with udp_printf, so it should be faster to dump. This is ONLY for 3.55!
You can see the code on wargio's repository (github.com/wargio/dump_flash), but it's adapted to v2. to use it on v1, simply change the file lv2_syscalls.h to the one on gitbrew on the common git and the Makefile must have the respective include for ppu.mk in v1 (it differs in v2). if you just want to use the repository you can clone it or fork it. Careful with it though. it's not guaranteed it works !
mc_iso and me_iso individuals seed (unknown what this does at the present time)
F2 33 6E 25 63 B6 03 07 7A 76 65 71 26 CA E4 DB
82 0E 92 85 6B 69 3C E8 14 22 E9 FB 1C 1C A5 B3
E9 43 38 8E 4B 48 03 50 AA 24 A5 FB FA BF D1 72
D9 7A 1E 25 DE 3E 64 A0 A7 A4 82 52 84 56 B1 74[/code]EID1 and EID5 still uncovered
EID0 sections 2,3,4,5,6,8,9,10 (marked as 1,2,...11) still uncovered. BD Drive Firmware (any kind) can't be decrypted yet through the computer. SYSCON Firmware (any kind) can't be decrypted yet through the computer.
Private Keys can't be obtained (unless somehow someone had a quantum computer with >1000 qubits processing power and Shor's Algorithm at hand...) AES can't be compromised (maybe in a near future)
Per-console key 0 can't be obtained so far. What you see here is what remains. If anything happens that makes any of these things possible or understandable or achievable to be done, i'll delete the respective part of them.
Debunking the idps
Here's my debunking of the idps or console id as you know.
This comes back from the psp era. usually, you'd insert a disc, load a certain save and it'd load a data that'd have a very long string. at the end or the middle of that string you'd see a binary loader (hbl.bin) that would load the main menu of HBL. In the case of the ps3, before the crypto fail was publically announced, little to nothing was possible in regards to load a binary of a savegame. now, thanks to that and thanks to flatz 's amazing tools, it might be a possibility in the near future
Since there isn't a tool that handles savegame crashes (yet), so far we can only manage ourselves with a DEX/Convert and eth debug to know what happens at the time of the crash/freeze.. in my case, i don't have access to such tools, but there are people who do
So, you can try this for yourselves.. this was made in fifa 09. i turned auto-save off (so it didn't overwrite the crafted save i made), made a savegame profile, and loaded the disc. The result was that it crashed while loading the save.
The only thing i changed was SYS-DATA. i opened it in HxD, and filled my name (zecoxao) with o's until it matched Ronaldo's string entry. that caused the game to crash.
Theoretically, you can most likely load a disc-bind 3.55 and below signed self from a register that returns an address and it'll just load the self (i think) although i didn't try this myself yet, because i can't debug it properly on a superslim. Anyone who wishes to give it a go is welcome to do so.
Printing Things to the Screen
As you all know, neither the sdk nor the psl1ght environment allow you to print things natively to the screen , at least not without using rsx. fortunately, inside the cobra sources of their usb, there is something that enables that, making debug output MUCH easier.
The specified functions are debug_install and debug_printf. debug_install patches the necessary offsets and redirects tty output to the screen, and then debug_printf simply prints the thing you want. this might not sound much but it's a VERY useful feature, specially when you want to debug code and you like to visually see what is happening. also, this could turn things such as memory patching and dumping much easier to look at.
I'd like to compile it myself and test for results but i don't have a working hackable console. so i'd like to ask any of you devs to test it and check if it works or not. as i was told it does seem to work, so i hope that this gets adapted to PSL1GHT very soon.
U$er , i'd like you to be the first person to test this, since you have understood the plugin loading and adapted it for ourselves.
Buffer Overflow on Save Games
This comes back from the psp era. usually, you'd insert a disc, load a certain save and it'd load a data that'd have a very long string. at the end or the middle of that string you'd see a binary loader (hbl.bin) that would load the main menu of HBL.
In the case of the ps3, before the crypto fail was publically announced, little to nothing was possible in regards to load a binary of a savegame. now, thanks to that and thanks to flatz 's amazing tools, it might be a possibility in the near future.
Since there isn't a tool that handles savegame crashes (yet), so far we can only manage ourselves with a DEX/Convert and eth debug to know what happens at the time of the crash/freeze.
In my case, i don't have access to such tools, but there are people who do
So, you can try this for yourselves.. this was made in fifa 09. i turned auto-save off (so it didn't overwrite the crafted save i made), made a savegame profile, and loaded the disc.
The result was that it crashed while loading the save.. the only thing i changed was SYS-DATA. i opened it in HxD, and filled my name (zecoxao) with o's until it matched Ronaldo's string entry. that caused the game to crash.
Theoretically, you can most likely load a disc-bind 3.55 and below signed self from a register that returns an address and it'll just load the self (i think) although i didn't try this myself yet, because i can't debug it properly on a superslim.. anyone who wishes to give it a go is welcome to do so.
From pastie.org/private/p1mxjrd6xbmv3hrphazxsw (the freeze):
It'll take some minutes to upload them, so please wait.
Lv2diag.self bricking consoles?
I told myself i wasn't going to post any more about ps3s but this is really bugging me so... i was hanging out in skype when suddenly vapour barges in and says a self he created with Objective Suites bricked his ps3.
Naturally, for a person who bricked 7 consoles by flashing ways, i thought he was kidding, since nowhere in the world Sony would do such a thing. then i asked hellsing9 to test it somewhere. he tested the self. it bricked. he tested again, bricked again. then i asked greysmoke. he tested the self. it didn't brick.
My question is this: in which consoles can the brick be caused, what causes the brick to be triggered, and most importantly, can we intercept the process of the command of bricking and replace it with something else?
This is the self (3.42 appldr signed): [Register or Login to view links]
Needless to say flashers can and MUST be used before doing anything. They can unbrick. E3 flasher can be used as any regular flasher. as for the pinouts, i believe they are available on the wiki (NiceShot has the picture).
From NiceShot: Uhm... you should have the original dump before trying this, I'm not sure if dumping it, byte swapping and flashing it back will solve the problem but it is worth trying, I had a broken e3 flasher clip so I had to map the whole points to use e3 linker but if you have an e3 flasher with e3 clip you can do the job the same way, but there you have the pinout for MSX-001:
So, i was bored and i decided to open ida pro and take a look at things. then, someone told me that i could open idb files in ida. so i went to graf's bible and opened a few. fun. anyways, here are some scripts/updates of scripts.
HV Dump script has "new" function names instead of the usual "undocumented_function" crap and export script prints all the function names to the screen (the ones that don't start with sub_) consider this a release of sorts. i'll try to take care of syscall_names.idh tomorrow for the lv2 dump script.
Download: [Register or Login to view links]
Github contains precompiled loaders, plugins, signatures, and the new scripts. i've updated the zip. you should have now two aditional export functions. one for the syscalls, and another for the hvcalls. gonna see if i can take care of syscall_names, idh today.
Edit: taken care of: github.com/zecoxao/ps3ida/blob/master/syscall_names.idh
Kinda piggish but it does the trick
Added some more signatures. had to use a trick. They're on github: github.com/zecoxao/ps3ida/tree/master/sig/ppc
From zecoxao: Euss right next to this (psdevwiki.com/ps3/Seeds#sc_iso_key_seeds) there's a chunk of data, size 0x290, which is loaded twice in two separate functions. i'm guessing that this is some sort of eid1 in disguise? this is on the jig firmware btw.
There is also a third value which i don't recognize (next to be2sc and sc2be keys):
I have a working idps but i have no program to put this to my ps3 cfw rogero 4.46 do anyone can help?
Also below is some VTRM crypto and Blu-ray playback from zecoxao, as follows:
This is already known info but i figured i'd make it into a nice post so let's start.
There are two VTRM blocks at the flash. Each block corresponds to each ros. Essentially one VTRM is a backup of the other.
Inside the VTRM block there are encrypted blocks. there might be 4,5,6,etc blocks. The reason why the number of blocks changes we don't know. The blocks have a size of 0x40 bytes.
There are two ways to decrypt the blocks: using aes-xts and sherwood_ss_seed and ss_seed_one more OR (recommended) using aes cbc and keyseed_for_srk2.
Method is the following:
First, encrypt root key with sc_iso metadata seeds. key is at 0x20, size 0x10, iv is at 0x10. then, encrypt (pick one) either sherwood_ss_seed(for data) and ss_seed_one_more (for tweak) or keyseed_for_srk2 (this is a string used as a seed) with aes cbc-128 for block key (iv is 0).
After obtaining the data and tweak keys (or the block key) use the keys and decrypt each block.
Most of the blocks contain nothing inside, except for the very first one.
First block contains a hash of DRL (0x14 bytes) followed by a hash of CRL(0x14 bytes) in sha1 format. If you just remarried your console, you can fix bluray playback by replacing the hashes there with the ones you currently have.
There's another set of hashes in plain sight, and they're probably all sha1. First hash is repeated in a set of patterns. second hash is cleverly hidden among the patterns, and third hash is at the VTRM header. Corruption of these hashes is very likely to cause RSOD. There has been a debate wether replacing a corrupted hash with another equal hash would be advisable ( it fixes the RSOD error, but we don't know the direct consequences of this)
Oh, forgot the link to glevand's mastery: psdevwiki.com/ps3/Fixing_DRL_and_CRL_Hashes
I i just had a word with flatz.. two of the 3 hashes can be calculated already:
User i asked you about the method to dump srk and srh, but unfortunately, even with your help, i wasn't able to dump the data. running the code with your pokes hangs at a black screen. if you're interested in sharing that package to dump srk and srh that would be very cool of you
From u$er: the prx has been tested on 446 dex in debug mode. it should work on cex as well, but you won't see any result... just connect to port 4546 and type "dumpsrk".
Download: [Register or Login to view links] (load with prx loader) / pastie.org/private/kfbm2w1dzjddczxvdonba (src)
Also from zecoxao: Dump Sysrom and the masked bootldr on NANDs
as you can see here (psdevwiki.com/ps3/Talk:Sysrom.bin), dump sysrom was originally released by glevand in an attempt to dump the bootldr in his MFW OTHEROS++. he could do it with graf's payload, so he originally thought of porting it over to psl1ght and trying it on OTHEROS++. the thing is, there is some patch that breaks this, and he failed to find out the cause. as an alternative, memdump was released, and so an alternative method was developed for it (maybe it's the same method, but i don't know for sure).
so, what is the purpose of dump sysrom?
well, like i said before, it dumps the bootldr (the system rom) located at address 0x2401FC0000 on NANDs (in the reset vector and mapped in MMIO) and in some other address on NOR, which doesn't matter because we can fully dump NOR, bootldr included, anyways.
i decided to test it one last time, to see if it'd work differently from the expected FF FF FF FF 80 01 00 03 (not implemented) error, but this time, by launching the self on rebug 4.46. it turns out, it dumped the bootldr in its encrypted form on my NAND. great!
to anyone else decided to do something constructive with this information, i've asked sguerrini97 to set up a github repository of what we successfully ported to psl1ght v2 (which wasn't much)
it's called psl1ghtv2_ports, and contains some of the code used by glevand in the early days of the scene.
to anyone concerned, anyone who wants to include this piece of coding, take into consideration that you need lv1 peek poke in order to achieve this. also, dumping random MMIO offsets is very fun to do and you might encounter something cool
Finally, from mind: I just compiled dump_sysrom.self and run it on my CECHA01 (NAND) console - works great. I'm using 455 cfw and multiman v.4.55.00 to run the self.
The sub HAS to contain only that instruction AND a blr.
Save the offsets in each sub for each asm file. Now, go to ida and load any process elf. Go to the specified offset (pick any). Go to the function, highlight it in IDA-View... ctrl-X (xrefs) it'll show up a list of possible xrefs (most of them are Packet IDs)
Hykem, for the work being currently done
deroad, for the help at the weekends
and of course, graf chokolo
Here's a list of offsets of the get_* functions from factory JIG lv1
perconsole nonce is also an interesting bit to watch. it's in metldr,bootldr,eid0,eid3 and eid5. perconsole revision key however, is only on 4 of these and not in eid3.
[Need Testers] Get logs from initialization with Juan Nadie's bootldr exploit
So yesterday i had a very interesting conversation with a friend of mine from irc. He had a theory about the initialization of the ps3. He also had logs, obtained from a modification of Juan Nadie's bootldr exploit. Unfortunately, he had to format the hdd, so the logs were lost. And this happened a long time ago.
right now we're trying to reproduce the same thing. so far:
I've uncommented line 912 ( //createLog(0); )
I've added these lines
this is the code so far. peekpoke is already precompiled, but btldr8 needs recompiling. red ribbon rc7 was the version used. this only works on NOR consoles though (my biggest difficulty, since i have a NAND) so, i'll need some testers for this.
also, notice that this may not be complete. my friend says that he's still trying to remember what he did to enable logging so we don't know if it might work or not.. and i just need to check the logs.
logging of the instalation of pups. not of dumping bootldr.
MANY MANY thanks to my friend without whom this wouldn't have been possible.
it can help us understand how the chain of trust works at its very early stages. this is useful for documenting purposes, and possibly to find other hidden secrets. here's how it looks like it's working.
It might be possible that bootldr and metldr headers are seeds.
[0x10-0x20] -> seed for iv
[0x20->0x40] -> seed for key
My friend thinks the most plausible possibility is this: psdevwiki.com/ps3/Flash:Individual_System_Data_-_cISD some of this data (CID for example) is used to generate two sets of keys.
The ldrkey (used to decrypt metldr and lv0ldr) located at cell. this key encrypts metldr header as a seed and generates another key, used for decrypting metldr blocks and it does the same with bootldr.
the eidkey (copied to LS at the beginning of chain of trust) also located at cell. this is known as the eid_root_key and is used to decrypt the HDD, authenticate for SYSCON, decrypt the eEID, and of course generate Backup and VTRM seeds for the hashes in cVTRM.
My friend was able to hang Runtime Secure Boot stating:
The good thing: while hang spu is running in isolation load mode. i'm trying to determine what causes this hang and i have some thoughts about time when decryption and verification happens.. if i'm right then i'm able to modify encrypted btldr after verification but before decryption. also i know that encrypted loader contains only this loader and no other data after it.
So, i got a little early christmas gift and i checked inside it and saw a really old lv1 from version 0.83. since this thread is about the embedded selfs, i figured i might post what i found inside it. And it turns out, Sony stored every manager inside lv1 instead of only a couple of them with the functions bulked up. here they are:
This is a program that simply dumps some of the eeprom offsets using only the lv2 update manager interface syscall and a few patches applied.
It currently works only on 4.46 mfw, and it's for debugging purposes, although this doesn't help much because lv1 has higher access than lv2 (sorry for the mess flatz , i hope you can forgive me).
What can be dumped:
[0x2F00] <- no signs of minimal downgrade version here
[0x48C00] <- some things like the spu number, other things, not so much
[0x3000]<- everything could be dumped, but it's all 0xFF
What can't be dumped:
It was developed by sguerrini and myself. Alex gave us a hand with the code, Also. however, i can't release the source of it because it only worked when compiled with the oficial sdk. i have no idea why this happened.
The fail char is 0xBE. you'll see it in the fail offsets. The dumps and the log go to /dev_usb000, so just plug a usb device in the rightmost port near the bd drive. Sure. i'll just leave the code here, since they're both illegal lol.
Small update. We were only trying to dump 5 offset areas, there are 6 of them. The link is the same, but the self has been updated.. the 6th area still doesn't return anything though.
It can work with any firmware, as long as the correct offsets are there. Smhabib, maybe you can help me out verifying why this freezes on 3.55 rebug?
I tried porting the payload to a working psl1ght app, but i failed at making it run properly. I have no idea of what could be wrong.. it freezes when running the app in a black screen. Didn't work, even with all the patches enabled. i'll port the offsets to 4.46 and check there, since it's a better version to test for me.
Edit: Smhabib we found out why it wasn't working. Apparently the lv1 hvcalls aren't executed, and we don't know why. Perhaps it's something that only otheros ++ has and rebug doesn't have. We just don't know what... in the meantime, me and sguerrini (via github.com/sguerrini97/psl1ghtv2_ports) have ported a couple more things from glevand to psl1ght v2 (recover_mode_toggle, reboot, get_token_seed):
This is what i know so far, either from chatting with other people or by doing assumptions (a lot of this info is an assumption, quite a big one, but most of the info people have gathered over the years seems to be correct)
In the Cell BE CPU chip, there are 48 efuses. each of the efuses holds a bit. there are, therefore, 6 bytes of information stored in those efuses. these 6 bytes may or may not contain what Sony calls it the Serial Number or Customer ID. the Customer ID is a unique 6 byte ID that defines every single bit of perconsole information stored in the ps3 console.
It is believed that this Customer ID is tied to metldr/bootldr/eid/perconsole keys/etc. Sony most likely uses a custom algo to forge every bit of information from the Customer ID, together with some statics and variables they have created and which they use, such as the revision key and the perconsole nonce, the statics and variables inside the cISD1, amongst other things.
There would only exist two ways of obtaining the algo Sony uses. one of them would be by decapping the chip and analyzing it and finding the necessary information. That would cost thousands of dollars, so it wouldn't be a viable way. Another way would be to access sony servers and test until the algo is figured out (change bits in the statics and the variables, to see what would change, and fetch the algo that way).
Unfortunately, due to the leak of Objective Suites, Sony changed authentication procedures and unfortunately it's not possible to access that info anymore (unless someone else has a newer version of the tool and is able to do those tests).
This is completely annoying because, since we can't figure out the algo, we can't do anything on unhackables. If we had that information we could sign our own bootldrs and metldrs, and forge our own keys. that doesn't seem to be the case.
This is just for clarification. Most of what i've said here are assumptions, because we can't know without the algorithm. Please take them as such. And here (psdevwiki.com/ps3/Flash:Individual_System_Data_-_cISD#example_4) is the wiki page that displays the location of the Customer ID.
Update: Corrected bytes information. Customer ID is actually 6 bytes. i'm an idiot. thanks tiefputin2 for the information
Adding more information, here's an example of a similar ID but on psp: wololo.net/talk/viewtopic.php?f=21&t=2132
And this: code.google.com/p/kirk-engine/source/browse/trunk/libkirk/kirk_engine.c#434
8 bytes are used. so fuse id is 6 bytes of info padded with zeroes. it also has the name fuse in it which suggests it could be inside efuses. but who knows... both the psp fuse id and ps3 customer id can be read in mmio. depends if you have the right permissions to do so.