News:

11 March 2016 - Forum Rules

Main Menu

Correspondence between ZST and SRM?

Started by Mooch, February 17, 2015, 05:08:58 PM

Previous topic - Next topic

Mooch

Hey everyone, I'm new to hacking, I've been reading through the introductory material (and it suuuuucks -- no offense, but it's all YEARS outdated and very poorly written; it's no help at all) and had a quick question regarding SNES hacking.

What's the correspondence between save states and saveram? Are the addresses the same? If I discover an address in a save state for, say, a character's name (presuming it's immutable and not player-changable), could I crack open the saveram, go to the same address, and alter that character's name? Or is a save state (I use ZSNES as is the standard) a subset of the saveram? Or is there no general, reliable relationship between the two at all?

Thanks ^_^

Seihen

First and foremost, you're talking about SNES hacking here, I presume, which kinda throws into question how "out of date" the information is. The system was made in the early 90s, so no matter how old the information gets, there's no way it will be "out of date."  Though I will agree that some of the programs referenced aren't the newest, latest, and greatest (and the websites mentioned may no longer exist). The information itself, however, is still as useful now as it was then.

NOW! Onto your question...
SRAM is essentially the 'save file' that the game generates and contains only the information needed for a save. In the case of an RPG, it would include HP and MP (current and max), level, equipment, spells, and names, etc. for all members in your party. It'd have how much money you hold, what and how many items, and all that stuff. Basically, whenever you load up an RPG and select your file, all the information that you had saved is contained in the SRM file.

Now, a savestate contains a dump of the SYSTEM ram, or what information is currently held in the memory of the system itself, and not the game. This is basically a snapshot in time for everything that is happening right at the moment that you created the savestate. So, basically, though they may contain similar information (current gold, for example), there is really no direct connection between the two. You can prove this to yourself by thinking about the fact that games without SRAM (Megaman X, for example) can also have savestates made.

As for your example of changing a non-player-changable character's name... you couldn't do that with either SRM or ZST hacking. That data is simply not contained in either file. The SRAM has no need to save constants (things that don't change), so it isn't located there, and the savestate will contain the images of the text being printed to the screen, but it doesn't contain the master list of character names. What you'll want to do is actually hack the rom data itself.

Jorpho

I would just like to add that sometimes (but not always) save ram contains checksums generated by the game itself (and not necessarily in any standard fashion).  In such cases even if you can find where some value like your current HP in the save ram, you won't be able to change it there without deciphering the checksum algorithm, calculating a new checksum, and inserting the new checksum. 

Generally no such protection exists in a savestate.
This signature is an illusion and is a trap devisut by Satan. Go ahead dauntlessly! Make rapid progres!

henke37

I wouldn't say that names never end up in ram. But yeah, you want to go for the actual source of the data.

puzzledude

#4
QuoteWhat's the correspondence between save states and saveram? Are the addresses the same? If I discover an address in a save state for, say, a character's name (presuming it's immutable and not player-changable), could I crack open the saveram, go to the same address, and alter that character's name? Or is a save state (I use ZSNES as is the standard) a subset of the saveram? Or is there no general, reliable relationship between the two at all?
Long story short: there is no correspondence. ZST is a savestate of the ZSNES emulator and is completely specific and emulator based. The savestate of other emus, such as Snes9x, have again their specific savestate file, in this case with the .000 extension. SRM however is save ram made by original game and is compatible with all emus and real hardware.

The difference between the two is great and there is no connection whatsoever. If you want to edit the save of the game, it is best to analyze the SRM itself. But again even if you would "hack" it, like Math On Napkins did with the Alttp SRM, the changes are not that easy.

SRM usually has an internal checksum validation, so if you edit anything (giving yourself better equipment) you need to manually change the checksum for the file to be valid. This however is somewhat difficult. In Alttp it is even/odd byte dependent. If the address to be changed is even, and gets a +1, then the even byte of the 2byte checksum needs -1. If the changes are bigger it is sometimes impossible to see, how to change the checksum without somesort of a calculator, specially because of the "looping", since 00 byte -1 is then FF.

Bregalad

I'd also add that normally the content of the SRAM (SRM) should also be included somehow in all emus save states (sometimes, as in SNES9x' case, in compressed form).

Jorpho

Quote from: puzzledude on February 18, 2015, 06:30:34 AMZST is a savestate of the ZSNES emulator and is completely specific and emulator based. The savestate of other emus, such as Snes9x, have again their specific savestate file, in this case with the .000 extension.
I read once long, long ago (on Zophar.net, to be precise) that they are in fact interchangeable as long as you rename the files correctly, but that might have changed somewhere along the way.
This signature is an illusion and is a trap devisut by Satan. Go ahead dauntlessly! Make rapid progres!

Mooch

Quote from: Seihen on February 17, 2015, 06:49:02 PMSRAM is essentially the 'save file' that the game generates and contains only the information needed for a save. In the case of an RPG, it would include HP and MP (current and max), level, equipment, spells, and names, etc. for all members in your party. It'd have how much money you hold, what and how many items, and all that stuff. Basically, whenever you load up an RPG and select your file, all the information that you had saved is contained in the SRM file.

Now, a savestate contains a dump of the SYSTEM ram, or what information is currently held in the memory of the system itself, and not the game. This is basically a snapshot in time for everything that is happening right at the moment that you created the savestate. So, basically, though they may contain similar information (current gold, for example), there is really no direct connection between the two. You can prove this to yourself by thinking about the fact that games without SRAM (Megaman X, for example) can also have savestates made.

As for your example of changing a non-player-changable character's name... you couldn't do that with either SRM or ZST hacking. That data is simply not contained in either file. The SRAM has no need to save constants (things that don't change), so it isn't located there, and the savestate will contain the images of the text being printed to the screen, but it doesn't contain the master list of character names. What you'll want to do is actually hack the rom data itself.

*smacks head*

Whoops! I meant "difference between save state and ROM," not saveram! Yeah, I was talking about hacking the constants in the rom.

But you answered my question anyway, heh, so thanks. Man, I gotta double-check my wording before I post >_>

Quote from: Jorpho on February 18, 2015, 01:32:50 AM
I would just like to add that sometimes (but not always) save ram contains checksums generated by the game itself (and not necessarily in any standard fashion).  In such cases even if you can find where some value like your current HP in the save ram, you won't be able to change it there without deciphering the checksum algorithm, calculating a new checksum, and inserting the new checksum. 

Generally no such protection exists in a savestate.

Oh! Didn't know that. Good to know.

Quote from: puzzledude on February 18, 2015, 06:30:34 AM
Long story short: there is no correspondence. ZST is a savestate of the ZSNES emulator and is completely specific and emulator based. The savestate of other emus, such as Snes9x, have again their specific savestate file, in this case with the .000 extension. SRM however is save ram made by original game and is compatible with all emus and real hardware.

The difference between the two is great and there is no connection whatsoever. If you want to edit the save of the game, it is best to analyze the SRM itself. But again even if you would "hack" it, like Math On Napkins did with the Alttp SRM, the changes are not that easy.

SRM usually has an internal checksum validation, so if you edit anything (giving yourself better equipment) you need to manually change the checksum for the file to be valid. This however is somewhat difficult. In Alttp it is even/odd byte dependent. If the address to be changed is even, and gets a +1, then the even byte of the 2byte checksum needs -1. If the changes are bigger it is sometimes impossible to see, how to change the checksum without somesort of a calculator, specially because of the "looping", since 00 byte -1 is then FF.

It's strange that they put checksum verification into save files on the SNES, considering back in the day, no method existed for hacking. I guess maybe they didn't put it in to prevent hacking, but to make sure if the cartridge itself somehow messed up and produced a wonky save file, it would be identified as corrupted and refuse to load it.

Quote from: Bregalad on February 18, 2015, 08:54:24 AM
I'd also add that normally the content of the SRAM (SRM) should also be included somehow in all emus save states (sometimes, as in SNES9x' case, in compressed form).

Ugh, I learned that the hard way when me and my brother were both playing Chrono Trigger some many years ago. We were both using save states and normal save files, and the save files kept getting overwritten by our use of save states.

Quote from: Jorpho on February 19, 2015, 12:17:18 AM
I read once long, long ago (on Zophar.net, to be precise) that they are in fact interchangeable as long as you rename the files correctly, but that might have changed somewhere along the way.

Well, I tried to save state hack Breath of Fire II last week using a Snes9x save state and it was utterly different than what I was expecting from the guide I was using, which assumed ZSNES save states. It's ultimately the same data, so I'm sure there's some way to convert, but I suspect it's pretty complex. Not least of all because Snes9x compresses its states and ZSNES doesn't.

henke37

Save states don't have to contain the same data. They depend a lot on the exact internal emulator design. Various timing details are sure to differ greatly.

Bregalad

Quote from: henke37 on February 20, 2015, 05:00:47 AM
Save states don't have to contain the same data. They depend a lot on the exact internal emulator design. Various timing details are sure to differ greatly.
A game could rely on the state of SRAM to run, and behave wrong or strangely if the save RAM is modified unexpectedly (this is what happens if you would load a save state without SRAM information and load SRAM with another unrelated .srm file).

In SNES case the system have more SRAM than the cartridge, so games are unlikely to use SRAM for any other use than saving, *however*, in the NES it's the exact opposite, games are unlikely to use SRAM solely for saving as it is typically larger than system's RAM.

QuoteUgh, I learned that the hard way when me and my brother were both playing Chrono Trigger some many years ago. We were both using save states and normal save files, and the save files kept getting overwritten by our use of save states.
Same here. Although used cleverly, you can have much more saves using less files, you can use up to 10 save states which themselves contains 3 saves (in the case of CT) so you can have 30 saves at a time without dealing with copy/pasting/backuping either SRAM or save state files manually, which can in turn be very practical, for example to access any point of the story quickly.

Unforutnately save states are not always portable between different versions of the same emulator.