Decrypt the Firmware 6.0
Decrypt the Firmware 6.0
Hi, i'm trying to decrypt the FW 6.0.
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....
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.
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.
-
- Posts: 110
- Joined: Tue Feb 27, 2007 9:43 pm
- Contact:
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.
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 ? :
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 ? :
Code: Select all
for(i=0, i<size; i+=4){
data[i] = key[j] ^ data[i];
data[i] = key[j] ^ data[i];
data[i] = key[j] ^ data[i];
data[i] = key[j] ^ data[i];
j++;
if(j >= 16){ // Is it really the key length ?
j = 0;
}
}
I'm French, and 15 years old, so my English is not good...
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?
Thanks!
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?
Thanks!
Code: Select all
%:include<stdio.h>
int _(int __,int ___,int ____,int _____)
<%for(;____<___;_____=_____*__,____++);
return _____;%>main()<%printf
("%d\n",_(2,5,0,1));%>
I think the keys has changed, you can see that in the PsarDumper :ab5000 wrote:2) Why psardumper fail in decrypting the table? i thought psar decryption wasn't needing firmware keys. did they change the algoritmh?
Code: Select all
TABLE_KEYS table_keys[] =
{
{ 0xb730e5c7, 0x95620b49, key_S },
{ 0x45c9dc95, 0x5a7b3d9d, key_S2 },
{ 0x6F20585A, 0x4CCE495B, key_S3 },
{ 0x620BF15A, 0x73F45262, key_S4 }
};
I'm French, and 15 years old, so my English is not good...
if you want i hooked the Dmesg function responsible for decrypting PSAR's, we can analyze the output...
Code: Select all
%:include<stdio.h>
int _(int __,int ___,int ____,int _____)
<%for(;____<___;_____=_____*__,____++);
return _____;%>main()<%printf
("%d\n",_(2,5,0,1));%>
What you call the updater mode ? What is it ?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.
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:
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...
(myDmesgHook is the name of my module) and wrote down hook function export address. Imagine it's 0x12345678...modexp @myDmesgHook
and i wrote down the adress of the stub for Dmesg function... imagine it's 0xABCDEF12. then:modimp @scePSAR_Driver
done...asm 0xABCDEF12 "j 0x12345678"
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...
Code: Select all
%:include<stdio.h>
int _(int __,int ___,int ____,int _____)
<%for(;____<___;_____=_____*__,____++);
return _____;%>main()<%printf
("%d\n",_(2,5,0,1));%>
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....serige wrote:It should be somewhere in the decrypted IPL, just follow the mips code.dridri wrote:UP
I decrypted the 01g IPL, but where is the key ??
Even if they change the decrypting routine, it would contain specific instructions to tell the ipl how to decrypt kernel modules.
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...
parts 2 and 3 aren't decrypted by psardumper... otherwise is would be too simple :P
take a look at this: http://forums.ps2dev.org/viewtopic.php?p=84468#84468
you need to take decrypted part1, reverse it, decrypt part2 & 3, decompress them and find the keys.
take a look at this: http://forums.ps2dev.org/viewtopic.php?p=84468#84468
you need to take decrypted part1, reverse it, decrypt part2 & 3, decompress them and find the keys.
Code: Select all
%:include<stdio.h>
int _(int __,int ___,int ____,int _____)
<%for(;____<___;_____=_____*__,____++);
return _____;%>main()<%printf
("%d\n",_(2,5,0,1));%>
I ve the full IPL.
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 :
EDIT: humm... you need the pandora Elf menu ^^
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 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.dridri wrote:But, how look likes the key ^^ ?
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 ??
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.
Yes, it's sure, but that Fu***** people dont want to give me that ! Are they afraid that I make an CFW ?? I don't know how to do !!serige wrote: However, I am pretty sure there are people out there who have already accomplished what you are trying to do :)
I'm French, and 15 years old, so my English is not good...
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.
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!Are they afraid that I make an CFW ??
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.Anyone want this ? ^^
Excuse me, I just realized I am talking to a 15-year-old, and that may me feel like I am 50... :'(
Just a thing: lui load upper 16bits. correct your program ;)
Code: Select all
%:include<stdio.h>
int _(int __,int ___,int ____,int _____)
<%for(;____<___;_____=_____*__,____++);
return _____;%>main()<%printf
("%d\n",_(2,5,0,1));%>
+1Viper8896 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.
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.