PSP Download Applet

Danj · Post by **Danj** » Sat May 21, 2005 4:30 am

piercer wrote:OK a question for UTF knowledgeable out there.

My nickname is Piercer on my PSP looking at the way this is stored in DATA2.BIN decrrypted/dehashed of course it looks like

50EFBD P
89EFBD i
85EFBD e
92EFBD r
83EFBD c
85EFBD e
92E38080 r (but slightly different) ????

What for of UTF is this - even though its supposed to be UTF8.

Any info on this encoding and how to view it as ascii?

Searching on the net reveals this page which would appear to suggest it's a UTF-8 conversion of SJIS (logical, since the PSP is Japanese).

piercer · Post by **piercer** » Sat May 21, 2005 2:46 pm

I have checked the decoding, am using the SHA1CypherStream class and the nickName 'Piercer' is definitely stored in the following set of bytes in the following order (at least I see this after the xor with the cypher stream buffer which does not change the data length, so I assume the EFBD's are not added by this process)

0: 80 P
1: -17
2: -67
3: -119 i
4: -17
5: -67
6: -123 e
7: -17
8: -67
9: -110 r
10: -17
11: -67
12: -125 c
13: -17
14: -67
15: -123 e
16: -17
17: -67
18: -110 r
19: -29
20: -128
21: -128
22: 0 end of string

Can anybody shed any more light on this?

th0mas · Post by **th0mas** » Sat May 21, 2005 3:20 pm

what more do you need? danj's post showed you the spec on what it is, my post shows how to get the ASCII from it...

piercer · Post by **piercer** » Sat May 21, 2005 3:54 pm

The java code in IdentityCollection converts these bytes to a nickname by a new String(bytes,0,length of 0 terminated byte string,"UTF8"). This specifies a UTF8 encoding. I am trying to work out how this is a UTF8 encoding, that is all.

I am trying a few dictionary style attacks on save files, but need to know how strings should be represented for my search. That is why I ask the question.

How should 'Conrad' be searched for? What should the bytes I am looking for look like? That sort of thing. Sorry if this is a pointless way of approaching things, but I have to try.

Danj · Post by **Danj** » Sat May 21, 2005 7:55 pm

piercer wrote:The java code in IdentityCollection converts these bytes to a nickname by a new String(bytes,0,length of 0 terminated byte string,"UTF8"). This specifies a UTF8 encoding. I am trying to work out how this is a UTF8 encoding, that is all.

I am trying a few dictionary style attacks on save files, but need to know how strings should be represented for my search. That is why I ask the question.

How should 'Conrad' be searched for? What should the bytes I am looking for look like? That sort of thing. Sorry if this is a pointless way of approaching things, but I have to try.

Not quite sure why you're using signed decimal numbers to represent your bytes, I find it much easier to use hex. Anyway, looking at what th0mas wrote, I would say that the sequence of bytes you're looking for is:

Code: Select all

43 EF BD    C
8F EF BD    o
8E EF BD    n
92 EF BD    r
81 EF BD    a
84 E3 80 80 d + string terminator

steddy · Post by **steddy** » Sat May 21, 2005 9:14 pm

Can someone please explain to me how this is used?

I have a JAP 1.5 PSP with a US Wipeout disk. I am wondering if the PSP will run unsigned JAR files and would like to test this. We are all assuming it won't, but this may be what the 1.51. firmware was to lock down.

Any ideas on how to reference the JAR file from within Wipeout browser to see if it will work?

PS if you haven't done so already download and decompile all the modules with JAD (below). Makes for some interesting reading.

http://kpdus.tripod.com/jad.html

Steddy

piercer · Post by **piercer** » Sat May 21, 2005 9:23 pm

It is not designed to run on a PSP, but inside a browser on your PC while the PSP is connected.

The only useful thing found out so far is the hashing/encryption technique used for storing DATA2.BIN

steddy · Post by **steddy** » Sun May 22, 2005 4:16 am

Thanks for taking the time to explain that to me.

How do I compile the example decoder you posted on the previous page without getting an error? I added this line to the top and copied the .jar file to my CLASSPATH but it reports the package does not exist:-

import net.scee.drm.mypsp.download.hash;

Thanks
Steddy

steddy · Post by **steddy** » Sun May 22, 2005 4:42 am

Ignore the last post...... apologies for being dumb. Got it working now.

Steddy

steddy · Post by **steddy** » Tue May 24, 2005 3:24 am

Has anyone worked out if anything PSP side actually uses these files?

\PSP\SAVEDATA\PPCD00001DLS001\DATA1.BIN
\PSP\SAVEDATA\PPCD00001DLS001\DATA2.BIN

I tried deleting them from the memory card and they weren't recreated even after entering games and creating save files. I am looking at exploits around this and need to understand when they may be actually used.

Cheers
Steddy

pedroleite · Post by **pedroleite** » Tue May 24, 2005 5:37 am

This directory, on my system, is recreated whenever I run wipeout out and load or create a new profile. I tried this long ago.

The seed's on the file change... on PARAM.SFO (the binary fields) and the .BIN files.

Does anyone saw if other game besides Wipeout Pure created the files?

steddy · Post by **steddy** » Tue May 24, 2005 6:25 am

Thanks, that did it. Just loaded a profile and they appear.

I can't work out what its actually using it for though... I created a decrypted version of the file less key and placed it on the memory card and it just overwrote it with an encrypted one.

I also extended the file size by duplicating the file multiple times onto itself upto 17mb and no error was generated in Wipeout and it just regenerated it. It seems to throw this file away and just regenerate it every time, just PRIOR to displaying the Load / New profile screen.

Seems it may be created every time at startup and only read by the Wipeout website when doing an update :(

Steddy

BTW what did you mean about using the timestamp as the Seed? The only seed used is the 20 byte key at the end of the file.

pedroleite · Post by **pedroleite** » Tue May 24, 2005 6:28 am

steddy wrote:BTW what did you mean about using the timestamp as the Seed? The only seed used is the 20 byte key at the end of the file.

I don't see a Timestamp being mentioned... The seed changes every time the file is recreated, if your compare the files, you can easily see where.

steddy · Post by **steddy** » Tue May 24, 2005 7:14 am

This is the comment I was referring too 'The seed's on the file change'. I read this to mean based upon the lastModified timestamp.

The entire file is completely different every time it is created, not just a particular part of it. This is most likely because a new key is created each time and place somewhere in the fle.

I am trying to decode SAVEGAME bin files using a similar method with the key at the beginning or end of the file. I have also tried varying key lengths and even the timestamp as the key but still no luck.

Ta
Steddy

pedroleite · Post by **pedroleite** » Tue May 24, 2005 8:13 am

From all i've read here on the last months...

In this form of encryption - simmetric, or shared secret - there are two factors, the key, and the IV or seed. Using the same key but a different IV leads to a diferent output from the same input.

This is what changes... those 20 bytes used as SEED (or IV). The key and the decoded form is the same. This could be random.

On the PARAM.SFO there are several binary structures still unknown. 16 bytes after the file name and 32 bytes on other section.

Until all the file structures are untangled, it's too hard to find a key.

I couldn't yet see where there's an RSA encoded key (or seed), to be decoded by the public certificates on the flash...

(Now that the flash is writable (in 1.0 firmware using homebrew) one could write a new certificate to validate these assumptions)