Raphael wrote:I really got no clue about such stuff, but could it be that somewhere at 0xbfc... is some kind of instr counter or mem addr pointer, dependent on the currently executed operation?
Doesn't make much sense elseway, since the double dump should definately get the same result if no other prx interferes
I have about the same clue as Raphael :)
I thought 0xbfc was used by the Media Engine; I looked it up on groepaz's YAPPD, 5.2.2 Ram Usage:
0xbfc00000 0xbfcfffff 1mb Hardware Exception Vectors (RAM)
(disclaimer: haven't been following this thread, so question may sound stupid)
What is the reason/goal for reverse engineering the exact IPL algorithm ?
I gave up trying to track the changes since Sony is obviously changing the algorithm quite often.
> ...dumping RAM after boot should be able to reveal prx keys.
True. The 2.60 keys and algorithm are available with a 2.60 memory dump.
Also the 2.70 keys appear to be the same as the 2.60 keys !
However they change the algorithm yet again (changed from 1.x to 2.0->2.5 by adding a few extra steps and then again to 2.6/2.7 with many more steps). The algorithm and how the new keys are used to decrypt the PRX files is significantly different for 2.6/2.7 (but nothing a little disassembly can't fix)
I started looking at for a PsarDumper update, but didn't see any good reason to finish it.
PspPet wrote:(disclaimer: haven't been following this thread, so question may sound stupid)
What is the reason/goal for reverse engineering the exact IPL algorithm ?
I gave up trying to track the changes since Sony is obviously changing the algorithm quite often.
Reason?
Even if sony changes the algorithm all the times they want, if the bfc0* memory gets dumped correctly, except if they still have another secret weapon, it will lead to the decryption of all future ipl's and firmwares. Of course if they change the algorithm, and obscure things, more time and reverse engineering will be needed, but that only causes a retard, not the impossibility.
Plus we are bored and we have to spend the time in something :D
TyRaNiD wrote:It still might be worth trying v1.0 just because :P
dump obtained in 1.00 (from 0xbfc00040-0xbfc002c0)
comparison: 638 of 640 bytes different between them.
The decryption didn't work either.
My decrypter should be fine, since it uses directly the ipl decryption code (040f0d70) (with jals, jumps and global vars relocated to a different address), and there is no rare kernel stuff in that part.
It is supossed to be a way to get the initial contents of that area by software (or maybe those guys lied), but it seems it will be harder.
Btw, i didn't experience in 1.00 the problem of the "double dump being different".
I believe the 0xBFC0 RAM is scrambled inside of the IPL. Every IPL performs "*(u32 *)0xBC100004 = -1;" and on 2.60 upwards this is not done until after the gzip payload is decrypted and the 0xBFC0 RAM is zeroed - it appears this write tells the CPU to kill the hidden boostrap data. The dump from 0xBFC0 RAM appears to be different for each firmware version and does not appear to contain and valid instructions or data, all of which strengthens my argument. It looks like we may need to keep looking for a way to obtain the data we want :)