module load sequence & prx format ?

[terryxq]

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 [email protected], maybe he is too busy there is no reply.
Could anyone tell me more about "~PSP" format?

thanks

[moonlight]

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.

[terryxq]

thanks for quick reply :)

[SilverSpring]

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.

[terryxq]

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.

[cory1492]

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.

[terryxq]

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: Select all

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.

[jas0nuk]

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: Select all

// 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 &#40;sceUtilsBufferCopyWithRange_&#40;buf, size+0x14, buf, size+0x14, 8&#41; < 0&#41; &#123;
		return -1;
	&#125;

	return 0;
&#125;

int UnsignCheck&#40;u8 *buf&#41; &#123;
	u8 enc&#91;0xD0+0x14&#93;;
	int iXOR, res;

	memcpy&#40;enc+0x14, buf+0x80, 0xD0&#41;;

	for &#40;iXOR = 0; iXOR < 0xD0; iXOR++&#41; &#123;
		enc&#91;iXOR+0x14&#93; ^= check_keys1&#91;iXOR&0xF&#93;; 
	&#125;

	if &#40;&#40;res = DecryptSC&#40;&#40;u32 *&#41;enc, 0xD0&#41;&#41; < 0&#41; &#123;
		return res;
	&#125;

	for &#40;iXOR = 0; iXOR < 0xD0; iXOR++&#41; &#123;
		enc&#91;iXOR&#93; ^= check_keys0&#91;iXOR&0xF&#93;;
	&#125;

	memcpy&#40;buf+0x80, enc+0x40, 0x90&#41;;
	memcpy&#40;buf+0x110, enc, 0x40&#41;;

	return 0;
&#125;

[moonlight]

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.

[terryxq]

thanks everybody for sharing knowledge. :)

[gauri]

hello everyone.
i've taken a look at jas0nuk's code and there's a function sceUtilsBufferCopyWithRange_(). can someone explain what it does?

[moonlight]

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.

[gauri]

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.

[jimparis]

Not gonna happen. Only Sony knows the algorithm and keys.