Actualy I found a key (first: is it a 16 bytes key ? or more ? less ?), and I use the PSP to decompress the code, and the result that is the result for a "simple" PRX (amctrl.prx) :
And all the file is 00.......
So I think my key is not good, too short or too long maybe ?
But the 8 first bytes means to be Ok, because the ELF header is good for these 8 bytes...
My key is :
C1 00 A9 EF C1 DE 2B 82 XX XX XX XX XX XX XX XX => the rest is not good....
I'm French, and 15 years old, so my English is not good...
Is this Sony's way of telling you "thanks for trying"?
Sorry for my non-suggestive comment. :p
I think there are many reasons that you are getting this kind of wired stuff.
It might be the best for you to analyze the problem yourself. Given that what you are trying to do, you should be capable of figuring it out by yourself.
You must be doing something seriously wrong. There is no possible way to get a 'partially' decrypted prx, this is not a stream cipher. The crypto hw used for decryption will either work and give you the correct output, or will fail and change nothing. It won't give a 'partial' result.
On top of that, after decryption a prx is compressed which needs to be decompressed to get the final plaintext ELF file (compression algo has changed too from GZIP to RLZ to KLE now). So after successful decryption, the header would not be ELF, it would be either 0x1F 0x1B (GZIP compressed), 2RLZ (RLZ compressed), or K4LE (KLE compressed). There would be no way to get a 'partially' decompressed file to produce that first bit of plaintext you showed there.
So somewhere, something has gone seriously wrong.
OR, everything actually worked out perfectly and that really is the final plaintext, in which case SCE is now doing some funky dummy tricks to fool devs.
I need to know what is a complete KL4E header, is there any documentation ?
Because that result is by decrypting and decompressing the file, this is the decrypted and compressed file :
So my key is too short I think, because the 3 firsts blocks of 4 bytes are good ine the final result.
I use a xor operation to decrypt the file, is it another thing ? :
Excuse me...
I decrypted usermode modules of 6.00, but i want to make a question to SilverSpring.
I know i need keys for kernel modules and i know they are in part2 and part3 of IPL.
I thought i can dump the ENCRYPTED firmware, but it says it can't decrypt the psar table (error -1)...
So i took the psardumper code and i modified it a bit so it'll load the psar table from a file.
I extracted the table from updater memory (just run 1.50 in TM, run psplink, reset in updater mode and run the fw update. strage thing: reset updater fails on 5.550 GEN-B2! error 0x8002013A) and i put it on MS.
It dumped and decrypted ALL the USER modules. So it's ok.
Now, here's the questions.
1) Why i can't even get crypted kernel modules? they simply miss.
2) Why psardumper fail in decrypting the table? i thought psar decryption wasn't needing firmware keys. did they change the algoritmh?
ab5000 wrote:I extracted the table from updater memory (just run 1.50 in TM, run psplink, reset in updater mode and run the fw update. strage thing: reset updater fails on 5.550 GEN-B2! error 0x8002013A) and i put it on MS.
What you call the updater mode ? What is it ?
EDIT: I said nothing, i found.. ^^
I'm French, and 15 years old, so my English is not good...
I made a PRX containing the patched function, then i did:
modexp @myDmesgHook
(myDmesgHook is the name of my module) and wrote down hook function export address. Imagine it's 0x12345678...
modimp @scePSAR_Driver
and i wrote down the adress of the stub for Dmesg function... imagine it's 0xABCDEF12. then:
asm 0xABCDEF12 "j 0x12345678"
done...
but i didn't dump the table this way.
i dumped user memeory when update was around 12% (no need for it to be 12%, just down it during update). then search for flash0: in the file, you'll find the table in 2 minutes...
then you'll need to copy it in a file. i took another table as reference: there's a "terminating" sequence, something like 08080808 (take a look at 5.50 table for example). modify psardumper to load 1000 and 2000 table from the file and yeah...
It should be somewhere in the decrypted IPL, just follow the mips code.
Even if they change the decrypting routine, it would contain specific instructions to tell the ipl how to decrypt kernel modules.
It should be somewhere in the decrypted IPL, just follow the mips code.
Even if they change the decrypting routine, it would contain specific instructions to tell the ipl how to decrypt kernel modules.
I think what you say is true, but for all firmwares. Because I decrypted the 5.00 IPL, as we know the keys, and I searched by using an Hex Editor and no results....
So yes, I need to follow all the code, jumps, and all ?! It's very fastidious...
I'm French, and 15 years old, so my English is not good...
You can get it by this wav :
- Put this PRX into "ms0:/elf/"
- install the 6.00 OFW
- Restart your PSP and press SELECT (like R for recovery)
- You arrives in the "ELF Menu"
- then start "Dump_IPL.elf" by pressing X
For sure, you need to have the TM
To reverse the IPL, you can use prxtool :
prxtool -b -w enc_ipl.bin > enc_ipl.asm
EDIT: humm... you need the pandora Elf menu ^^
Last edited by dridri on Sat Sep 19, 2009 7:19 am, edited 1 time in total.
I'm French, and 15 years old, so my English is not good...
I found that (bu following the code) :
0xBF 0x0E 0xBF 0xC0 0x02 0x80 0xEC 0x0F 0xEC 0x4F 0xED 0x8F 0x71 0x40 0xE9 0x8F
It's maybe that or not, but what is the algorithm to decrpt the IPL2 ??
I remember last time I saw an IPL, it's doing a lot of uncovering of its trace (i.e. zero out key buffers and stacks before routines return, etc.). Based on this, I doubt that it will leave valuable information that visible for you.
There used to be an interesting embedded file inside of part2 IPL, it's gziped and then encrypted. I don't think the encryption is the same for each and every firmware version. So, for fw6.0, you are supposed to figure it out yourself. However, I am pretty sure there are people out there who have already accomplished what you are trying to do :)
Last edited by serige on Sat Sep 19, 2009 7:55 am, edited 1 time in total.
Hey man, please be polite to other devs. They don't do it because they have to give out the algorithm to you. But like I said, you can always figure it out yourself.
Are they afraid that I make an CFW ??
I don't know about that. But if you can make one, you probably shouldn't be here and asking this kind of questions at the first place. But anyway, I hope you good luck on your mission!
I don't mean to offend you, but I don't really see the point of it. If you would like to share it, then why don't you share it. By the way, people who are dealing with assembly in a regular basis should already have something similar.
Excuse me, I just realized I am talking to a 15-year-old, and that may me feel like I am 50... :'(
There is really a lack of sharing and openness in the psp dev community. It has been a real bitch since the beginning. No one is interested in any childish competition. Wiki any info you have. Put all your source in a public repo. For the sake of the community.
Viper8896 wrote:There is really a lack of sharing and openness in the psp dev community. It has been a real bitch since the beginning. No one is interested in any childish competition. Wiki any info you have. Put all your source in a public repo. For the sake of the community.
+1
Seriously, the PSP deserves to be as open as we can make it. Bringing more devs to the scene would be nice. Sony aren't going to help.