I have an idea for an addon for World of Warcraft which would basically be a minigame within the game itself. Eventually, I'd like to have players be able to compete against each other directly. The game would have some RPG-like elements, particularly statistics and abilities, which it would be undesirable for the end users to modify.

So the fact that this is a client-side script, where everything (logic and data storage) are all in flat text files, means that it's impossible for me to truly secure things. But I'd like to at least make it non-trivial to alter things, e.g. so that you can't just open up a file in notepad and type in 'Strength = 256'.

I'm looking for any ideas on how I might obfuscate the data, preferably something which is easy to implement as it's not really what I feel like spending my time on, but probably more sophisticated than ROT-13.

As an example, one idea I had, which I'm not sure if it's feasible (have never made an addon for WoW before) is to serialize the data in base-64.


Your first idea is good: Just put all your settings into a structure, and store is as a binary. Another thing you might want to try is to concatenate all integers and add something inbetween to checksum (i.e. NVVVCC, N is number of bytes that follow, V is the value, C is the checksum.) Use some weird checksumming (xor of all values emitted so far for instance), so people have to pull out a calculator to change the values, after finding them in the super-long digit string. That's usually enough to prevent someone from using notepad to open your file and changing something, but easy enough so your implementation stays simple. And you can inspect the values visually, which might be helpful.

As you said, the goal is to keep people away from randomly tampering with the data, and adding stuff which is easy to do automatic but cumbersome to do manually usually helps there.

  • \$\begingroup\$ I like the idea of incorporating a checksum! \$\endgroup\$ – Asmor Nov 17 '10 at 22:43

Sorry, no matter what kind of encryption on the client side you do, if you store sensitive stuff on the client, it will be hacked.

The client has to be able to read the data in the "encrypted" file. So you are giving the lock and the key to the client in a competitive game, and telling them not to edit anything inside your encrypted file.

Your client will be hacked no matter what. The only thing that the encryption will do is slightly increase the time to be hacked.

Always assume the client is compromised. If you can't work around that assumption, then you are So-Out-of-Luck.

  • 2
    \$\begingroup\$ The key words "obscure", "non-trivial", "means that it's impossible for me to truly secure things" make me think he knows this already. He was asking about making it more difficult for the opportunistic cracker, not making it 100% secure. \$\endgroup\$ – jpaver Nov 17 '10 at 0:51
  • 1
    \$\begingroup\$ As jpaver says, I'm aware it's not possible. I'm not even trying to make it difficult, really, just not simple. \$\endgroup\$ – Asmor Nov 17 '10 at 3:15
  • \$\begingroup\$ All it takes is one person to crack it and release the hack for even the best encryption to be cracked for all. The only thing good encryption will do is slightly increase the time for being hacked. \$\endgroup\$ – AttackingHobo Nov 17 '10 at 4:42

I don't have specific experience with WoW addons, but if it were me I'd serialize the script to binary, then for each successive byte XOR it by the next element of a linear congruential random number generator. The generator could be seeded by the CRC of some pre-known locations in your script file. If you need to convert back to ascii, you can remap bits[0..3] of each byte to 'A'..'P' character and bits [4..7] to 'K'..'Z'. NOTE: the pre-known locations would have some other invertible transform applied, and obviously they should not be XOR encrypted (otherwise you can't reconstruct your CRC for decryption).

Not the best or most unique algorithm in the world, but would serve against opportunistic reverse engineering.

  • \$\begingroup\$ I don't know why, but XOR is never in my 'toolbox' of things I tend to think of. I've really got to change that. Strange that something so simple can be so useful. \$\endgroup\$ – Asmor Nov 17 '10 at 3:16

An idea I had which is interesting, though way more involved than I'd care to implement, is to use the 'integrity of the crowds'. That is, working under the assumption that most people wouldn't both trying to change things, have each client broadcast all their progress, and when a client logs in it attempts to sync with other clients.

Obviously just the skeleton of an idea with a whole lot of complicated details that would need to be ironed out, which is why I said it's more involved than I'd care to implement. :)

  • \$\begingroup\$ Not going to work, if its all client side, one could just level up once, capture the packets from other clients that confirm a valid move, and then just replay those packets when needed for whatever hack is attempted. \$\endgroup\$ – AttackingHobo Nov 18 '10 at 21:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.