psp saves to psx

[ShendoXT]

I have sucessfuly disassembled pops.prx from the 3.40 firmware (first firmware with vmp format).

So method that firehawke mentioned may get us somwhere.
The only problem is that I'm not much familiar with assembler and i doubt that I alone would be able to figure out this thing.

If anyone is interested to try you can use PrxGUI 2.0 to disassemble prxes.

[Sune]

Try asking for advice on the programming board over at mameworld.

www.mameworld.info/ubbthreads/postlist.php?Cat=&Board=programming

S

[Gamesoul Master]

Well, I can at least upgrade my status to full theory tester. I just got a new PSP yesterday. I'm gonna start testing to see what changes cause the checksum to change, which should hopefully help to isolate what the checksum is based on.

I know nothing of assembler at all, so I won't be any help in that category. But at least I can now do more than use blind trial and error techniques to try and figure things out...


Edit: Alright, so far I've tested changing that first set of numbers (the sequential one). When I changed it to 00-13, it reformatted the card. So if the PSP only reformats the card if it sees the checksum isn't valid for what it's based on, it's safe to assume that the checksum is based partly on that number sequence.

A minor side note is that when it reformatted the card, it left the number sequence as 00-13, despite the first memory card still bearing that value. That's something I've never seen before (every set of memory cards I've ever seen have two different sets for the two memory cards). So I take that to mean it reformatted the card but left the number sequence alone, furthering my idea that the sequence only changes when a save is made. I'm going to test using an "invalid" sequence set (like 03-16, for example) and see if it still leaves it alone.

Edit 2: Alright, so an invalid sequence didn't stick, and actually... setting a new valid one didn't work either. It just keeps going back to 00-13, with the same checksum value. That solves a small mystery.

I can't tell if the checksum is based on any information from other files, because modifying the PARAM.SFO in any way causes the game to not start. Modifying the CONFIG.BIN file seems to do nothing, and changing one of the saves in no way affects the other one (that one is pretty much common sense, but I checked anyway).

With some of those easier ones out of the way, I'd say it's about time to test data within the saves themselves. I suppose I'll start with trying to modify data within the saves themselves, to see if that has any effect. Then I'll continue on with trying to modify data where the other Game ID's should go (the slot headers). I'll also try modifying the main .mcr header within the file to see if that has any effect.

Edit 3: Another tidbit of nearly useless information... when the PSP reformats the memory cards, it doesn't seem to do a full reformat. If you check the files far enough down (where the meat of the saves seem to be), you'll see that there's still information saved for whatever slots had saves in them. I obviously have no idea what the information is, but I only thought to check because I caused the PSP to reformat both cards, bearing the same first number sequence (00-13), and noticed that the checksums were still different. Determined to find what differences were in the files, I scrolled one until I found non-zeroed data, and then I scrolled to that address in the other memory card. I had saved one save to both cards (the only difference being about 5 seconds more game time on the second save), and found the nearly identical data, with only a few minor differences (only a few bytes were different, probably the data for the save time). The first card had a second save though, so I'm not sure if that minorly different data is specifically part of the checksum calculation or not. But whatever data that is, that the PSP isn't properly deleting, is part of the data used in the checksum. Not too helpful, but once again... I intend to post whatever results I find, whether big or small. My next step is to create (nearly) identical saves on both cards (where the only difference should be, once again, the game/save time), and see if that affects the checksum or not.

Edit 4: A slightly more significant report, my results on the above tests. I managed to create the two memory card files bearing the same exact saves, except for the fact that they weren't all saved at the same time (that being real-time *and* in-game time). Doing so, of course, left both cards formatted, but there was data remaining as seen in the last run of testing.

There are only 8 bytes that are different between the two files... 4 bytes of each save. The bytes are either recording the save time or game time. I can't be sure. All I know is that whatever they are, they are used in calculating the checksum, because the checksums are different.

I'm going to stop here for now, and wait for a couple people to read all this and let me know if I'm being any kind of help at all, or if I should use my PSP to look in a different direction. Before I end this for now, I'd like to add, before I forget, that modifying any byte in the .vmp or .mcr headers cause the PSP to reformat the card. I also tried modifying random non-header data, which also caused a reformat. I know modifying random data isn't too useful, but I was basically trying to see if modifying non-header data. I chose a spot that appeared to have no main-type data (like the BIOS slot descriptor, etc). If not for Shendo's admission that he was able to modify certain save data and inject it back in (without causing a reformat), I'd be first in line to assume the checksum is based on *all* the data in the file.

So yeah, enjoy reading all this (which hopefully is at least *somewhat* useful). Like I said, let me know if it's at all useful... and if not, what I should instead be doing to help.

[Firehawke]

Very useful info. Sorry I've not been around much-- still having PC issues (going to be another month, it looks like. Maybe two..) but I do have sporadic access to the internet. What time I have is split across a half-dozen projects, but this one IS still of particular interest to me. I'll eat my words somewhat on my previous post on the topic, but it seems your tests do bear out what I said.

In any case, I did find something interesting to possibly play with sometime in the near future and I'll link it here in case either of you have any interest. I'm HOPING this might shed a little light, but.. I suspect pops uses its own save mechanisms rather than the standardized save calls. If you wish to play with this, you'll need a custom firmware revision.

pspupdates.qj.net/Savegame-Deemer-saves-loads-unencrypted-savedata-for-any-game/pg/49/aid/112482

I'm not giving up on this whole direction, certainly. I'm just out of angles for the most part at this point. Too many brick walls, not enough good data. If only one of us could actually get ahold of Mat or Dax...

[Gamesoul Master]

ShendoXT: The checksum may not be based on the Game ID of the game, but it's certainly based on the Game IDs within the save files themselves. At least we seem to be getting closer to the possibility that the only data the checksum is based on is within the memory card (not including any key that the checksum may be based on).

I'm wondering... how did you make those .vmp files with only 2 bytes different way up there in the main .mcr header? I recognize that the second different byte is the starting location of the first used slot's Game ID (and the value is *always* 42 if there's a game saved on the card, because as far as I know, all Game ID's start with "BA", which is 42 41). And the first different byte is always A0 on an empty memory card (and 51 on a card bearing game saves). So since you managed to change two bytes that never seem to be any value but the two listed, I'm wondering how you manipulated that without causing the memory cards to reformat.

I'm working on extracting my pops.prx so I can disassemble it and take a look at it. Regardless of what little I know, I may be able to stumble upon something, so it's worth a look. I can always hope to somehow get lucky, eh...? XD

Firehawke: I haven't tested that plugin yet, but it seems really interesting. I'll have to test it, simply because I'm strongly curious as to what an *unencrypted* game save looks like. Since the .vmp files aren't encrypted (and are only different due to the .vmp header), I'd imagine it's probably a plain .mcr type of save...? Unfortunately, the program itself sheds no light on the topic, as I'd imagine the developer simply found a way to issue a command to the PSP to write the save a second time, this time without calling the encryption function. Though if he found *that* instruction, maybe he could follow it and post the code that it leads to. Unless I'm not properly thinking this out.

The *good* part is that, with this plugin, we could manipulate small areas of data, load it back into the PSP, and see if, upon being loaded, the checksum changes or not. Too bad the plugin couldn't be interfaced with directly. Otherwise a program could be written that, upon the plugin's activation, takes the memory card file into memory, makes a change to a single byte (the first one), then tells the plugin to initiate a save again using the newly modified file. The program would create a file the same size as the memory card file, but filled with zeros. When the plugin returns the save, the program could check if the encrypted one had a checksum change or not, and mark the corresponding byte in the new file with a >00 value if it did. The program would do this in a loop until the last byte was reached.

Or maybe a memory card could be modified to hold all zeros and sent back through the plugin, to see what the resulting checksum would be. It'd be a simple matter to at least figure out the type of checksum used, having been calculated against all zeros. Then it'd just be a simple matter to test for all amounts of zeros from a safe number of bytes to 128 KB. If that yields no results, we know a key is being used.

I realize half of that probably doesn't make any sense. I'm quite tired right now, so please excuse if that doesn't make sense.

[ShendoXT]

hoshikuzu said:

I'm wondering... how did you make those .vmp files with only 2 bytes different way up there in the main .mcr header? I recognize that the second different byte is the starting location of the first used slot's Game ID (and the value is *always* 42 if there's a game saved on the card, because as far as I know, all Game ID's start with "BA", which is 42 41). And the first different byte is always A0 on an empty memory card (and 51 on a card bearing game saves). So since you managed to change two bytes that never seem to be any value but the two listed, I'm wondering how you manipulated that without causing the memory cards to reformat.

From the "inside". I made a PSX program that will save to a memory card.
I only changed the save region, the usual ones are:
BA - America, BE - Europe, BI - Japan.

[Gamesoul Master]

Wait... I think I finally get what you mean, because I never quite understood what you meant by the type of program it was. You wrote a PS1 homebrew program to run *within* POPS? Oh my. Now that I fully understand what the program is... would you possibly be willing to share this program with me? I'd be *very* interested in it. What language is the program written in? I don't suppose you wrote it in C++...?

So then... that first byte that got changed was an accident? Makes me wonder how it's related. Every card I checked, regardless of the region, always had 51 at that address if there was at least one save on the card. And as I said... no saves left it bearing a value of A0, regardless of if the card ever had a save or not. So I'm rather intrigued that the value was changed to something it normally wouldn't be. I wonder if the value is based on the first byte of the Game ID...

[ShendoXT]

hoshikuzu said:

Wait... I think I finally get what you mean, because I never quite understood what you meant by the type of program it was. You wrote a PS1 homebrew program to run *within* POPS? Oh my. Now that I fully understand what the program is... would you possibly be willing to share this program with me? I'd be *very* interested in it. What language is the program written in? I don't suppose you wrote it in C++...?

It was written in C++, yes.

Unfortunately I lost the source due to a reformat but if you are interested I can program it again.

[Gamesoul Master]

I would indeed be interested. If you find the time to rewrite the program, I'd very much appreciate it.

[ShendoXT]

It's done. PM your contact info so i can send you the files.

Here is the preview:

[Gamesoul Master]

I'm reviving this thread to continue the research. I had considered creating a new thread, but all the info is already here anyway, so I might as well just continue where we left off.

Well, a rather logical (and simple) test was to create two memory cards with this program using the same exact information. Basically, I created one with all zeroes, then deleted the folder and did it again. Both files are completely identical, including the checksums. So it seems at least that no random bytes are created when the PSP creates the memory cards (well, basically it means *nothing* is left up to being random, which is always good, as it means whatever we're dealing with is at least predictable).

Edit: However, doing an overwrite save with the same exact data (all zeroes) turned out to give it a few different bytes. And actually, now that I'm looking at the data, I'm seeing that the scattered different bytes are actually a counter of sorts. They use predictable values that change in a distinct pattern. While that's very interesting to me, it's probably old news to you guys, and I know it's not all too important to cracking this damn thing either... :/ I'm gonna keep trying different things to see if I can find any more patterns that may be a bit more relevant to figuring this out.

BTW... That first sequence of numbers I've talked about a few times... it obviously isn't random, but it doesn't always start out at 00-13 initially. The identical cards made from scratch both used 28-3B, and then upon a second save of the same data on the card caused it to be 00-13. Useless tidbit, but I'm going to be keeping an eye on that anyway.

[ShendoXT]

I gave up on this subject a while ago when I discovered a loading method with popstation but it would be a nice thing to finally crack the checksum.

Since I have a free time I will start the research again, maybe I learn something new.

I think that a very hard part about all this is to actually discover what bytes are included in process of calculating the checksum as there are 131072 bytes...

Anyway, I suggest that you instead of using the program I gave you you try the other method,
that way you can load any card you changed with hex editor.

[Gamesoul Master]

I'll try that soon enough, though I'm still getting the occasional interesting result this way.

I've noticed that nothing relating to the game at all is used when creating the memory card files, since a clean memory card created by one game and another created by another game are completely identical. So the checksum is 99% self-contained (the only possible outside factor is some kind of key). And identical cards created on two different PSP's will still yield completely identical cards, so if there's any kind of key being used, it's a constant.

Edit: Taking into account that they might've been lazy about it, wouldn't it make sense that they might've used the whole file? Or at least some whole chunk that doesn't involve any jumping around. That would require so many less variables and functions to complete, as it could mostly all be done in a single loop then. If nothing else, I'm assuming that they went to the end of the file (easier/smarter than using specific values for something like this).

The part that bugs me is that it obviously includes that first sequence of numbers that comes *before* the checksum. Not that it has to be linear, but why would they put a checksum in the middle of what it's based on, instead of at the beginning or end?

Edit 2: As a note, we don't really need to know exactly what bytes are being used in the calculation if the checksum is completely self-contained. We only need to know how many bytes it calculates off of.