mesg_led.prx?

D_Street · Post by **D_Street** » Thu Sep 03, 2009 3:10 pm

Anyone kind enough to tell me what these 2 functions do?

sceMesgd_driver_102DC8AF
sceNwman_driver_9555D68D

It would be really nice if someone can point me to some useful info about this module without asking me to reverse engineer it :)

SilverSpring · Post by **SilverSpring** » Thu Sep 03, 2009 4:15 pm

They both decrypt PSAR's.

sceNwman_driver_9555D68D decrypts internal PSAR's (eg. devkit updaters)

sceMesgd_driver_102DC8AF decrypts retail PSAR's (from retail fw updaters)

(used only after the PSAR header is 'descrambled' into plaintext first)

mesg_led.prx in general is used to decrypt pretty much every type of firmware file (typically prxs).

This post for the different types of files it decrypts:
http://forums.ps2dev.org/viewtopic.php?p=57770#57770 (beware of changed NID's though)

And here for the real names of those functions:
http://my.malloc.us/silverspring/2009/0 ... tion-nids/

D_Street · Post by **D_Street** » Thu Sep 03, 2009 5:37 pm

Thank you, really helpful info you have here!
I got a little question though.
Isn't this file a firmware file? Then how does it get decrypted in the first place before anybody can use its decrypt functions?

D_Street · Post by **D_Street** » Thu Sep 03, 2009 5:49 pm

Oh, I see. mesg_led.prx is probably decrypted by some other means.

SilverSpring · Post by **SilverSpring** » Thu Sep 03, 2009 8:01 pm

Yes, mesg_led.prx and kernel modules are decrypted with the IPL. User modules and other encrypted files use mesg_led.prx to decrypt.

D_Street · Post by **D_Street** » Thu Sep 03, 2009 8:16 pm

Yeah, that's what I was suspecting...
Does psardumper decrypt the ipl?

SilverSpring · Post by **SilverSpring** » Thu Sep 03, 2009 8:40 pm

Well, it's a bit more complicated than that. But in general, no, not fully anyway (for recent firmware).

For 1.50 updater and below, psardumper won't even dump the IPL let alone decrypt it since the IPL didn't exist in the PSAR back then (it was embedded inside another prx embedded into the updater app itself).

For 2.00 and 2.50 updaters, psardumper will dump and fully decrypt the IPL. From 2.60 onwards the IPL was further encrypted which used the contents of the pre-IPL as a seed so psardumper cannot fully decrypt those IPL's. For these fw, psardumper will dump the IPL and decrypt the block decryption of the first stage IPL, but will not decrypt the rest of the IPL (where the code and keys to decrypt fw prxs reside).

So if you really want to see the full decrypted IPL I suggest you run psardumper on 2.00 or 2.50 updaters.

D_Street · Post by **D_Street** » Thu Sep 03, 2009 8:58 pm

Oh, so, this is the story why they only manage to partially decrypt the 5.55fw, although some people might have fully decrypted it in their own privacy.

Thanks for sharing the knowledge though, I will make sure to do more research before asking dumb questions.

Torch · Post by **Torch** » Fri Sep 04, 2009 12:50 am

How does the flow of control look like when CFW's custom IPL patches the FW IPL? The FW IPL obviously needs to be decrypted first.

D_Street · Post by **D_Street** » Fri Sep 04, 2009 5:36 am

Did you watch TyRaNiD's presentation about breaking the security model of the PSP? I guess you can find some useful information on how they messy up the original IPL and create a custom one.

SilverSpring · Post by **SilverSpring** » Fri Sep 04, 2009 1:10 pm

Torch wrote:How does the flow of control look like when CFW's custom IPL patches the FW IPL? The FW IPL obviously needs to be decrypted first.

Does not need to be decrypted. The ofw IPL is signed code so it can run as is, ie. it can decrypt itself and decrypt the fw itself when run.

Torch · Post by **Torch** » Fri Sep 04, 2009 6:35 pm

SilverSpring wrote:
Torch wrote:How does the flow of control look like when CFW's custom IPL patches the FW IPL? The FW IPL obviously needs to be decrypted first.
Does not need to be decrypted. The ofw IPL is signed code so it can run as is, ie. it can decrypt itself and decrypt the fw itself when run.

I was asking about the custom IPL used since 3.60M33. Does the IPL use static addresses? Since the forged block would be first, which then continues into the M33 custom IPL. Would the official IPL need to be relocated or something before the M33 IPL jumps into it? How what exactly is the process of loading, patching and executing the official IPL after the forged IPL is done and the M33 IPL is executed.

D_Street · Post by **D_Street** » Mon Sep 07, 2009 7:27 pm

SilverSpring wrote: For 2.00 and 2.50 updaters, psardumper will dump and fully decrypt the IPL. From 2.60 onwards the IPL was further encrypted which used the contents of the pre-IPL as a seed so psardumper cannot fully decrypt those IPL's. For these fw, psardumper will dump the IPL and decrypt the block decryption of the first stage IPL, but will not decrypt the rest of the IPL (where the code and keys to decrypt fw prxs reside).

So despite this fact, we can still hand decrypt the rest of the IPL based on what is known in the decrypted part 1, right?
BTW, can anyone suggest a simple tool to disassemble a plain text MIPS code (or partially plain text MIPS) file like part1_nandipl_02g.ipl?

EDIT: I guess maybe I should have asked how to twist prxtool to work with part1_nandipl_02g.ipl?

SilverSpring · Post by **SilverSpring** » Tue Sep 08, 2009 4:08 pm

D_Street wrote:
SilverSpring wrote: For 2.00 and 2.50 updaters, psardumper will dump and fully decrypt the IPL. From 2.60 onwards the IPL was further encrypted which used the contents of the pre-IPL as a seed so psardumper cannot fully decrypt those IPL's. For these fw, psardumper will dump the IPL and decrypt the block decryption of the first stage IPL, but will not decrypt the rest of the IPL (where the code and keys to decrypt fw prxs reside).
So despite this fact, we can still hand decrypt the rest of the IPL based on what is known in the decrypted part 1, right?
BTW, can anyone suggest a simple tool to disassemble a plain text MIPS code (or partially plain text MIPS) file like part1_nandipl_02g.ipl?

EDIT: I guess maybe I should have asked how to twist prxtool to work with part1_nandipl_02g.ipl?

Yes you can always still manually decrypt the IPL completely (though algorithms change almost every fw update).

To disassemble using prxtool:

Code: Select all

prxtool -b -w -r 0x040F0000 part2_nandipl_02g.ipl  > part2_nandipl_02g.asm

The -b switch tells prxtool to load the file as a binary file.
The -w switch tells prxtool to disassemble the file.
The -r 0x040F0000 tells prxtool to relocate the address to 0x040F0000 (which is where the IPL is first loaded into memory, the IPL uses hardcoded addresses).

You should also use the part2* file of psardumper, it is quite poorly named and really the part1* file shouldn't even be saved. The part1* file is the same as the part2* except it still includes a header for each decrypted IPL block which just tells the preIPL where in memory to load the decrypted block. The part2* file is the complete IPL after first stage block decryption.

Torch wrote:I was asking about the custom IPL used since 3.60M33. Does the IPL use static addresses? Since the forged block would be first, which then continues into the M33 custom IPL. Would the official IPL need to be relocated or something before the M33 IPL jumps into it? How what exactly is the process of loading, patching and executing the official IPL after the forged IPL is done and the M33 IPL is executed.

Yes ofw IPL addresses are all hardcoded. Take a look at the 'simple IPL' sample from moonlight to see how a custom IPL can be used to patch ofw IPL.

Torch · Post by **Torch** » Tue Sep 08, 2009 4:40 pm

SilverSpring wrote:Yes ofw IPL addresses are all hardcoded. Take a look at the 'simple IPL' sample from moonlight to see how a custom IPL can be used to patch ofw IPL.

That demonstrates it for a 1.50 IPL. But for a 2.50+ IPL the official IPL's part 1 must be allowed to run first since the data to be patched will be in the the further encrypted part. I'm guessing initially the M33 IPL patches the code of part 1 to jump back into the M33 IPL after deceyption of the further part so that the decryted part can be patched after part 1 runs. Then it jumps back to the patched decrypted part.

D_Street · Post by **D_Street** » Tue Sep 08, 2009 5:50 pm

Thanks for the tip!

SilverSpring wrote: You should also use the part2* file of psardumper, it is quite poorly named and really the part1* file shouldn't even be saved. The part1* file is the same as the part2* except it still includes a header for each decrypted IPL block which just tells the preIPL where in memory to load the decrypted block. The part2* file is the complete IPL after first stage block decryption.

I am a bit skeptical if it is still true in the latest firmware (5.55). Looks like part1 has everything in part2 and a little bit more, especially the embedded file. This might not be too surprising though, since, as you have already said, the algorithm kept changing every firmware update. Anyhow, I still need to do more analysis to see what is going on.

Can you also explain what happened to part3? I dumped the 5.00 firmware, it has 0 byte part3 files (same for 5.55). Does part2 already include it or what?

D_Street · Post by **D_Street** » Fri Sep 11, 2009 10:49 am

Sorry for bumping this thread.

I think I have reverse engineered almost all of the wanted MIPS code in the ipl, all I need is the pre-ipl.

I have a 2k slim, and I tried booster's ipl sdk, but didn't work (not sure what I did wrong). I did the search and have read through the results, didn't really help, couldn't find anything from google either. :(

If anyone has successfully dumped their 2000 pre-ipl before, I would appreciate it if you can share your method (or you can pm me).

P.S. Note, I am not asking for the pre-ipl file, I am only asking for a working method, and hopefully I am not breaking the forum rule here.

Torch · Post by **Torch** » Fri Sep 11, 2009 4:07 pm

moonlight's custom IPL sample also dumps the pre-IPL to unused upper kernel memory. It's only for 1.50 though. Maybe if it were modified for TM's 1.50 IPL, but I'm sure there are easier ways.

WosRet · Post by **WosRet** » Mon Sep 14, 2009 3:51 pm

D_Street wrote: I have a 2k slim, and I tried booster's ipl sdk, but didn't work (not sure what I did wrong).

to use booster's ipl sdk, you have to compile it with gcc 4.0.2.
it didn't work with gcc 4.3.2 (for me at least). i spend 2 days, to find that out! :(

D_Street · Post by **D_Street** » Mon Sep 14, 2009 4:59 pm

WosRet wrote: to use booster's ipl sdk, you have to compile it with gcc 4.0.2.
it didn't work with gcc 4.3.2 (for me at least). i spend 2 days, to find that out! :(

Damn it! I got a gcc 4.1.0 :'(
Man, that sucks! I have spent 4 days looking for a way to dump that thing and ended up with failure. It leaves me no choice but I have to settle down with a phat preipl... Luckily, the 1g ipl is pretty much the same as the 2g one, so I don't have to alter my code in any way :)

BTW, can you confirm that the bios dumper ipl works under a slim model (if you have one by any luck)?

Thanks for the tip!

WosRet · Post by **WosRet** » Mon Sep 14, 2009 5:21 pm

ok, you can download my compiled bios dumper here.
sorry, i can't confirm if this is working on a slim, i have only a phat.
i hope it works! :)

D_Street · Post by **D_Street** » Mon Sep 14, 2009 5:58 pm

You are right about that compiler version, it works and I just got the dump.

This is great! It's not like I am the only one who has no clue of why the ipl sdk doesn't really work the way it should (well, the pandora recovery menu works on the phat, not the slim; the bios dumper simple fails to work on both models). I believe there are folks out there who are looking for exactly the same thing as I am and they ought to come here and say thank you!

moonblood · Post by **moonblood** » Sat Oct 17, 2009 3:42 am

@WosRet
The download doesn´t work for me:( Note: I haven´t a premium-account...

WosRet · Post by **WosRet** » Sat Oct 17, 2009 11:54 am

should work for everybody! weird... i try to upload it somewhere else...

moonblood · Post by **moonblood** » Sat Oct 17, 2009 6:39 pm

Yeah... it works now! Thank you! But I dont know why it didnt work yesterday...

EDIT: Sorry for the noob-question, but how do I get the bios-dumper work? Where I have to copy/install this pspboot.bin? Sorry I´m still a noob!