Encrypted files?

Started by
6 comments, last by KulSeran 17 years, 10 months ago
How do you make encrypted binary files, and still have your program have access to it and change data etc.? Came accross my mind when I was thinking about security for a game.
Advertisement
If the program can access it without a password prompt, that means that the program contains the key needed to decrypt the file, so you might as well not encrypt it in the first place since you're giving away the key.
How would you make the files secure as in not allowing users looking through files and messing with them? What methods do other people use?
If you develop your own package format (as opposed to just using zlib) you'll probably put off a number of users from looking through your files. People who really want to get at your stuff will still get at it no matter what - but it's protected by your copyright, for what it's worth.

If you are just worried about the user unintentionally breaking their game by modifying it, or using the game files to give themselves an unfair advantage (start with 1,000,000 gp instead of 300 gp) you could compute a hash for each archive (if you use archives) and compare it to a reference value. Set all files to read-only. Provide repair functionality from cd (but just reinstalling should be fine too).

From what I've seen, most games don't bother. Text files sometimes start with a "modify at your own risk" line, most files are just there in the directory structure, neither packed nor encrypted nor whatever. Some use archives, a few use proprietary archive formats.

If your data files are easily available, it could enable the growth of a modding community, which is a good thing for any game imho :)
You can pack all your files into an archive. And you can encrypt the archive.
For just about any hoby project, this will deter 99% of the people who ever look at the project.
For any commercial project you have to deal with the 1% that are dedicated to the cause of modding the project.
They will break anything you put in their way inorder to get at what they want. Make things slightly
dificult, and forget about making a totally secure system.
The only exceptions to this are online games, where the fact that it is online provides a level
of protection to the content, since the content has to sync for the system to work.
Though even this is not totally secure to people wanting to mod the look of the client, or even
find out stats of stuff in the game.
Quote:Original post by lightbringer
If the program can access it without a password prompt, that means that the program contains the key needed to decrypt the file, so you might as well not encrypt it in the first place since you're giving away the key.



As with all encryption its a matter of making it more difficult. Making it outside of the ability of the ordinary person can be enough and making it too tedious to be wortwhile to more advanced people likewise.

Protecting assets... (stealing or modification)

Preventing cheating....

Making it hard to copy/pirate ...

Sorry to sound like I know nothing, but what do you mean by archives and hash?
An archive is something like a .zip, .rar, .pak, .wad. They are all filetypes that people have created for the purpose
of compacting several files into one large file. Sometimes they are compressed (zip, rar, tar), and sometimes they
aren't.

A hash is something that transforms one representation to another, usually from a variable length string to a fixed
length one. MD5 and CRC32 are two common examples used often to check if two files are the same, or if one
file has been changed/corupted since the hash was made.
They both take variable length strings (the file data) and output a fixed length hash number (32-bits for CRC32).
This hash is "unique" to the file that got hashed since it is hard to find another file with the same function
that has the same hash. Though it is posible to have two different files with the same hash, it is not likely.
"Good" hashing usually referes to a hash function that has some "good" property to the distribution of outputs.
In the case of CRC32 and MD5 the "good" part comes from the hash returning a very different hash for small
changes in the input. Though there are other ways to hash something, that is the most common way.

This topic is closed to new replies.

Advertisement