Im using c++ engine called cocos2d-x which don't have any build in resource encrypting method
Is there any way or ant body already did it . i want to encrypt the resources in the game in efficient way the purpose the resources have copyrights so when you download APK/EXE you won't be able to see them .
Thanks
You can encrypt files as much as you want, but the game will need to decrypt them, and since the users will have the game... the users will be able to decrypt them as well.
I recommend against DES. It offers next to no protection, and it is comparatively slow.
The "next to no protection" bit is not so much an issue because finally you cannot prevent someone from stealing your stuff anyway if the data plus the executable that can decrypt said data is on their harddisk. You can make it somewhat harder, and that's it. But DES is slow in addition to that, and that makes it a bad candidate.
I'm using XOR-encryption on a simple (non-secure) pseudorandom generator. That's about as fast as memcpy, and admittedly not very secure, but it stops the most obvious stupid attempts of unsavy people looking into, or tampering with datafiles (even more so as datafiles are compressed). As stated above, you cannot do this securely anyway, that's wasted time. To anyone not knowing the trade, this is a showstopper, and that's the intent. To anyone with the least bit of experience, it's laughable. Annoying, but pretty much as good as you can get, unless you control the hardware.
XOR-encryption is mighty fine, really. You don't even need a particularly clever, or even "random" random generator. Anything that is not immediately obvious and already implemented in editors with a plugin or script (like ROT13) and that prevents identical input values from having the same identical output values every time will do. Just enough so you cannot see patterns with the naked eye and so you can't select "un-ROT13" from the editor's menu to get something readable.
If you are in super paranoia mode, you could use a simple and fast Feistel cipher like TEA (need not even bother with the improved versions, and even half the number of rounds will do). A few lines of portable code, no huge state, and fast. And... totally sufficient.
The advantage of a block cipher over a stream cipher is that changing one byte always changes the entire output block. That makes byte-tampering with a hex editor even harder since you don't just change one byte but e.g. 16 of them at a time. But the problem of tampering is solved better with a checksum. Of course, with a checksum, you have the same issue again. It's stored on the user's computer, so the total amount of security that you can achieve is... somewhat limited. But you can sure make the life of someone trying to change a wall texture ID to transparent somewhat harder.
The bad news is, computer security is like dying due to being struck by lightning. Unless you are a total idiot, and if you take minimum precautions (such as not going on an open field with a metal rod in your hands during a thunderstorm), getting struck by lightning is an extremely difficult task. It's so rare it doesn't happen once in a lifetime. But when it happens... it literally happens once in a lifetime. Once is enough.
Encryption safely prevents a hundred million unsavy users from accessing something you don't want them to read, and the chance that they find a way are very small. But once is enough. If one dedicated (and skilled) person finds a way, the next day the 99.9 million remaining people will use the same click-to-crack patcher. And unluckily, there's more than just one person out there with spare time to try and nothing better to do, too.
First: If you don't actually HAVE to encrypt the data, the don't worry about it. It's more important to make a fun game, and make sure that lots of people hear about your fun game!
Second: If you are licensing content where the licensing agreement requires that you do some kind of protection, then I second the recommendation for XOR with a pseudo-random stream. That's a perfectly legitimate encryption method, and the "security" of that system ends up being related to the seed (key) for the stream, and the random number generator. But, as already pointed out: Your program needs to draw the bits to the screen. Someone who knows how to use a debugger, can copy the bits out of your program at that point. Thus, there exists no 100% fool-proof DRM/encryption system, and thus, building something that is "good enough" is the best you can do.
Third: If you are really ambitious, you could use a stronger random stream (like a SHA256 hash) and use a per-user seed -- encrypting the payload once per user. When a user starts up their game, have them connect to your server that tracks purchases by user ID (email address? phone number?) and serves the key to them. This lets you track if someone copies their game to too many other computers. If you also watermark the assets, it also lets you track who ended up leaking the data, once the data is leaked onto the internet anyway. But, that's not necessary for any "indie" game. I know some of the really big development houses does something like that with closed alpha/beta versions, to know which testers they can trust, though. (They also watermark screen shots.)
Thanks for the replays , after some looking and reading online , im not sure i really have to encrypt them only to be able to prevent from other to use / see the resources
i read that i need to create somekind of file of my own and use this to store the files
here is the reference :
Right, most attempts at protecting your content are ill-advised. If you're a security/encryption expert with serious time and budget to invest, you can protect your content perhaps long enought to get through the first several weeks of sales -- If you're an AAA developer who sees a huge initial sales volume, this can sometimes be worthwhile. But most small developers don't have the time or budget, and even if they can spare those things it would be better invested in making the game better; likewise, most games from small developers don't have that same initial sales spike -- viral hits tend to reach peak sales weeks after launching, modestly-successful games tend to have a sales trajectory that's quite long with a gentle rise and decline.
Many times, people from small studios make the mistake of believing that they should emulate what the AAA studios do, not realizing that their circumstances are entirely different. What often ends up happening is that they make a significant investment in these kinds of 'protections' burning time and budget, but because they are not expert their solution ends up barely more effective than the simple things you could do in an afternoon. IMO, for small studios, they should mostly stick to very simple methods like XOR, .ZIP files, etc if they deem it necessary to obscure their files at all -- these are not at all 'secure' but will obscure the files from curious users and extremely casual 'attackers'. Take the time you saved to make your game better and to make sure your game's launch makes a big splash (Get your announcements and press kits together, talk to reviewers, all that jazz) -- Either one of those activities will contribute more to your bottom line in the end.
Again, if you want to make the files moderately hard to read for a normal human being who's not a trained reverse engineer, XOR-ing the data by the output of a random number generator is a fine method. That should be easy to do across platforms, too.
This code, as written, should be portable across a very large number of systems and languages, as it assumes nothing more than "ints are at least 16 bits." It also encrypts different data with different rotating keys, such that a simple XOR of two encrypted files won't trivially recover the key.
Is this "safe against all hackers?" No. But it's about as good as you can make it without involving things like kernel-level DRM modules and "trusted computing" hard-cryptography stuff.
