PSAR Dumper 2.0 (PRX 2.0 format decrypted)

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

PspPet
Posts: 210
Joined: Wed Mar 30, 2005 2:13 am
Contact:

PSAR Dumper 2.0 (PRX 2.0 format decrypted)

Post by PspPet »

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).
User avatar
groepaz
Posts: 305
Joined: Thu Sep 01, 2005 7:44 am
Contact:

Post by groepaz »

amazing, great work
User avatar
dot_blank
Posts: 498
Joined: Wed Sep 28, 2005 8:47 am
Location: Brasil

Post by dot_blank »

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
10011011 00101010 11010111 10001001 10111010
Warren
Posts: 175
Joined: Sat Jan 24, 2004 8:26 am
Location: San Diego, CA

Post by Warren »

Good work PspPet
Ninja
Posts: 3
Joined: Mon Mar 28, 2005 3:42 pm
Location: K.Lumpur

Post by Ninja »

Great work..

I guess we can load the decrypted PRX using MPH Firmware Launcher or UMD Emulator?
nem
Posts: 73
Joined: Thu Jan 13, 2005 9:21 pm
Contact:

Post by nem »

Great work!
How did you manage to get the table?
IPL hack or something like that?
ice-master
Posts: 6
Joined: Thu May 19, 2005 6:52 pm

Post by ice-master »

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
Posts: 49
Joined: Mon Jul 04, 2005 1:31 am

mph source

Post by pspkrazy »

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
Posts: 58
Joined: Wed Jun 15, 2005 8:24 pm

Post by Chrighton »

Very nice work :)
jockyw2001
Posts: 339
Joined: Thu Sep 29, 2005 4:19 pm

Post by jockyw2001 »

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

/JockyW
User avatar
groepaz
Posts: 305
Joined: Thu Sep 01, 2005 7:44 am
Contact:

Post by groepaz »

How did you manage to get the table?
IPL hack or something like that?
yeah please explain :)
PspPet
Posts: 210
Joined: Wed Mar 30, 2005 2:13 am
Contact:

Post by PspPet »

> 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
Posts: 53
Joined: Mon Mar 28, 2005 10:53 am

Post by placasoft »

PSPpet you rellay rocks!!!!
Alcahest
Posts: 135
Joined: Fri Mar 25, 2005 2:08 am

Post by Alcahest »

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
Posts: 17
Joined: Sat Oct 01, 2005 2:13 pm
Location: USA
Contact:

Post by train2335 »

hmm this is all VERY interesting, hopefully someone will turn this into a firmware launcher that can fully launch 2.0
PspPet
Posts: 210
Joined: Wed Mar 30, 2005 2:13 am
Contact:

Post by PspPet »

> 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
Posts: 43
Joined: Sat Jan 17, 2004 11:32 am

Post by adresd »

nice work psppet. seems you are quite busy at the moment :)
Alcahest
Posts: 135
Joined: Fri Mar 25, 2005 2:08 am

Post by Alcahest »

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
Posts: 210
Joined: Wed Mar 30, 2005 2:13 am
Contact:

Post by PspPet »

> 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
Posts: 108
Joined: Sat May 14, 2005 7:40 pm

Post by digihoe »

@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
Posts: 210
Joined: Wed Mar 30, 2005 2:13 am
Contact:

Post by PspPet »

> 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
Posts: 16
Joined: Wed Oct 12, 2005 9:27 pm

Post by terryxq »

great
User avatar
sherpya
Posts: 61
Joined: Mon Oct 03, 2005 5:49 pm

Post by sherpya »

does Vampire's patch and buffer increase make psardumper dump correcly 2.50 fw?
User avatar
sherpya
Posts: 61
Joined: Mon Oct 03, 2005 5:49 pm

Post by sherpya »

btw worked :P
PspPet
Posts: 210
Joined: Wed Mar 30, 2005 2:13 am
Contact:

Post by PspPet »

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
Posts: 108
Joined: Sat May 14, 2005 7:40 pm

Post by digihoe »

Nice :-)

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

Best regards!
Erant
Posts: 33
Joined: Fri May 13, 2005 6:19 am

Post by Erant »

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?
Live free, prosper, and under my rule.
PspPet
Posts: 210
Joined: Wed Mar 30, 2005 2:13 am
Contact:

Post by PspPet »

> 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(&g_dataOut[20], original_key, 0x90); // input key
u32* pl = (u32*)g_dataOut;
pl[0] = 5;
pl[1] = pl[2] = 0;
pl[3] = code; // depends on which key
pl[4] = 0x90;
(*g_mangleProc)(g_dataOut, 20+0x90, g_dataOut, 20+0x90, 7);
memcpy(result_of_step1, g_dataOut, 0x90);
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
Posts: 33
Joined: Fri May 13, 2005 6:19 am

Post by Erant »

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(&g_dataOut[20], original_key, 0x90); // input key
u32* pl = (u32*)g_dataOut;
pl[0] = 5;
pl[1] = pl[2] = 0;
pl[3] = code; // depends on which key
pl[4] = 0x90;
(*g_mangleProc)(g_dataOut, 20+0x90, g_dataOut, 20+0x90, 7);
memcpy(result_of_step1, g_dataOut, 0x90);
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(u8* buffer1, u8 codeExtra)
{
    static u8 g_dataTmp[20+0xA0] __attribute__((aligned(0x40)));
    u8* buffer2 = g_dataTmp; // aligned

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

    int ret = (*g_mangleProc)(buffer2, 20+0xA0, buffer2, 20+0xA0, 7);
    if (ret != 0)
        printf("extra de-mangle returns %d\n", ret);
    // copy result back
    memcpy(buffer1, buffer2, 0xA0);
}
Am I correct in assuming that 0xA0 is the length of the header?
Live free, prosper, and under my rule.
PspPet
Posts: 210
Joined: Wed Mar 30, 2005 2:13 am
Contact:

Post by PspPet »

> 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.
Post Reply