Protecting Download Files? (For the End-User)

[Jimothy]

Bit of a strange question really...

Is there a way to protect (IE, unable to replace//edit) a particular file or folder in a downloaded mod? I am working on a multiplayer game mod that has gone down very nicely with the community we server. One of the facets of the mod is the lack of a 'reticule' which was removed via the texture sheet. Unfortunately, the more abled have already replaced the texture sheet (.dds) with one from what is essentially 'Native' (original game) ... Beyond begging on our knees for the developers to assist us, we're a little boned.

Is there any way to protect or encrypt either the folder it belongs in or the actual .dds file itself so that an end-user cannot modify that file?

 

[Pho]

You could always hash (MD5, SHA1 etc) the file against the calculated hash of the file when it was shipped, if they don't match then you know it's been modified.

 

[Jimothy]

Mhm, thank you for the speedy reply Pho!

Would that work in what is essentially a folder that sits inside the original game (Game/Mods/OurMod) on the user's computer? There is no online checking of the files beyond the initial game launch-up where the assets are counted in (objects, textures, collision meshes and the such)

This is the problem we have. It is incredibly simple to place the original texture sheet back into the mod folder. We have no way of countering this beyond what I seek here and // or support from the original game devs. We've considered (and tried) making a breadcrumb trail of textures and meshes, materials and more textures, in an attempt to make it as difficult a process as possible but ultimately those with modding skills will solve it. Hence why I am now wondering if it is possible to simply lock the aforementioned file and prevent over-writes//edits.

 

[Pho]

I'm sure someone will come along who knows more about this sort of thing than me, however perhaps a simple approach would be to create a file called filehashes.txt or file.ext.hash for each file, e.g. crosshair.png.hash or something.

Obviously this allows someone to come along and then change these hashes once they've changed the original file defeating the point, so you could also encrypt these hashes in the file (using say AES). As you load the hashes into your mod decrypt the hash values using your decryption key (which only your game will know) and then proceed to verify that the hashes of the file match up to the hashes specified in the hash file.

That sounds reasonably secure to me .

 

[tntcoder]

The problem is though that even if the hashes are encrypted, you can just patch the hash check out so it always passes. Even if you encrypt the hashes the decryption key will have to be distributed with the game, meaning that ultimately anyone with the skills will be able to change or remove the hash check and sadly there is no way around this (as countless forms of DRM have showed us).

Pho's method of using hash checks is the way to go though and it might catch a few people out along the way and make the process more time consuming.

To make it as hard as possible you should:

- Encrypt the checksum hashes

- Dynamically implement the decryption key for the hashes in the game, for example rather than hard coding it in, hard code a version in that is XOR'ed in with another key (that you hardcode). This will make it harder than just statically pulling the key out the game.

- Pack the executable to make reverse engineering it significantly harder - something like ASPack or Armadillo. This will make it hard for them to simply remove the hash check.


Ultimately though if someone has the time on their hands then im afraid you're screwed, you can only make it more challenging for them.

 

[Pho]

Good points . To be honest I reckon if someone went to all the trouble to add a cross-hair after hacking/decrypting your code then you might have to think about protecting yourself from aimbots too :/.

As someone who likes to poke around in disassembly ever so often, ASPack/Armadillo are annoying .