New savedata encryption and decryption samples for 2.0

jimparis · Post by **jimparis** » Sun Dec 11, 2005 6:51 am

psp123 and I have figured out the new savedata encryption format in 2.0.

The new save format, used by games like GTA, SOCOM, and The Hustle, cannot be decrypted by the sceUtilitySavedata* functions on a 1.0/1.5 PSP, and most of the functions in sceUtility do not work properly from VSH mode, which is all we have access to on 2.0. Instead, we use the VSH sceChnnlsv module to do the work.

Each game has a unique key in the new format. This key has to be found in the game binary. When encrypting a save, two or three hashes also need to be updated in PARAM.SFO. Interestingly, the generated hashes are specific to each PSP, but can be verified (and will therefore work) on any PSP.

I have added two new samples to the pspsdk:

Code: Select all

$ ls samples/savedata/decrypt
Makefile  README.txt  decrypt.c  decrypt.h  main.c
$ ls samples/savedata/encrypt
Makefile  README.txt  encrypt.c  encrypt.h  hash.c  hash.h  main.c  psf.c  psf.h

Both samples work with both the new and old save formats. The decrypt sample takes a single data file (e.g. DATA.BIN). The encrypt sample also needs to know which PARAM.SFO to update. It only supports modifying the hashes in an existing PARAM.SFO, not creating a new one. The filenames in each sample are hardcoded. psp123 plans on releasing a more user-friendly version soon.

The samples currently only work on 2.0 in VSH mode through Fanjita's loader (tested with 0.8.5). Getting them to work on 1.0 and 1.5 will involve either figuring out how to load the sceChnnlsv module, or by rewriting the samples to call the lower semaphore_4C537C72 directly.

The main purpose in doing this was to recreate EdisonCarter's work, which he chose not to reveal, in order to repeat his success with the GTA exploit. See http://forums.ps2dev.org/viewtopic.php?t=4336.

Bitmap1 · Post by **Bitmap1** » Sun Dec 11, 2005 5:38 pm

Hi, I was talking with psp123 and I made a small sample exploit here.

psp123 & jimp thought it would be a good idea for me to post it here, so I am doing so now.

There are some notes about it:
1) Its coded to auto search for NID's by looking for the module_info for gta, so it should work on any firmware revision.

2) Printing text to the screen is a bit weird. The hello world 2 sample's Print didnt work properly, and Fillvram(0) blacked out most of the screen but a few lines at the bottom.

There's some more info inside the rar, should be of more use when psp123 & jimp's program is released to encrypt/decrypt.

http://rapidshare.de/files/8966422/gtae ... c.rar.html

Fanjita · Post by **Fanjita** » Mon Dec 12, 2005 4:23 am

A few things I've discovered while messing with this:

Printing to screen is hard, there's something odd going on with the vram addresses.

If you just go with the framebuffer that's currently set, you can print to the screen without major problems, but if you try to set your own, it doesn't tend to work.

The flash appears to be highly locked down, I was unable to gain any access to it, which suggests that a downgrader will be hard.

All the threads are user-mode. The thread running the exploit ("mainthread") appears not to be in contention with any others for the screen.

The fact that the threads are user-mode suggests that this exploit will be slightly more locked-down than the TIFF exploit (which runs in VSH). :-(

I have a basic BIN loader that works for 2.0 (and therefore probably 2.01) - PM me if you want it.

Fanjita · Post by **Fanjita** » Tue Dec 13, 2005 1:46 am

Basic hello world loader now posted to pspupdates.com - see enclosed readme for instructions and restrictions on using it to load other stuff. The advantage of the loader is that you won't need to mess about with the savegame any more, to run basic apps.

The loader uses Bitmap1's NID resolution scheme, so it should run on all GTA-supported firmware. Note that the list of NIDs available in this way under GTA is quite restricted. I'll be using a more complete but static method within the EBOOT loader, to support the missing ones.

derFeef · Post by **derFeef** » Tue Dec 13, 2005 7:12 am

Hi,

great work man!
I tested it but its not working for me.
after loading the savegame the screen turns black and the psp is shutting down.
I am using the EU-version of the game with 2.5 firmware.

keep on with the good work

Fanjita · Post by **Fanjita** » Tue Dec 13, 2005 12:08 pm

There's an intermittent problem with SetFrameBuffer, that makes it not work some of the time. You should find that after a few goes, it works fine.

I had a version running more stably on 2.0, but it relied on a hardcoded value for the GetFrameBuffer syscall, which isn't available dynamically with Bitmap1's method, so I had to go with the less reliable SetFrameBuffer option. I might produce a HW patch that addresses this with a few more smarts (shouldn't be hard to deduce GetFrameBuffer from SetFrameBuffer), since I'd like to see confirmation that the process works reliably on all firmwares.

imhotep · Post by **imhotep** » Tue Dec 13, 2005 9:19 pm

two questions for you, fanjita:

1. when in the game, is the exploit in user-mode only (sorry, but i haven't got the answer from a reliable post yet)?

2. elz-dev created a 2.0 umd dump utility (partial dump). does it function in user-mode or is using the umd a kernel thing?

thanks

Post by **mrbrown** » Tue Dec 13, 2005 11:31 pm

imhotep wrote:1. when in the game, is the exploit in user-mode only (sorry, but i haven't got the answer from a reliable post yet)?

2. elz-dev created a 2.0 umd dump utility (partial dump). does it function in user-mode or is using the umd a kernel thing?

1. All games run in user mode. There is no known way to access the kernel once you're in user mode.

2. Asking about UMD ripping tools is one of the fastest ways to get banned on this site.

imhotep · Post by **imhotep** » Tue Dec 13, 2005 11:43 pm

thanks for the answer and the tip, won't do it again :)

Fanjita · Post by **Fanjita** » Fri Dec 16, 2005 11:30 am

I've got some dumps of the NID->syscall mappings for v2.01, 2.5 and 2.6.

These are just the NIDs that have been resolved within the GTA memdump, but they're a good starting point for filling in the remaining gaps.

The bad news for v2.6 is that manual syscall resolution suddenly got a lot harder:

The NIDs in the export list appear to be shuffled, relative to previous versions, so you can't deduce an unlisted syscall directly from a previously-adjacent one.
The syscalls appear to be allocated from an essentially RANDOM base index, each time the app is started. Within these lists, they stay in order, but the actual syscall values change each time.

So it seems that to be able to resolve syscalls on 2.6, we have to either decrypt the firmware to find the new export order, or research the order using trial and error with functions with known effects.

Anyway, here are links to the data, for anyone that will find it useful:

2.0/2.01
2.5
2.6 (one instance)

Vampire · Post by **Vampire** » Fri Dec 16, 2005 11:12 pm

Fanjita wrote:I've got some dumps of the NID->syscall mappings for v2.01, 2.5 and 2.6.

These are just the NIDs that have been resolved within the GTA memdump, but they're a good starting point for filling in the remaining gaps.

this is the syscall list for 2.00/2.01 game-mode:
http://home.zhwin.ch/~oem/syscalls_game_2.00.txt

jtwald · Post by **jtwald** » Wed Jan 04, 2006 3:18 am

What has happened to the simple user friendly GUI decryptor/encryptor?

Has development been abandoned?

I have been thinking of making my own, so the general public could play with save files.

EDIT:
I found GTA's key hardcoded into the source of the decrypt main.c, but I still want to know how to find the key on my own from any game. If someone could explain that I would appreciate it.

EDIT:
I have the dumped BOOT.BIN file from SOCOM Fireteam Bravo. I'm assuming the key is somewhere in this file, so if someone could point me where to look (a specific offset, reference, or method to follow?) I would appreciate it.

jtwald · Post by **jtwald** » Thu Jan 05, 2006 10:18 am

Another thing which I've been wondering.. Is this exploit in all 2.0+ save files, or all save files in general?

If I do a pattern search of the hash on the GTA dump will it turn up, so I know where to find it on other game dumps? Or will someone explain that please, I can't find any documentation on finding the game's hash.

jimparis · Post by **jimparis** » Thu Jan 05, 2006 11:22 am

jtwald wrote:What has happened to the simple user friendly GUI decryptor/encryptor?

psp123 was working on one, and I think he was mostly done, but I haven't heard from him lately. It looks like another one was recently released here but I believe it's only for old format saves at the moment.

jtwald wrote:I found GTA's key hardcoded into the source of the decrypt main.c, but I still want to know how to find the key on my own from any game. If someone could explain that I would appreciate it.

The 16-byte key is stored at offset 0x5DC in the structure passed to sceUtilitySavedataInitStart, so you'll have to find the code that copies it there in each game. Yes, it would typically be in BOOT.BIN, although a future game could of course do all sorts of tricks like obfuscating it or reading it from some other file.

Is this exploit in all 2.0+ save files, or all save files in general?

This topic is about the savedata encryption code, which works on all save files currently out there. Any particular code exploits like the GTA one are game-specific.

jtwald · Post by **jtwald** » Thu Jan 05, 2006 2:37 pm

jimparis wrote:
jtwald wrote:What has happened to the simple user friendly GUI decryptor/encryptor?
psp123 was working on one, and I think he was mostly done, but I haven't heard from him lately. It looks like another one was recently released here but I believe it's only for old format saves at the moment.

jtwald wrote:I found GTA's key hardcoded into the source of the decrypt main.c, but I still want to know how to find the key on my own from any game. If someone could explain that I would appreciate it.
The 16-byte key is stored at offset 0x5DC in the structure passed to sceUtilitySavedataInitStart, so you'll have to find the code that copies it there in each game. Yes, it would typically be in BOOT.BIN, although a future game could of course do all sorts of tricks like obfuscating it or reading it from some other file.

Is this exploit in all 2.0+ save files, or all save files in general?
This topic is about the savedata encryption code, which works on all save files currently out there. Any particular code exploits like the GTA one are game-specific.

Thanks for the help. I'm looking to inject my own trainer of sorts into SOCOM. I havn't really been involved much with the ps2/psp dev scene but I am with ps2/psp game hacking. I know C++, Java, and a good amount of MIPs (need it for game hacking), just before this I never bothered setting up the PS2/PSP dev environment

What particular flaw/bug allowed the GTA save to load and inject his code? So I can try to reproduce it in a SOCOM save.

Sorry for all these questions.

jimparis · Post by **jimparis** » Thu Jan 05, 2006 3:22 pm

Some info here, but that's getting off topic for here, and won't really help you with socom anyway.

lS[UMD/2kdlSU] · Post by **lS[UMD/2kdlSU]** » Fri Jan 06, 2006 1:50 am

Hmm, I don't understand what are you doing and what you know so much...

jimparis wrote:
jtwald wrote:What has happened to the simple user friendly GUI decryptor/encryptor?
psp123 was working on one, and I think he was mostly done, but I haven't heard from him lately. It looks like another one was recently released here but I believe it's only for old format saves at the moment.

I've(and some person including psp123?) already succeeded 2.xx savedata decryption on 1.x0 firmware.
# Cheatworks PSP uses chnnlsv.prx and some modification makes it supporting 2.xx savedata encryption easily.
But my method needs 2.xx chnnlsv, which is Sony's material.
And please don't forget it, it is now only beta version;)

How? (using PSPSDK sample ...It is very simple method!)
1. Patch chnnlsv.S or create original sceChnnlsv stub.

Code: Select all

# 2nd argument must be 0x40090000 to use "Dynamic Link".
STUB_START "sceChnnlsv",0x40090000,0x00060005
 ~~~ stub code ~~~

2. Set kernel attribute

Code: Select all

PSP_MODULE_INFO&#40;"AS YOU LIKE...", 0x1000, 1, 1&#41;;

3. And put code which loads chnnlsv.prx in MemoryStick.
# beta1 uses flash0:/vsh/module/chnnlsv.prx
(using PSAR dumper? use ms0:/OUTX/chnnlsv.prx)

Code: Select all

// &#40;code from Cheatworks PSP source code&#41;
pspSdkInstallNoDeviceCheckPatch&#40;&#41;;
pspSdkInstallNoPlainModuleCheckPatch&#40;&#41;;
pspSdkLoadStartModule&#40;"ms0&#58;/OUTX/chnnlsv.prx", 1&#41;

If i don't figure the story out, excuse me for my poor English reading...

jimparis · Post by **jimparis** » Fri Jan 06, 2006 2:18 am

lS[UMD/2kdlSU] wrote:But my method needs 2.xx chnnlsv, which is Sony's material.

Chnnlsv is a fairly simple module that just uses semaphore_4C537C72 to do all of the work. It wouldn't be too hard to recreate it and directly call that function instead.

lS[UMD/2kdlSU] · Post by **lS[UMD/2kdlSU]** » Fri Jan 06, 2006 9:39 am

jimparis wrote:
lS[UMD/2kdlSU] wrote:But my method needs 2.xx chnnlsv, which is Sony's material.
Chnnlsv is a fairly simple module that just uses semaphore_4C537C72 to do all of the work. It wouldn't be too hard to recreate it and directly call that function instead.

Thsnk you!
I'll try it.

jtwald · Post by **jtwald** » Sat Jan 28, 2006 4:34 pm

The Fanjita Beta GTA eLoader is now released..

Now I've run into some problems.

These ecrypt/encrypt samples will not run on a 2.01 PSP using the GTA eBoot loader.

I would apreciate it if you had any insight on code to change or could post new samples that are compatible with 2.01 and 2.5 GTA eLoader.

The current ones reset your psp on the Working.. message.

Fanjita · Post by **Fanjita** » Sat Jan 28, 2006 11:36 pm

Most likely because that beta loader appears to have some sort of scribbler that makes it very unstable. There's not much I can suggest, until those bugs are fixed.

ditlew · Post by **ditlew** » Thu Feb 02, 2006 6:14 pm

You can't use the eLoader for the current encryption/decryption eboots, since they needs to be run in VSH mode (according to the top post by jimparis) and the eLoader runs in GAME mode.

// Ditlew

jtwald · Post by **jtwald** » Fri Feb 03, 2006 2:55 am

ditlew wrote:You can't use the eLoader for the current encryption/decryption eboots, since they needs to be run in VSH mode (according to the top post by jimparis) and the eLoader runs in GAME mode.

// Ditlew

Is it possible to modify these samples to run in game mode?

Or are some features used only availabe in VSH mode.

jimparis · Post by **jimparis** » Fri Feb 03, 2006 4:25 am

Did you read http://forums.ps2dev.org/viewtopic.php?p=34482#34482? Please don't cross-post.

jtwald · Post by **jtwald** » Wed Feb 22, 2006 9:49 pm

Just wanted to know that these samples now work on 2.01, 2.5, and 2.6!

The new GTA eLoader version (brown ale) supports the VSH NIDs.

Fanjita · Post by **Fanjita** » Thu Feb 23, 2006 1:43 am

I'd be very surprised if they actually work though, since the appropriate module is not loaded unless running in VSH mode.

jtwald · Post by **jtwald** » Thu Feb 23, 2006 2:42 pm

Fanjita wrote:I'd be very surprised if they actually work though, since the appropriate module is not loaded unless running in VSH mode.

Hmmm I'll try to decrypt a SOCOM FTB save and see if the results are correct now.

Before I just tested it and it went through without error so I assumed it was working.

I'll get back to you on that.

jtwald · Post by **jtwald** » Thu Feb 23, 2006 2:47 pm

You were right.

They do not work correctly.

They will say that they succesfuly wrote data and execute correctly, but the output when encrypting or decrypting is not correct.

jimparis · Post by **jimparis** » Thu Feb 23, 2006 4:48 pm

That's what would happen if you had the encryption key wrong. Did you change it for SOCOM? The samples are set up for GTA.

jtwald · Post by **jtwald** » Fri Feb 24, 2006 5:28 am

jimparis wrote:That's what would happen if you had the encryption key wrong. Did you change it for SOCOM? The samples are set up for GTA.

Yea I compiled my own eboots to decrypt/encrypt the SOCOM save file, as well as the socom online update file in the SHARED save directory.

They work perfect on my friend's 2.0 Tiff exploit psp, so I know they work correctly. ON my 2.01 using brown ale eLoader the output is incorrect but it runs succesfully.

forums.ps2dev.org

New savedata encryption and decryption samples for 2.0

New savedata encryption and decryption samples for 2.0

Decryption/Encryption on 1.x0 firmware

Re: Decryption/Encryption on 1.x0 firmware

Re: Decryption/Encryption on 1.x0 firmware