Hướng dẫn hex file save game đơn giản

evandixon, I really do wish I could help you. But unfortunately I do not know how people even figure out checksum algorithms. I was lucky enough that one was documented (and later a more optimized one was discovered by SCV / Sabresite) for DPPt.

I guess if I were to try myself, I would figure out what offsets relate to one aspect of the save (I think you said you found the name of your team somewhere), and see how changing it affects the save file.

Try to change one character of your team name and see what bytes change. The checksum will be in there somewhere. Change the team name back to exactly what it was before, see what changes again. If something that changed before changes back to what it started as (other than the team name bytes obviously), then hey, there's the checksum. Then you can make other changes and try to infer the mathematical pattern.

At least, I guess that's what you would do.

Does anyone know of a sophisticated (or effective) way of plotting out these changes to find a formula? Like a T chart in linear systems of equations?

Go to the Savedata folder and open it in notepad. Find “sceneId” on the value next to it (might be “flashback_” or “scene_”). Anyways change it to “flashback_fantasyisland”. Save it and restart the game.

Note that you can use this to go anywhere in the game. And you need to return it to normal after otherwise the game will be stuck there forever. Change it to “scene1” that’s the easiest.

If it wasn't for videogames, I'd probably never have got into the career path I have, and a lot of that also comes from my other habit of taking stuff apart to see how it works.

Back in the days of the original Playstation, I had one of these Xplorer cheat cartridges.

This allowed the use of game cheats that weren't necessarily part of the actual game code.

In addition, the cartridge allowed the user to create new codes, by essentially searching for values in an existing game.

My understanding of it is that it effectively was a memory scanner, that would find values in the systems RAM, and allowed values to be rewritten (constantly rewriting the memory location of the health variable to read 100% would effectively be an infinite health cheat, for example).

Similar application shave been released for PC games, but to be honest, they went to involve running unchecked code and tend to have an air of shadiness about them.

Plus they tend to just be a very directed tool for a specific game title, so blinding running one might help you out with a game, but you're not getting anything useful from it.

This project is to demonstrate that similar results can be produced using standard tools, which have uses beyond games, so while cheating at the game won't make you any good at the game, you might instead learn something that is useful in the real world.

Tools The tool being used is a Hex Editor (wikipedia). I'm using GHex, but the most commonly known editor is WinHex for windows.

Process

There are several approaches that can be taken, there are some who will painstakingly sit and work out the whole format of the file.

While this is probably the most technically sound approach, it's incredibly time consuming and laborious, particularly if you're only looking to change one or two values.

Another approach is to load a game, make a note of some key values in the game you'd like to amend - ammo, health, cash, etc. The more unique the value, then in theory the easier it will be to find in the file.

For this example we're using Saints Row 3, and in particular we're looking at ammo.

Note that there the process does involve a certain amount of trial and error, so for conciseness I'm not going to cover all of the missteps along the way, just what I did right. Of course it goes without saying making backups of the save before editing is worth doing just in case.

These are the ammo balances of the save I'm using:

The first thing to do is to convert some of these values to hexadecimal so that we know what to look for in the hex editor.

So starting with 265 - this converts to 109 in hex, or in the notation used with most hex editors, this will appear as "01 09", so use the find function in the hex editor to look for all instances of that. There are two likely outcomes, either:

• You'll find multiple instances, so the next step becomes figuring out which one is the one you want to change.
• You'll find nothing. In which case the endian ordering of the file could be an issue - this refers to the order in which the bytes are used to create the actual number. In layman's terms, you can think of it as reading from left-to-right or right-to-left. Simply reverse the order of the bytes above - e.g. "01 09" becomes "09 01" and search for that. If you continue to find nothing, it could well be there's some additional encoding or perhaps simple encryption on the file. There's ways around that but it's a bit of of scope for this project - I might do a follow up post later dealing with those things.

As it happened, with the pistol ammo amount I lucked out, there was only the one instance.:

The bytes representing the pistol ammo highlighted in red (click to enlarge)

So, let's change these two bytes to FF (the largest 2-character hexadecimal value - like 99 is in decimal), reload the game, and see what happens.

The pistol ammo is now 65535 (which is the decimal equivalent of hex value FFFF)

So, where to go from here? We can repeat the above exercise with the other values to find them, but we can help to deduce the whereabouts by adding some logic to what we already know - in this instance, we're looking for ammo values, we've found one, and we can reason that it's quite likely that these values will be grouped together.

For example, the SMG ammo value (70 00) was found nearby

The 2 values (pistol value in blue, SMG value in red). Click to enlarge.

From there we can deduce further - The pistol value starts at byte 19104. The SMG value starts at 19132 - 28 bytes apart.

So what if we look forward another 28 bytes at 19160? We find "30 00" - decimal value 48, the value of shotgun ammo. And again, another 28 bytes later we get hex "77 00" - decimal 119, the rifle ammo.