PSAR Dumper 2.0 (PRX 2.0 format decrypted)

PspPet · Post by **PspPet** » Fri Sep 30, 2005 3:13 pm

Download
http://aibohack.com/psp/psardump02.zip
[binaries for 1.00 and 1.50 firmware, source code, README.TXT]

You will need a homebrew compatible PSP (1.0 or 1.50 firmware)
The new PsarDumper2 is very similar to the old "PSAR Dumper" release, but it now does the things the old version can't handle.

This new version will decrypt the 2.0 PRXs!!! (and put them in the OUTX folder)

Advanced expert tool.
A tool to help legal reverse engineering of the PSP system components.
Extracts the contents of the update data file, and saves them as separate files on memory stick.
NOTE: The non-decrypted PRX files are not saved in this version so it will fit on a 32MB memory stick.

Legal Note:
The files you download (ie. the updater EBOOT.PBP) and the files extracted by this tool (ie. the contents of the OUT and OUTX folders) are all Sony copyrighted material !!
You can use them under certain "fair uses". Do not post these files on the Internet. Use this tool at your own risk! The tool itself contains no Sony copyrighted material.

NOTE: you can load 2.0 decrypted prx files on top of the PSP 1.0/1.50 system, but system incompatibilities make things very difficult. This is what a lot of people want. This is only a step along the path (but a big step in the right direction).

groepaz · Post by **groepaz** » Fri Sep 30, 2005 4:27 pm

amazing, great work

dot_blank · Post by **dot_blank** » Fri Sep 30, 2005 4:30 pm

i must say this is dev
now this is absolutely wonderful
source you have here pspet 8)

excellent info, you continue to
impress members such as myself

Post by **Warren** » Fri Sep 30, 2005 4:48 pm

Good work PspPet

Ninja · Post by **Ninja** » Fri Sep 30, 2005 6:43 pm

Great work..

I guess we can load the decrypted PRX using MPH Firmware Launcher or UMD Emulator?

nem · Post by **nem** » Fri Sep 30, 2005 8:21 pm

Great work!
How did you manage to get the table?
IPL hack or something like that?

ice-master · Post by **ice-master** » Fri Sep 30, 2005 9:06 pm

Ninja wrote:Great work..

I guess we can load the decrypted PRX using MPH Firmware Launcher or UMD Emulator?

I just tried and it seems to not work (Sce_ImposeDriver error if i remember correctly)

++

pspkrazy · Post by **pspkrazy** » Fri Sep 30, 2005 9:26 pm

i ve tried. It does not work but it is normal.

I've tweaked john source to add pspSdkInstallNoPlainModuleCheckPatch() so it can load modules freshly decrypted by psppet's work.

Then i've modified a function to handle $ like % in module list.

2.0 started but i got the famous "Incorrect parameters. Push O to restore system defaults" screen.

It put me 2.0 settings in my real flash0 and bugged.

Thanks to sony my 1.5 is working with another "Incorrect parameters. Push O to restore system defaults" screen.

Woooo :)

let johnmph do some work here ! :)

Chrighton · Post by **Chrighton** » Sat Oct 01, 2005 12:46 am

Very nice work :)

jockyw2001 · Post by **jockyw2001** » Sat Oct 01, 2005 1:36 am

Wonderful! You are a hardcore hacker :P
Can you explain how u did it?

/JockyW

groepaz · Post by **groepaz** » Sat Oct 01, 2005 1:36 am

How did you manage to get the table?
IPL hack or something like that?

yeah please explain :)

PspPet · Post by **PspPet** » Sat Oct 01, 2005 1:44 am

> Can you explain how u did it? ...
The 2.0 PRX decryption algorithm is very similar to the 1.0 version, and somewhat similar to the way PSARs are scrambled. They've added an extra scramble step and changed the keys. The hardware does all the work.
BTW: Apparently the 2.0 IPL update isn't needed for normal functioning, probably just for the initial bootstrap.

I already had the initial code and table/key for the 1.0 firmware. I got the new parts from the 2.0 "user mode" memory grab
BTW: The 2.0 loader has a few new keys, and more elaborate logic.
It also has a list of 151 specific 1.x style PRX files that it will no longer load (ie. the 2.0 will load 1.x style PRXs -- needed for games. If you try to use system files from earlier PSP releases, it won't work)

placasoft · Post by **placasoft** » Sat Oct 01, 2005 7:23 am

PSPpet you rellay rocks!!!!

Alcahest · Post by **Alcahest** » Sat Oct 01, 2005 8:23 am

hmm what could I do with netfront.prx now.... ;-)
Is there anyway to launch it?
Later,

Alcahest

Edit: Now it's maybe possible to find out what the differences are between 2.0 JP from july and the one from august..?

train2335 · Post by **train2335** » Sat Oct 01, 2005 2:16 pm

hmm this is all VERY interesting, hopefully someone will turn this into a firmware launcher that can fully launch 2.0

PspPet · Post by **PspPet** » Sun Oct 02, 2005 2:11 am

> hmm what could I do with netfront.prx now.... ;-)
First, you can see the (decoded&expanded) PRX is very big -- almost 1.5MB by itself. You can disassemble the (decrypted) "netfront.prx" module and notice there are ~700 exported entries. You can also see it is directly tied to the libwww.prx library module (~150 exported entries). Another very large PRX module (~1.1MB)

What this tells you => the built-in 2.0 web browser is a very big & fat ;->
BTW: Netfront is owned by a Japanese company (ACCESS CO., LTD). They also do the web browser of the Sony brand CLIE PDAs (which is also big and fat - eating up 2 or 3MB on some PDAs that have less RAM than the PSP)

---
You can't load it under 1.0/1.50 because it is relying on non-trivial additions to the system libraries. The existing Firmware launcher approach can't handle such a significant replacement of components. AFAIK the UMDEmulator approach has similar limitations.
Someone needs to figure out a way of getting into the system before the standard module list is loaded, not after.
Otherwise major system patching will be required.
----
> Now it's maybe possible to find out what the differences are between 2.0 JP from july and the one from august..?
You could do that before (with PsarDumper V1). IIRC there was no difference between the July 2.0 JP and August 2.0 ENG (the update program changed, but the PSAR data didn't)

adresd · Post by **adresd** » Sun Oct 02, 2005 8:53 pm

nice work psppet. seems you are quite busy at the moment :)

Alcahest · Post by **Alcahest** » Mon Oct 03, 2005 1:57 am

Thanks for these details PspPet.
In other unrelated news, apparently a french group (pspteam) just released a 1.50 eboot loader for fw 2.0!?
Later,

Alcahest

PspPet · Post by **PspPet** » Mon Oct 03, 2005 3:15 am

> apparently a french group (pspteam) just released a 1.50 eboot loader for fw 2.0!?
WARNING - it is a fake. It is a program intentionally written to brick your PSP [it deletes four critical files from flash0]

As always be very careful if you download files from untrusted sources.

digihoe · Post by **digihoe** » Thu Oct 13, 2005 6:53 pm

@Psppet

Could you make a new version of your dumper? Since the u8 g_dataPSAR[13200000] is too small to be able to load the new 2.50 firmware... It needs u8 g_dataPSAR[13900000] ...

Thanks and best regards!

PspPet · Post by **PspPet** » Fri Oct 14, 2005 1:47 am

> Could you make a new version of your dumper?
Will do. It will be in "2.0A" bug fix release coming soon (including the size fix and IPL decoding/decrypting)
[in the mean time you can bump up the buffer yourself and rebuild if interested in 2.50]

terryxq · Post by **terryxq** » Fri Oct 14, 2005 2:30 am

great

sherpya · Post by **sherpya** » Fri Oct 14, 2005 5:19 am

does Vampire's patch and buffer increase make psardumper dump correcly 2.50 fw?

sherpya · Post by **sherpya** » Fri Oct 14, 2005 5:57 am

btw worked :P

PspPet · Post by **PspPet** » Fri Oct 14, 2005 8:22 am

Version .02 "A"
http://www.aibohack.com/psp/psardump02a.zip

(should work for all known versions of updater PSAR files - including 2.50)
NOTE: Version 2.50 dump will barely fit on an initially empty 32MB stick

digihoe · Post by **digihoe** » Fri Oct 14, 2005 8:33 am

Nice :-)

Wonder if 2.5 prx files can be loaded in 2.0...

Best regards!

Erant · Post by **Erant** » Thu Oct 27, 2005 1:42 am

I've been looking at the sourcecode, and there are two things that baffle me. First, you talk about precalculated tables produced through step 1. But I find no reference of that step 1. you talk about. I have found the keys in memory however. Also, this demangling key is also something I find hard to grasp, they seem to be sequential, but when I look in my memory dump, the order in which the keys appear are not sequential. So, my question, how do you derive the tables from the key in memory, and how do I find or calculate the demangling key?

PspPet · Post by **PspPet** » Thu Oct 27, 2005 2:20 am

> But I find no reference of that step 1. you talk about
What I call Step1 is the process of taking the 0x90 byte key (found in the data sections of certain system PRX files) and running them through the block cipher. The result is a constant.
What I call Step2 is the process of checking the signature (SHA1 hash)
BTW: Step3 is all the XOR header prep, and Step4 is the actual decryption.

For the purposes of PsarDumper, you don't need all these steps (the results of 'Step1' are a constant, and only a part of Step2 is needed)

> I have found the keys in memory
> but when I look in my memory dump, the order in which the keys appear are not sequential.
I don't understand. If you have found the original keys in the data segments of the PRX files, the format should be relatively obvious.

> So, my question, how do you derive the tables from the key in memory, and how do I find or calculate the demangling key?
"step1" goes something like this:

Code: Select all

memcpy&#40;&g_dataOut&#91;20&#93;, original_key, 0x90&#41;; // input key
u32* pl = &#40;u32*&#41;g_dataOut;
pl&#91;0&#93; = 5;
pl&#91;1&#93; = pl&#91;2&#93; = 0;
pl&#91;3&#93; = code; // depends on which key
pl&#91;4&#93; = 0x90;
&#40;*g_mangleProc&#41;&#40;g_dataOut, 20+0x90, g_dataOut, 20+0x90, 7&#41;;
memcpy&#40;result_of_step1, g_dataOut, 0x90&#41;;

You can't change any of these values - so this is a fancy way of calculating a 0x90 byte constant from another 0x90 byte constant.
The mangleProc/semaphore2 call with last arg of "7" appears to be a block cipher - exact details unknown. Used in several places.
BTW: This is getting off topic for PSarDumper (and getting into the encryption technology of the device)

Erant · Post by **Erant** » Thu Oct 27, 2005 2:56 am

PspPet wrote: > I have found the keys in memory
> but when I look in my memory dump, the order in which the keys appear are not sequential.
I don't understand. If you have found the original keys in the data segments of the PRX files, the format should be relatively obvious.

> So, my question, how do you derive the tables from the key in memory, and how do I find or calculate the demangling key?
"step1" goes something like this:
Code: Select all
memcpy&#40;&g_dataOut&#91;20&#93;, original_key, 0x90&#41;; // input key
u32* pl = &#40;u32*&#41;g_dataOut;
pl&#91;0&#93; = 5;
pl&#91;1&#93; = pl&#91;2&#93; = 0;
pl&#91;3&#93; = code; // depends on which key
pl&#91;4&#93; = 0x90;
&#40;*g_mangleProc&#41;&#40;g_dataOut, 20+0x90, g_dataOut, 20+0x90, 7&#41;;
memcpy&#40;result_of_step1, g_dataOut, 0x90&#41;;
You can't change any of these values - so this is a fancy way of calculating a 0x90 byte constant from another 0x90 byte constant.

What I ment was this:

{ 0x4467415d, (u8*)g_key44, 0x59, 0x59 }

The first is the tag found at offset 0xD0, the second is the key I found in memory (I found the key in memory by searching for the tag, I never looked at PRX files for the key), but the two codes after that baffle me. The seem to be sequential, 0x59, 0x5A, 0x5B, but when I look in the 2.00 memory dump, they're not right next to each other, and the 0x59 one is somewhere in the middle of a massive block of code. The ones with 0x5A and 0x5B are seperated by another key. So how did you derive these codes? Because if I look at your sourcecode closely, these are the keys used for demangling. I've added comments where I assume things. Reading code was never one of my strengths

Code: Select all

static void ExtraV2Mangle&#40;u8* buffer1, u8 codeExtra&#41;
&#123;
    static u8 g_dataTmp&#91;20+0xA0&#93; __attribute__&#40;&#40;aligned&#40;0x40&#41;&#41;&#41;;
    u8* buffer2 = g_dataTmp; // aligned

    memcpy&#40;buffer2+20, buffer1, 0xA0&#41;; // move the PRX file into another buffer, creating room in front of the buffer for following step.
    u32* pl2 = &#40;u32*&#41;buffer2;  //make a pointer to buffer.
    pl2&#91;0&#93; = 5;
    pl2&#91;1&#93; = pl2&#91;2&#93; = 0;
    pl2&#91;3&#93; = codeExtra;
    pl2&#91;4&#93; = 0xA0;       // Length of header?

    int ret = &#40;*g_mangleProc&#41;&#40;buffer2, 20+0xA0, buffer2, 20+0xA0, 7&#41;;
    if &#40;ret != 0&#41;
        printf&#40;"extra de-mangle returns %d\n", ret&#41;;
    // copy result back
    memcpy&#40;buffer1, buffer2, 0xA0&#41;;
&#125;

Am I correct in assuming that 0xA0 is the length of the header?

PspPet · Post by **PspPet** » Thu Oct 27, 2005 3:37 am

> What I ment was this:
> { 0x4467415d, (u8*)g_key44, 0x59, 0x59 }
My guess: the byte "code" is a seed used by the block cipher.
There are other 'code' values. There are other 0x90 byte key blocks too [something like 16 in V1, and new ones added in V2]. The 0x90 byte key block must be combined with the correct byte "code"
The ones included in PsarDumper are the bare minimum needed

> So how did you derive these codes?
Reverse engineering (disassemble the code that calls them)
BTW: for a disassembly (not mine) of the low level guts, see this thread: http://forums.ps2dev.org/viewtopic.php?t=3573 and posts by 'florinsasu'

>Am I correct in assuming that 0xA0 is the length of the header?
I call it the length of the "block". The header structure is more complicated. This "block cipher" is used several times to mangle the header bytes in several places to make it hard to understand and harder to hack. Since we don't know how to reverse the block cipher, it provides security.

PSAR Dumper 2.0 (PRX 2.0 format decrypted)

PSAR Dumper 2.0 (PRX 2.0 format decrypted)

mph source