| View previous topic :: View next topic |
| Author |
Message |
Marco_N
Joined: 29 May 2005
Posts: 46
|
 Posted: Tue Aug 22, 2006 4:56 am Post subject: |
 |
|
| 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)
In the "Hardware Access" part it shows hardware references to this area for me_booter.prx, mebooter_umdvideo.prx and me_wrapper.prx
(http://hitmen.c02.at/files/releases/psp/hardwarelist.txt)
Is it possible for the ME to be somehow responsible for the changing values? |
|
| Back to top |
|
 |
PspPet
Joined: 30 Mar 2005
Posts: 210
|
| Posted: Tue Aug 22, 2006 6:40 am Post subject: |
|
|
(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. |
|
| Back to top |
|
|
moonlight
Joined: 26 Oct 2005
Posts: 567
|
| Posted: Tue Aug 22, 2006 9:02 am Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
moonlight
Joined: 26 Oct 2005
Posts: 567
|
| Posted: Tue Aug 22, 2006 10:25 am Post subject: |
|
|
| 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". |
|
| Back to top |
|
|
robby
Joined: 23 Jun 2004
Posts: 1
|
| Posted: Tue Aug 22, 2006 9:20 pm Post subject: |
|
|
| 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 :) |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
