New savedata encryption and decryption samples for 2.0

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

Moderators: cheriff, TyRaNiD

jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

New savedata encryption and decryption samples for 2.0

Post by jimparis »

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
Posts: 1
Joined: Sun Dec 11, 2005 5:23 pm

Post by Bitmap1 »

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
Posts: 217
Joined: Wed Sep 28, 2005 9:31 am

Post by Fanjita »

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.
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
Fanjita
Posts: 217
Joined: Wed Sep 28, 2005 9:31 am

Post by Fanjita »

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.
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
derFeef
Posts: 1
Joined: Tue Dec 13, 2005 7:08 am

Post by derFeef »

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
Posts: 217
Joined: Wed Sep 28, 2005 9:31 am

Post by Fanjita »

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.
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
imhotep
Posts: 41
Joined: Tue Dec 13, 2005 9:15 pm

Post by imhotep »

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
mrbrown
Site Admin
Posts: 1537
Joined: Sat Jan 17, 2004 11:24 am

Post by mrbrown »

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
Posts: 41
Joined: Tue Dec 13, 2005 9:15 pm

Post by imhotep »

thanks for the answer and the tip, won't do it again :)
Fanjita
Posts: 217
Joined: Wed Sep 28, 2005 9:31 am

Post by Fanjita »

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)
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
Vampire
Posts: 138
Joined: Tue Apr 12, 2005 8:16 am

Post by Vampire »

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
Posts: 24
Joined: Wed Jan 04, 2006 2:57 am

Post by jtwald »

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
Posts: 24
Joined: Wed Jan 04, 2006 2:57 am

Post by jtwald »

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
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

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
Posts: 24
Joined: Wed Jan 04, 2006 2:57 am

Post by jtwald »

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
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

Some info here, but that's getting off topic for here, and won't really help you with socom anyway.
lS[UMD/2kdlSU]
Posts: 8
Joined: Wed Oct 26, 2005 10:08 pm
Location: Shiga, Japan
Contact:

Decryption/Encryption on 1.x0 firmware

Post by lS[UMD/2kdlSU] »

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("AS YOU LIKE...", 0x1000, 1, 1);
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

// (code from Cheatworks PSP source code)
pspSdkInstallNoDeviceCheckPatch();
pspSdkInstallNoPlainModuleCheckPatch();
pspSdkLoadStartModule("ms0:/OUTX/chnnlsv.prx", 1) 

If i don't figure the story out, excuse me for my poor English reading...
lS[UMD/2kdlSU] - now working as 67...
----------------------------------------------
site: jap | eng
jap blog: here
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Re: Decryption/Encryption on 1.x0 firmware

Post by jimparis »

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]
Posts: 8
Joined: Wed Oct 26, 2005 10:08 pm
Location: Shiga, Japan
Contact:

Re: Decryption/Encryption on 1.x0 firmware

Post by lS[UMD/2kdlSU] »

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.
lS[UMD/2kdlSU] - now working as 67...
----------------------------------------------
site: jap | eng
jap blog: here
jtwald
Posts: 24
Joined: Wed Jan 04, 2006 2:57 am

Post by jtwald »

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
Posts: 217
Joined: Wed Sep 28, 2005 9:31 am

Post by Fanjita »

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.
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
ditlew
Posts: 4
Joined: Fri Dec 16, 2005 8:35 pm

Post by ditlew »

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
Posts: 24
Joined: Wed Jan 04, 2006 2:57 am

Post by jtwald »

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
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

Did you read http://forums.ps2dev.org/viewtopic.php?p=34482#34482? Please don't cross-post.
jtwald
Posts: 24
Joined: Wed Jan 04, 2006 2:57 am

Post by jtwald »

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
Posts: 217
Joined: Wed Sep 28, 2005 9:31 am

Post by Fanjita »

I'd be very surprised if they actually work though, since the appropriate module is not loaded unless running in VSH mode.
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
jtwald
Posts: 24
Joined: Wed Jan 04, 2006 2:57 am

Post by jtwald »

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
Posts: 24
Joined: Wed Jan 04, 2006 2:57 am

Post by jtwald »

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
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

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
Posts: 24
Joined: Wed Jan 04, 2006 2:57 am

Post by jtwald »

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