forums.ps2dev.org Forum Index forums.ps2dev.org
Homebrew PS2, PSP & PS3 Development Discussions
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

PSAR Dumper 2.0 (PRX 2.0 format decrypted)
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    forums.ps2dev.org Forum Index -> PSP Development
View previous topic :: View next topic  
Author Message
PspPet



Joined: 30 Mar 2005
Posts: 210

PostPosted: Fri Sep 30, 2005 3:13 pm    Post subject: PSAR Dumper 2.0 (PRX 2.0 format decrypted) Reply with quote

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).
Back to top
View user's profile Send private message Send e-mail Visit poster's website
groepaz



Joined: 01 Sep 2005
Posts: 305

PostPosted: Fri Sep 30, 2005 4:27 pm    Post subject: Reply with quote

amazing, great work
_________________
http://www.hitmen-console.org
http://hitmen.c02.at/files/yapspd/
Back to top
View user's profile Send private message Visit poster's website
dot_blank



Joined: 28 Sep 2005
Posts: 498
Location: Brasil

PostPosted: Fri Sep 30, 2005 4:30 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Warren



Joined: 24 Jan 2004
Posts: 173
Location: San Diego, CA

PostPosted: Fri Sep 30, 2005 4:48 pm    Post subject: Reply with quote

Good work PspPet
Back to top
View user's profile Send private message
Ninja



Joined: 28 Mar 2005
Posts: 3
Location: K.Lumpur

PostPosted: Fri Sep 30, 2005 6:43 pm    Post subject: Reply with quote

Great work..

I guess we can load the decrypted PRX using MPH Firmware Launcher or UMD Emulator?
Back to top
View user's profile Send private message
nem



Joined: 13 Jan 2005
Posts: 73

PostPosted: Fri Sep 30, 2005 8:21 pm    Post subject: Reply with quote

Great work!
How did you manage to get the table?
IPL hack or something like that?
Back to top
View user's profile Send private message Visit poster's website
ice-master



Joined: 19 May 2005
Posts: 6

PostPosted: Fri Sep 30, 2005 9:06 pm    Post subject: Reply with quote

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)

++
Back to top
View user's profile Send private message
pspkrazy



Joined: 04 Jul 2005
Posts: 49

PostPosted: Fri Sep 30, 2005 9:26 pm    Post subject: mph source Reply with quote

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 ! :)
Back to top
View user's profile Send private message
Chrighton



Joined: 15 Jun 2005
Posts: 58

PostPosted: Sat Oct 01, 2005 12:46 am    Post subject: Reply with quote

Very nice work :)
Back to top
View user's profile Send private message
jockyw2001



Joined: 29 Sep 2005
Posts: 339

PostPosted: Sat Oct 01, 2005 1:36 am    Post subject: Reply with quote

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

/JockyW
Back to top
View user's profile Send private message
groepaz



Joined: 01 Sep 2005
Posts: 305

PostPosted: Sat Oct 01, 2005 1:36 am    Post subject: Reply with quote

Quote:

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


yeah please explain :)
_________________
http://www.hitmen-console.org
http://hitmen.c02.at/files/yapspd/
Back to top
View user's profile Send private message Visit poster's website
PspPet



Joined: 30 Mar 2005
Posts: 210

PostPosted: Sat Oct 01, 2005 1:44 am    Post subject: Reply with quote

> 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)
Back to top
View user's profile Send private message Send e-mail Visit poster's website
placasoft



Joined: 28 Mar 2005
Posts: 53

PostPosted: Sat Oct 01, 2005 7:23 am    Post subject: Reply with quote

PSPpet you rellay rocks!!!!
Back to top
View user's profile Send private message
Alcahest



Joined: 25 Mar 2005
Posts: 135

PostPosted: Sat Oct 01, 2005 8:23 am    Post subject: Reply with quote

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..?
Back to top
View user's profile Send private message
train2335



Joined: 01 Oct 2005
Posts: 17
Location: USA

PostPosted: Sat Oct 01, 2005 2:16 pm    Post subject: Reply with quote

hmm this is all VERY interesting, hopefully someone will turn this into a firmware launcher that can fully launch 2.0
Back to top
View user's profile Send private message Visit poster's website AIM Address MSN Messenger
PspPet



Joined: 30 Mar 2005
Posts: 210

PostPosted: Sun Oct 02, 2005 2:11 am    Post subject: Reply with quote

> 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)
Back to top
View user's profile Send private message Send e-mail Visit poster's website
adresd



Joined: 17 Jan 2004
Posts: 43

PostPosted: Sun Oct 02, 2005 8:53 pm    Post subject: Reply with quote

nice work psppet. seems you are quite busy at the moment :)
Back to top
View user's profile Send private message
Alcahest



Joined: 25 Mar 2005
Posts: 135

PostPosted: Mon Oct 03, 2005 1:57 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
PspPet



Joined: 30 Mar 2005
Posts: 210

PostPosted: Mon Oct 03, 2005 3:15 am    Post subject: Reply with quote

> 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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
digihoe



Joined: 14 May 2005
Posts: 108

PostPosted: Thu Oct 13, 2005 6:53 pm    Post subject: Reply with quote

@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!
Back to top
View user's profile Send private message
PspPet



Joined: 30 Mar 2005
Posts: 210

PostPosted: Fri Oct 14, 2005 1:47 am    Post subject: Reply with quote

> 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]
Back to top
View user's profile Send private message Send e-mail Visit poster's website
terryxq



Joined: 12 Oct 2005
Posts: 16

PostPosted: Fri Oct 14, 2005 2:30 am    Post subject: Reply with quote

great
Back to top
View user's profile Send private message
sherpya



Joined: 03 Oct 2005
Posts: 61

PostPosted: Fri Oct 14, 2005 5:19 am    Post subject: Reply with quote

does Vampire's patch and buffer increase make psardumper dump correcly 2.50 fw?
Back to top
View user's profile Send private message
sherpya



Joined: 03 Oct 2005
Posts: 61

PostPosted: Fri Oct 14, 2005 5:57 am    Post subject: Reply with quote

btw worked :P
Back to top
View user's profile Send private message
PspPet



Joined: 30 Mar 2005
Posts: 210

PostPosted: Fri Oct 14, 2005 8:22 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Send e-mail Visit poster's website
digihoe



Joined: 14 May 2005
Posts: 108

PostPosted: Fri Oct 14, 2005 8:33 am    Post subject: Reply with quote

Nice :-)

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

Best regards!
Back to top
View user's profile Send private message
Erant



Joined: 13 May 2005
Posts: 33

PostPosted: Thu Oct 27, 2005 1:42 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
PspPet



Joined: 30 Mar 2005
Posts: 210

PostPosted: Thu Oct 27, 2005 2:20 am    Post subject: Reply with quote

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

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)
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Erant



Joined: 13 May 2005
Posts: 33

PostPosted: Thu Oct 27, 2005 2:56 am    Post subject: Reply with quote

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:

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:

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.
Back to top
View user's profile Send private message
PspPet



Joined: 30 Mar 2005
Posts: 210

PostPosted: Thu Oct 27, 2005 3:37 am    Post subject: Reply with quote

> 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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.ps2dev.org Forum Index -> PSP Development All times are GMT + 10 Hours
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
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