psp saves to psx

[Gamesoul Master]

psxemulator.proboards54.com/index.cgi?board=support&action=display&thread=1199678745&page=1#1199761441

[Firehawke]

Alright, I promised I'd provide what I could off my PSP. A dead video card has made that a little harder than I'd like-- I can't get to a good chunk of my PS1 conversions right now (I use 3.80 M33 CFW on my PSP) and thus I can only provide what I can get off my PSP right this second.

There's just one problem-- I'm pretty sure MOST of these are empty. I can promise you the second card in every set is empty, I don't usually save to the second card in games. The reason I think most are empty is that I only had time to do basic testing on the PS1 games I'd converted when I was doing the batch conversion.

If there's a Raystorm save in the zip (can't remember..) I'm absolutely positive that has an actual real save in it, as I played the game through to completion on my PSP just a few nights ago. Probably SOTN as well, considering how long I've had that converted.

I'll see what I can do about getting some real saves together when things stabilize-- as it stands, I'm currently fighting Sapphire over my video card warranty.

Hm. As I don't see any way to actually ATTACH the file, I'll just send a URL to my own home webserver via private mail.

[patrickp]

No, this forum doesn't support hosting files, firehawke. Most members use a free hosting service such as HostFile.

[Gamesoul Master]

If a checksum is generated and placed in the header of the .vmp file, it can't be based only on the actual data in the file (meaning any of the data *after* the header), because it seems to generate two different headers for the same *exact* content. The only difference in the files is in the header itself, which contains two 160-bit strings of data, amongst a bunch of zeroes that are constant, and a 32-bit string that is also constant.

The two 160-bit strings are obviously the points of interest. One, I assume, is the checksum. The other seems to be some kind of counter, the nature of which I cannot guess at. In the two identical files, one counted from 00 to 13, and the other counted from 14 to 27. The other string in each one was also different, of course. There has to be a relation between the two, since they are the only two differences in the file (and assuming that one string is a checksum).

Another note of interest about the counter string is that they seem to be in sets. Imagine 00 - FF being broken into sets of 160 bits (00-13, 14-27, etc). At first I thought it was random, but I'm pretty sure that the PSP starts off with 00-13 every time it creates memory card files for a new game. The first card gets 00-13, and the second gets 14-27. Every time the memory card is updated (saved to), the sequence is changed to the next one not currently used (28-3B in this case). 78-8B is the latest string I've found so far, but it may very well go further. The only reason I would suspect otherwise is... if it looped back all the way, it wouldn't go back to 00-13, instead looping to 04-17.

In any case, I don't really think that sequence matters, as long as it's kept as one of the standard sets mentioned above. The whole point is... I know only a little bit more than I did before, except that the checksum must be calculated partly from that sequence, and the checksum is 160-bit.

I don't suppose there's any chance it could be an SHA1 or RIPEMD160 checksum...? I'd imagine they'd probably come up with one of their own, wouldn't they?

[Firehawke]

Considering the laziness of programmers (I *am* one from time to time..), I wouldn't be surprised if they used something off-the-shelf in terms of algorithm. Have you considered getting in touch with some of the bigger names on the PSP scene? Mathieulh or Dark_Alex should be able to provide something a bit more useful in the way of hints.

There ARE a few things I do know that might help a little here. When you do a PS1 to PSP conversion, you need to know the SXXX-XXXXX number. It's heavily tied to how the thing writes savegames (it creates an appropriate directory name) and possibly may be used in some form of pseudo-encryption on the header itself. If I remember correctly, copying a save file from another PS1 conversion will not work, despite the header being the same. It wipes the card and starts clean-- the same thing if the header doesn't match the data in some way, shape, or form.

edit: You know, I just remembered something fairly important here. This is the NEW PS1 save format. There was a change around the 3.10 timeframe (I don't remember the exact revision) that changed the format entirely. I'll see if I can find anything on the old format. There might be a workaround (albeit annoying) just importing the new format and exporting to the old one. The annoying part being the popup that the save will be upgraded to the new format and won't be usable on older-revision PSPs anymore, blah blah.

[Gamesoul Master]

Yeah, of the group of saves given to me, one of them was in the old format still, where the file is saved as a .bin file instead. Upon opening it, the whole thing looks like a ton of gibberish, compared to the relatively clean look of a .vmp or .mcr file.

I had considered possibly asking Dark_Alex, but I sort-of figured that if he knew the answer, wouldn't he have integrated the capability of importing PS1 saves into his firmware? It'd certainly be an extremely easy feature, compared to doing the on-the-fly insertion method available now (through a plugin and the pains that come with such). I may end up asking one of them anyway, just in case they have any ideas on the topic, because I'd feel a lot better if I could convert PS1 saves to PSP saves. I know there are plenty of people out there wanting that.

I figured maybe that a checksum was created against the Game ID characters (which is a 160-bit value, funny enough), or that and the 160-bit counter string, but I couldn't come up with any valid checksums using any combination of those values. Admittedly, trial-and-error is not the best method with this little information, but I'm hoping to suddenly be inspired, come up with the miracle answer, and solve the problem... LOL.

One thing I'd really like to know... Would a programmer be motivated enough to create a function that picks specific pieces within a file to run a checksum again (meaning, basically, multiple ranges of offsets... for instance, pulling the 160-bit string of each slot's Game ID value)? Or would they just pull the whole block containing all those values and calculate a checksum from that?

[Firehawke]

Well, it's pretty reasonable to assume that the save format doesn't use the PSP hardware ID. The saves are transferrable between PSP and PS3 just by hooking up a USB cable. There's no pre-configuration like the Remote Play required to do so.

In this case, we're 50% sure of the input, 100% sure of the output, and have no idea what the transformation process is.

We know it's not a 'save counter', as that wouldn't do anything that would prevent you from directly modifying the save data. It has to be a checksum or CRC type deal. I believe that we could get the answers by decrypting the Pops part of the firmware (easily done, believe it or not-- there're updated tools for that) and either disassemble the routines or go through it step by step. The main reason I think DAX and Mat haven't played with any of this is more lack of interest than impossibility, and I do firmly believe they have SOME insight on the matter. You don't do five or six CFW revisions without picking up on Sony's methodology.

For me, pSX<->PSP save compatibility is one of the remaining holy grails. Although it does remind me of one thing I'd like to suggest. It'll probably get me shot by the mods (for suggesting another ISO format) but I'm going to make the request because it's not quite as dumb as it sounds. I digress, though, I'm offtopic.

I believe this is probably very simple, I just don't have the required knowledge.

[Gamesoul Master]

Meh... don't worry about your image support request. Nobody has yet requested eboot image support to my knowledge, though I suppose I could be forgetting if it was (and I certainly never saw it enough to put it in the Known Requests section, so no big deal).

Well, I know the checksum isn't a save counter. But there *is* that 160-string that is, essentially, a counter. Again, I have no idea why they put it in there, but it is most definitely as simple as it looks... a string of sequential numbers in hex. But that string is not of concern, because if the other 160-bit string (seemingly the checksum) is cracked, that 160-string won't mean anything, as it would be a simple matter of trial-and-error to figure it out if it somehow isn't as simple as it looks (in terms of what decides what sequence set to use, I mean).

Because of how the saves work, and the knowledge that two identical save files can have different checksums, I'd agree that the answer to this must be quite simple... *If* we had the proper knowledge, which I probably lack much more of than you do.

I think I'll go throw in a request to one of them for any possible info on what makes this checksum tick.

[patrickp]

Indeed, Gm, I don't think this has been requested before and, even looked at as a new format support request - it's not simply a request for a new format, it's a request for a new function in pSX.

[ShendoXT]

As Gamesoul Master said sequence could be easily replicated so that's not the problem.

So far I have been able to figure out that actual save data doesn't matter
(I HEX edit my saves when I want to continue playing
PS1 games on the PSP), what matters is the header (game ID, identifier, region, slot number, etc..).

I had an Idea for a while:
I was thinking of creating a PSX program (which will be converted to eboot) where you can save to memory card whatever you want.

I don't have much experience in cracking stuff but if anyone does and volunteer for the job i could try to make such application.

Here is a 10sec paint made mockup of the application:

[Gamesoul Master]

Well... the only problem is it generating two different checksums on identical memory card files (all the header information, except for the number sequence). That being the case, it most certainly also has to include either that sequence of numbers, or possibly the filename (unlikely, but the only other possibility).

Also, the .vmp header itself has none of that information, so are you referring to the "headers" of each slot, in addition to the raw memory card itself?

This program you're talking about... are you basically talking about a homebrew program that will create a PSP natively formatted memory card file (.vmp)? On one hand, it'd be a good start to trying to figure out how the checksum works. The only problem is... since we know the checksum depends on more than just that data, we can't really use it to figure out how it works, unless it's definitely calculated on *only* that data and either the number sequence, the filename, or both. If it's not one of those 3 possibilities, we're left still in the dark on how it works.

Either way, I currently have no way to test-run this program, as I don't have a PSP anymore. I'll have to stick to the PC-side of trying to figure this stuff out (through PS1 memory cards from the PSP). I'm still thinking it's *probably* an SHA1 checksum. I know some people said it may be MD5, but MD5 is only 128-bit, which is too short to be the 160-bit checksum that appears in the header file. Do you (or anybody else) have any thoughts on that?

I tried asking other people on different forums (including PM'ing some knowledgable people on those forums), but I have received no answer as of yet. And I have no contact information on Dark_AleX beyond his username on various forums, but in many cases, his inbox was already full and so I couldn't send him a message. I don't know anything about IRC, so if he frequents any IRC channels that anybody knows of, could someone possibly ask him there?

[ShendoXT]

hoshikuzu said:

Also, the .vmp header itself has none of that information, so are you referring to the "headers" of each slot, in addition to the raw memory card itself?

Yes, that's what I was referring to.

hoshikuzu said:

This program you're talking about... are you basically talking about a homebrew program that will create a PSP natively formatted memory card file (.vmp)?

Yes, It would be a PSX homebrew game.

hoshikuzu said:

I tried asking other people on different forums (including PM'ing some knowledgable people on those forums)...

Well, since CWCheat works I can see why nobody want to mess with that.

[Firehawke]

That homebrew idea won't work, unfortunately. You're missing a fairly large part of the equation, the part that negates the idea completely. In order for this to make sense, I'm going to have to cover the entire PS1->PSP conversion method.

There are two interlocking pieces that create PS1 emulation on the PSP. For the sake of having actual data here, we'll use FF7 (US)'s first disc as an example. That is SCUS-94163.

There is the actual eboot (which seems to be a bootloader stub and an encrypted disc image) firstly. When you're creating the eboot.pbp using Popstation, you are REQUIRED to set the game ID. That's SCUS-94163, in this case, to repeat. This data is used for the virtual memory card system, but NOT for game booting. (We know this because you can set disc 2 and disc 3 of FF7 to the ID of the first disc to have your saves transfer correctly)

Then you have the actual save folder with the two virtual memory card images. What we know for a FACT is that the save folder is based on the disc id (the one you set using popstation). What we are 99% certain of is that the game ID is also used as part of the header checksum. There are reports that simply copying a Virtual Memory Card image to another game's save directory (one with a different disc ID) doesn't work. The checksum fails and the card is reformatted.

The same is also said to occur if you try to overwrite part of the VMC (the MCR portion) with another MCR-formatted file from any source.

As a result, we know for a fact that the checksum DOES check the game ID in some form, and does check the save data in some form.

Since the save ID is *not* part of the Playstation emulation but the actual EMULATOR stub data itself, a PS1 coded application to create random save data under different IDs won't help you. You'll still need to set a disc ID for the disc image when you convert the disc image to run on the PSP, and it's THAT id that gets used for the save data, *NOT* the ID on any data on the save slots on the virtual memory card.

Therefore, that plan of attack is a dead end.

edit: Removed discussion of old format (MEMCARDx.DAT) entirely. While it's still an alternative plan of attack, it seems to be encrypted.

Edit again: I've seen at least one reference to the encryption method being 128-bit AES on the older .DAT format. I'm now beginning to believe that the only way to actually figure this out would be from *inside* the firmware, by reverse engineering decrypted PRX modules.

One last edit, really! Honestly!: keys.bin, the decryption/encryption key for the eboot file, is 16 bytes. 16*8 gives us 128 bits of encryption. Coincidence? I doubt it.. but there's always the chance of some math being done to the key BEFORE the encryption step, so it's not likely the key itself.

In any case, I now firmly believe the only real way we could get any more progress is through people already knowledgeable on PSP internals.. though if GM is really interested in checking out the keyfile and playing with it, all he needs to do is ask.

[Gamesoul Master]

I think I need to take a break from this until a little more information comes out, or I feel up to more research on this topic. As things are, I'm pretty sure all I can do at the moment is more trial and error, and there are just too many possibilities without enough of a direction to go in.

[ShendoXT]

I've read your reply firehawke and i see you misunderstood me.

I don't plan to write random data, i plan to put all zeros in the save part of the mcr.
I would only write desired data to the mcr save header.

The reason for that would be the fact that i HEX edited my Vagrant story save with a new data and
was able to continue my game which I played on ePSXe,
but when i edited any part of the save header memory card was formatted.


Edit: I just tried any was able to use a VMP memory card from another game with a different id.

I used Memory Card from a Monster Rancher and made a save in Final Fantasy VII and when I viewed the card the saves from both games were there, it was not formatted besides being created by the game
with a different ID.


That proves that checksum is not calculated by the Game ID nor the Save ID.


Edit: Well I went out and made the utility I was talking about.

Here are 4 vmp files with mcrs different in only 2 bytes from each other.
Off course checksum is "random" but I'm still posting the files for someone (GM ) to take a look.