n00b data encryption for save files, pt. one

Following the excellent suggestion of a TIGSource user, I decided to add a save slot to Netpack’s final version. This single-use slot auto-saves on any non-death exit. It’s destroyed when it’s loaded or when a new game is started. I’m sure there are plenty of options for me in terms of libraries so I wouldn’t have to code the encryption myself, but I figured, “Oh well, what the hell,” and decided to do it anyway, for fun.

The data that need to be written and read for a Netpack save game are bare-bones (player stats, game mode, and dungeon level, basically), making a complex system unnecessary. This was further motivation to do it on my own as an exercise, as well as further evidence that I didn’t need a huge, professional encryption module to accomplish my goal.

I don’t care if anyone messes with their save files to achieve fake high scores or to see the ending or whatever. That’s not the point. I did this for the “hack” of it, so go nuts. Once you read these articles, you’ll be able to cheat Nethack pretty easily.

Note to gamers/fans: I’ll be releasing this version of Netpack in about a week, along with the second part of the article.
Note to experienced programmers: My ideas and code will likely be laughable and redundant. Move along.

My first idea was to write a function that constructs an obscure data string representing the game data. I started by figuring out all the game data I’d need for saving and loading: inventory items, player level, dungeon level, score, game mode, and ghosts killed.

Usually, I work in a test file when I’m trying out a new idea, simulating the relevant parts of the game environment so I don’t have to open the actual game 50 times during testing. (Is this a common? It seems natural to me.) Two runs using my test file follow, one asking for input and creating a data string and one loading and unpacking the string (I hadn’t added the number of ghosts killed yet):

At this point, I started implementing in-game. After incorporating the number of ghosts killed, a sample data string would look something like this: ‘2000071220040a0e09Re03532022a’.

Data string sketch

For a final obfuscation, I decided to generate 19 other similar yet totally random and inconsequential data strings and hide the real one somewhere in the block. It would be positioned between the third and last lines, the line chosen at random on creation. The third line of the block would always contain the key – a hex telling how many lines past the third the real line is. So the load function would read the block, look at [2][4] to find the key, and skip that many lines to find and deconstruct the real data string.

Of course, the real line sticks out like a sore thumb even without the key since I generated this block by quitting at the beginning of the game with no items or score. I planned to improve the algorithm to generate more realistic fake lines, thus camouflaging the real one a bit better, but then I stumbled upon a much simpler and more effective idea, which I’ll cover in my next post!

Leave a Reply