Archived

This topic is now archived and is closed to further replies.

GroZZleR

Hex Editing Save Games And The Like...

Recommended Posts

In class today, a friend of mine went to play a saved Counter-Strike demo, basically a replay of a game he had played. Upon loading it, it immediately crashed. He instantly loaded a hex editor, and changed all instances of +showscores to -showscores, because the displaying of the scores was what would cause it. This got me thinking, and a little bit curious, so I opened up a save game I had of Half-Life. I checked for all instances of the value 6. I then shot a bullet, checked for all instances of the value 5. I continued this process, recording the memory addresses in the save file where the value was being seen. Eventually I found the right memory offset and managed to give myself 6 bullets again. It was pretty neat, and fairly interesting. It''s long been a topic of interest of mine on how save game editors and the such worked, and I learned out today. However, before I go delving into writing a save game editor at full steam, I''ve got many questions =P How exactly would you open the file (through your program) and edit the value? My assumption would be to read the file in as binary, then seek to your desired memory address and alter the value. But what about things like RPGs and such? Where the save game is constantly changing in both size and position (or so I assume, I haven''t done any RPG checks). For example, is it really safe to edit the value at 0000 2541 on every save game and know that you''re raising strength? What if that particular player had a name like ''Bob'' instead of ''Rambo'' and the difference in size changed the memory offsets. So I guess in recap, my questions are: How can you ''read'' the file in (or how do hex editors do it?) and how can you safely alter a value that may not be in the same offset everytime? Cheers

Share this post


Link to post
Share on other sites
Well, basically, you need to figure out the basic format of the file. Not neccessarily what each byte is, but enough to find the value you''re looking for. For example, the format of the file might have a tag like ''SAVE'' as the first 4 characters, then a header size field, then the header, then the number of items, then 7 bytes for each item, then strength. Once you figure that out, you''d process the file getting the info you need and skip over sections until you get to the right field.
For opening, you''d just use regular binary file handling.

Share this post


Link to post
Share on other sites
If you don''t want to rely on absolute offset values for properties of your save file, you could store the offset in the beginning of the file. Then, in your code, when you open the file you can read in the first few bytes and know where the beginning of all the sections of your save file are.

Think of it like a table of contents for your save file.

Share this post


Link to post
Share on other sites