 |
forums.ps2dev.org
Homebrew PS2, PSP & PS3 Development Discussions
|
| View previous topic :: View next topic |
| Author |
Message |
terryxq
Joined: 12 Oct 2005
Posts: 16
|
 Posted: Mon Nov 19, 2007 5:31 pm Post subject: module load sequence & prx format ? |
 |
|
Hi
question 1:
could anyone explain cfw modules init load sequece after power on?
I want to replace some modules to learn internals, I don't know which loads recovery.prx & when, I need to keep recovery.prx working so it is possible to rollback modified prx to original ...
question 2:
About "~PSP" file format.
"yet another psp doc" described "~PSP" format. I read the source code of m33 newpsardumper, it seems when prx is decoded from psar, it matches the format of "yet another psp doc". But most of the prx files I copied from psp 3.71m33 flash0:/ does not match yapspd, (except idcanager.prx, usbdevice.prx and so on, I think these were made by dark alex).
I did not know how to convert them to ELF, so I asked to coolj@QJ, he replied jas0nuk's prxdecrypter can do this job. Yes, I tried, it works, but I still don't know how, then I left message to jas0nuk@lan.st, maybe he is too busy there is no reply.
Could anyone tell me more about "~PSP" format?
thanks |
|
| Back to top |
|
 |
moonlight
Joined: 26 Oct 2005
Posts: 567
|
| Posted: Mon Nov 19, 2007 5:44 pm Post subject: |
|
|
| those other prx's are signchecked. You have to unsign check them to see the real format. Anyways, they have hidden the module names in the ~PSP container in 3.71, this was to avoid modules to be recognized, as they were hiding the file names in the psar using a crappy des encryption over a file names table. |
|
| Back to top |
|
|
terryxq
Joined: 12 Oct 2005
Posts: 16
|
| Posted: Mon Nov 19, 2007 6:11 pm Post subject: |
|
|
| thanks for quick reply :) |
|
| Back to top |
|
|
SilverSpring
Joined: 27 Feb 2007
Posts: 115
|
| Posted: Tue Nov 20, 2007 12:53 pm Post subject: Re: module load sequence & prx format ? |
|
|
| terryxq wrote: |
I did not know how to convert them to ELF, so I asked to coolj@QJ, he replied jas0nuk's prxdecrypter can do this job. Yes, I tried, it works, but I still don't know how |
What do you mean you still dont know how? So you want to know in technical terms how the ~PSP files are decrypted to ELF's? Or you want to know how to do it in code, in that case look at the psardumper src.
If you want to know the technical details behind it, well it can get pretty detailed. |
|
| Back to top |
|
|
terryxq
Joined: 12 Oct 2005
Posts: 16
|
| Posted: Tue Nov 20, 2007 8:44 pm Post subject: Re: module load sequence & prx format ? |
|
|
| SilverSpring wrote: | | terryxq wrote: |
I did not know how to convert them to ELF, so I asked to coolj@QJ, he replied jas0nuk's prxdecrypter can do this job. Yes, I tried, it works, but I still don't know how |
What do you mean you still dont know how? So you want to know in technical terms how the ~PSP files are decrypted to ELF's? Or you want to know how to do it in code, in that case look at the psardumper src.
If you want to know the technical details behind it, well it can get pretty detailed. |
ok, I'll try to explain with my poor english.
Initially, I used m33 psardumper, and got a lot plain prx files. I thought if I gzip the plain one, create a ~PSP header manually, it will be as same as the one stored in flash0.
But when I copied prx files from flash0:/, I found I was wrong. I could not find any info about that ~PSP format, but jas0nuk's prxdecrypter can convert them to plain format.
Due to moonlight, I know they are signchecked. And jas0nuk's tool can unsigncheck. So my next question is how to unsigncheck. I am reading psardumper source again, searching everything about semaphore_4C537C72. I hope I can unsigncheck prx myself, but it does not seems I am on the right way yet. |
|
| Back to top |
|
|
cory1492
Joined: 10 Dec 2004
Posts: 216
|
| Posted: Tue Nov 20, 2007 11:48 pm Post subject: |
|
|
| When prx's are installed to flash, they are signed per PSP (signcheck), meaning the executeable's header (the part you see ~PSP) is "mangled" in some fashion so you won't see ~PSP but some seemingly random data. Files that have ~PSP as the first 4 bytes are generally (some m33 files now have a ~PSP header) crypted and often compressed, but are not signchecked. When you get the files from a psar, those will be crypted but not signchecked yet, when you get files from your PSP flash those may well be signchecked. |
|
| Back to top |
|
|
terryxq
Joined: 12 Oct 2005
Posts: 16
|
| Posted: Wed Nov 21, 2007 1:22 am Post subject: |
|
|
| cory1492 wrote: | | When prx's are installed to flash, they are signed per PSP (signcheck), meaning the executeable's header (the part you see ~PSP) is "mangled" in some fashion so you won't see ~PSP but some seemingly random data. Files that have ~PSP as the first 4 bytes are generally (some m33 files now have a ~PSP header) crypted and often compressed, but are not signchecked. When you get the files from a psar, those will be crypted but not signchecked yet, when you get files from your PSP flash those may well be signchecked. |
Hi cory
this amctrl.prx (copied from my psp flash, 3.71 m33), has ~PSP as the first 4 bytes.
| Code: |
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 7E 50 53 50 07 50 01 00 02 01 20 00 00 00 00 00 ~PSP.P.... .....
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 01 02 D6 17 00 00 80 0C 00 00 ........?..€...
00000030 DC 06 00 00 C8 14 00 80 68 08 00 00 10 00 40 00 ?..?.€h.....@.
00000040 00 00 00 00 00 00 00 00 40 15 00 00 00 00 00 00 ........@.......
00000050 00 00 00 00 34 15 00 00 80 08 00 00 00 00 00 00 ....4...€.......
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 00 01 00 07 03 02 00 00 00 ................
00000080 7D E8 FB 74 B2 54 F2 B7 C3 4D AA 06 1A 81 2D 8F }棼t睺蚍肕?.??
00000090 F8 82 80 84 6A F2 0D 3E 52 C0 C0 9E A3 B2 65 33 鴤€刯?>R览灒瞖3
000000A0 95 47 CB FA 28 FF E6 A2 17 1D F2 75 00 2C 15 DE 旼塌(姊..騯.,.?
000000B0 FB 88 87 99 32 87 EB 37 B0 1B 55 17 4B 87 CA C6 麍嚈2囯7?U.K囀?
000000C0 DB 7B 82 2F 41 83 D6 B1 99 7A 29 1B B5 D1 FC 68 踸?A冎睓z).笛黨
000000D0 4A EC A3 D6 0A 7F 3D EA 92 1D 62 5B 07 AE 9E 4F J欤?=陹.b[.疄O
000000E0 1F 29 FE 4A 0A 39 9A 7E 7C EE 6A C0 2B 26 C1 45 .)﨡.9殈|頹?&罞
000000F0 D0 80 8F A5 07 9A 5B E9 43 8E 6F 4F 69 8D BD BE 衻彞.歔镃巓Oi嵔
...
|
I compared unsignchecked prx, it seems signcheck only mangled 0x80~0x14f (size 0xd0), from 0x150 to end of file is encrypted content. |
|
| Back to top |
|
|
jas0nuk
Joined: 27 Apr 2006
Posts: 137
|
| Posted: Wed Nov 21, 2007 5:25 am Post subject: |
|
|
Code to Unsigncheck a buffer (pass the entire encrypted PRX to UnsignCheck, it will unsigncheck the buffer. If the buffer wasn't originally signchecked, the buffer will end up as junk.)
| Code: | // sigcheck keys
u8 check_keys0[0x10] = {
0x71, 0xF6, 0xA8, 0x31, 0x1E, 0xE0, 0xFF, 0x1E,
0x50, 0xBA, 0x6C, 0xD2, 0x98, 0x2D, 0xD6, 0x2D
};
u8 check_keys1[0x10] = {
0xAA, 0x85, 0x4D, 0xB0, 0xFF, 0xCA, 0x47, 0xEB,
0x38, 0x7F, 0xD7, 0xE4, 0x3D, 0x62, 0xB0, 0x10
};
int DecryptSC(u32 *buf, int size) {
buf[0] = 5;
buf[1] = buf[2] = 0;
buf[3] = 0x100;
buf[4] = size;
if (sceUtilsBufferCopyWithRange_(buf, size+0x14, buf, size+0x14, 8) < 0) {
return -1;
}
return 0;
}
int UnsignCheck(u8 *buf) {
u8 enc[0xD0+0x14];
int iXOR, res;
memcpy(enc+0x14, buf+0x80, 0xD0);
for (iXOR = 0; iXOR < 0xD0; iXOR++) {
enc[iXOR+0x14] ^= check_keys1[iXOR&0xF];
}
if ((res = DecryptSC((u32 *)enc, 0xD0)) < 0) {
return res;
}
for (iXOR = 0; iXOR < 0xD0; iXOR++) {
enc[iXOR] ^= check_keys0[iXOR&0xF];
}
memcpy(buf+0x80, enc+0x40, 0x90);
memcpy(buf+0x110, enc, 0x40);
return 0;
} |
|
|
| Back to top |
|
|
moonlight
Joined: 26 Oct 2005
Posts: 567
|
| Posted: Wed Nov 21, 2007 5:47 am Post subject: |
|
|
You can know if a file is signchecked looking the 0x58 bytes at offset 0xD4.
If all of them are zero, then the file is NOT signchecked, otherwise it is. This only aplies to 2.80+ prx's however, and doesn't apply to previous ones or to games prx's. |
|
| Back to top |
|
|
terryxq
Joined: 12 Oct 2005
Posts: 16
|
| Posted: Wed Nov 21, 2007 2:34 pm Post subject: |
|
|
| thanks everybody for sharing knowledge. :) |
|
| Back to top |
|
|
gauri
Joined: 20 Jan 2008
Posts: 35
Location: Belarus
|
| Posted: Tue Jan 22, 2008 3:35 am Post subject: |
|
|
hello everyone.
i've taken a look at jas0nuk's code and there's a function sceUtilsBufferCopyWithRange_(). can someone explain what it does?
_________________
Freelance game industry veteran. 8] |
|
| Back to top |
|
|
moonlight
Joined: 26 Oct 2005
Posts: 567
|
| Posted: Tue Jan 22, 2008 6:28 am Post subject: |
|
|
| gauri wrote: | hello everyone.
i've taken a look at jas0nuk's code and there's a function sceUtilsBufferCopyWithRange_(). can someone explain what it does? |
It calls the hardware encryption engine. |
|
| Back to top |
|
|
gauri
Joined: 20 Jan 2008
Posts: 35
Location: Belarus
|
| Posted: Tue Jan 22, 2008 5:16 pm Post subject: |
|
|
| moonlight wrote: | | It calls the hardware encryption engine. |
Hmm, nice. :-) And who knows what the algorithm this engine uses?
I aim to make a decryptor that runs NOT on PSP.
_________________
Freelance game industry veteran. 8] |
|
| Back to top |
|
|
jimparis
Joined: 10 Jun 2005
Posts: 1179
Location: Boston
|
| Posted: Tue Jan 22, 2008 6:43 pm Post subject: |
|
|
| Not gonna happen. Only Sony knows the algorithm and keys. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
