Sign in to follow this  

Using RSA encryption to prevent easy texture modding?

This topic is 392 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello,

 

Earlier this evening, whilst working on my project, I began wondering, is it possible to encrypt textures, so that no one can mod them or put something inappropriate, that may cause problems.

 

Theoretical plan:

 

Tool:

1) Convert textures to byte arrays

2) Encrypt with RSA Private key

3) Store *.bin files

 

In game:

1) Open *.bin files

2) Decrypt with RSA Public key

3) Load byte arrays into memory

 

Idea is that only me, as a developer, can place textures into the game.

 

Of course, i know that its still possible to place custom stuff into the game, but i want it to be a bit more complicated than "replace a png file".

 

Or is it actually a common tactic?

Or maybe RSA is not meant for that...

Share this post


Link to post
Share on other sites

Or is it actually a common tactic?
 

 

The common tactic involves placing most of the resources in as few files possible, which end up being big. Maybe with some compression that is very fast to decompress (ie, l4z family). Why? Load times. Compression is to reduce the time spent on disk reading, bunching up files into a single directly indexed file reduces OS round trips to request open file handles, and you can mmap it for even easier access, letting the OS page in/out as needed.

 

No one encrypts their assets as far as I am aware.

Share this post


Link to post
Share on other sites
Why are you scared of modding?

For indie studios modding is something to be embraced and encouraged not feared and protected against.

Your game won't be some precious flower that every AAA studio will want to rip off and that every gamer will want to adjust the textures of and lie to claim they made it.

The opposite is true and if you make it open and documented how to mod your game you'll get a cult following and your own modding community which will increase the shelf life of your game in ways you can't imagine.

Stop, and rethink your strategy.

Good luck!

Share this post


Link to post
Share on other sites
Perhaps I'm wrong, but I thought public keys were for encryption and private for decryption? And public keys were somewhat trivial to derive from private keys? It seems like this combination of factors, if true, would defeat any security since you would need to give the clients the private key. Edited by Nypyren

Share this post


Link to post
Share on other sites

Perhaps I'm wrong, but I thought public keys were for encryption and private for decryption? And public keys were somewhat trivial to derive from private keys? It seems like this combination of factors, if true, would defeat any security since you would need to give the clients the private key.

Private is for signing and public for verifying.

RSA is used in certificates and general PK cryptography and is too expensive to use for general encryption of a stream of data.

Generally the correct method is to use rsa to sign and encrypt a 2k block of random data or similar and then if the signature passes validation use that 2k block once decrypted as the key for a faster stream cypher such as AES or twofish.

Using RSA alone to encrypt and decrypt large assets would be lunacy as you'd have to wait for ages for the game to read any file...

Share this post


Link to post
Share on other sites

Hello,

 

Earlier this evening, whilst working on my project, I began wondering, is it possible to encrypt textures, so that no one can mod them or put something inappropriate, that may cause problems.

 

Theoretical plan:

 

Tool:

1) Convert textures to byte arrays

2) Encrypt with RSA Private key

3) Store *.bin files

 

In game:

1) Open *.bin files

2) Decrypt with RSA Public key

3) Load byte arrays into memory

 

Idea is that only me, as a developer, can place textures into the game.

 

Of course, i know that its still possible to place custom stuff into the game, but i want it to be a bit more complicated than "replace a png file".

 

Or is it actually a common tactic?

Or maybe RSA is not meant for that...

 

You can always try an MD5 verification every time the image is loaded into memory.

But like everyone had said ahead of time, there is typically no point in preventing someone from modifying a texture. Because if they really wanted to, they could do it.

If you are worried about someone trying to do something like an Xray texture, you'll be happy to hear that under most scenarios that a transparent texture would never grant someone the ability to see through it unless it was Alpha texted in the shader. That is to say that if an object was never intended to be seen through, in most rendering engines, it will not produce anything behind it.

Share this post


Link to post
Share on other sites

You could use a crc check. Even when the images are loaded in memory, you could check it every x seconds.

 

 

 

You can always try an MD5 verification every time the image is loaded into memory.

But like everyone had said ahead of time, there is typically no point in preventing someone from modifying a texture. Because if they really wanted to, they could do it.

If you are worried about someone trying to do something like an Xray texture, you'll be happy to hear that under most scenarios that a transparent texture would never grant someone the ability to see through it unless it was Alpha texted in the shader. That is to say that if an object was never intended to be seen through, in most rendering engines, it will not produce anything behind it.

 

Where exactly do you plan on storing a CRC/MD5/etc hash that a modder can't also simply overwrite?

Share this post


Link to post
Share on other sites

Short answer: Games often do use some level of basic encryption (including digital signing, which seems to be what you're suggesting) to make cheating harder (where modifying content == cheating)... but these schemes can always be overcome by a cheater who is dedicated enough to jump over these hurdles, because they can always just modify your game.

 

As mentioned above, if this is something that you need, I'd start off with a much simpler scheme such as XOR encryption and/or checking file hashes -- it will work against the non-dedicated attackers, and will fail against the dedicated attackers slightly sooner than complex encryption, but is much simpler to implement and has a lower performance impact.

Edited by Hodgman

Share this post


Link to post
Share on other sites

a. You need the private key to decrypt, not the public key.

 

b. Your scheme is as secure as encrypting your assets with a XOR encryption (which is not very secure). It will prevent the average guy interested in tinkering with your assets, but it won't stop any moderately determined hacker.

 

c. There is value in modding. Had the creators made it difficult to mod, there would be no Counter Strike today, nor DOTA (or any MOBA for that case, as the genre was born from mods).

Share this post


Link to post
Share on other sites

Perhaps I'm wrong, but I thought public keys were for encryption and private for decryption? And public keys were somewhat trivial to derive from private keys? It seems like this combination of factors, if true, would defeat any security since you would need to give the clients the private key.

Private is for signing and public for verifying.


That's true. Though since the verification code in this case would be on the client's computer, they can just bypass that (likely as simple as MOV EAX,1; RET;) :) Edited by Nypyren

Share this post


Link to post
Share on other sites

Thanks for the replies! I will look into them :)

 

If I know where this public key is, I can just replace it with my own public key. Voila! My own custom textures!

 

Sure, if you know, chances are, random Joe wont have a clue how to make changes to hardcoded keys.

 

Its not about uber protection, its about simply closing the door.

Edited by Sollum

Share this post


Link to post
Share on other sites

 

You could use a crc check. Even when the images are loaded in memory, you could check it every x seconds.

 

Where exactly do you plan on storing a CRC/MD5/etc hash that a modder can't also simply overwrite?

 

 

Depending on the game, you could xor X images, crc them, crc all those values to Y bytes. Send this value to the server and compare it. If it's an offline game, you could store it in a virtualized area, so it will be harder and most likely not worth it to reverse.

Share this post


Link to post
Share on other sites

Sure, if you know, chances are, random Joe wont have a clue how to make changes to hardcoded keys.

 
Then, as others have said, it's as effective as a simple ROT13 or XOR.

You don't even need to do this.

Use a standard compression format such as zip and change the identification bytes at the start of the file from "PK" to your initials. Make sure your code can recognise this header, and you're sorted.

It doesn't have any extra overhead and it will thwart most newbies.

Hope this helps!

Share this post


Link to post
Share on other sites
No one encrypts their assets as far as I am aware

 

This is not right! The Division encrypts its assets and also signs whole packages in addition for not have mods happen to it.

The simplest and most performing solution you could make is exaclty this. Generate an asset package sheme for your game that has the index table encrypted e.g. via AES block cipher encryption so you need to hide the key for it anywhere or download it from a server maybe. That prevents modders from seeing what files are inside the package. The you may also encrypt some assets like your textures via AES and at the end sign you package with an RSA encrypted SHA hash. This is what I'm doing too in my framework and access times to the package are not that slow as if someone would claim for it.

 

There are lightweight implementations for maximum performance and less memory consumption out there for AES and RSA

Edited by Shaarigan

Share this post


Link to post
Share on other sites

This topic is 392 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this