Jump to content

  • Log In with Google      Sign In   
  • Create Account


Binary File Writing (Making It Unreadable) C++


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
13 replies to this topic

#1 ajm113   Members   -  Reputation: 257

Like
0Likes
Like

Posted 05 December 2009 - 09:34 AM

Hello, I would like to create my own file format that you can't just open it up in a text file to read it's contents clearly. Basically what I want to know is how can I make my own secure file format that only my program can open and read and understand? I was thinking of using the Hashing technique, but is there any alternatives that are effective? Thank you, Andrew. VS2008 C++

Sponsor:

#2 Erik Rufelt   Crossbones+   -  Reputation: 3030

Like
0Likes
Like

Posted 05 December 2009 - 11:11 AM

You can't make a secure file-format. You could make it a bit harder to read by saving binary data instead of text-data. For example if you want to save the number 100, don't save the text '1' + '0' + '0', but rather the byte 0x64 (which in ASCII text will be the letter 'd').

#3 demonkoryu   Members   -  Reputation: 976

Like
0Likes
Like

Posted 05 December 2009 - 11:15 AM

Just encrypt your files.

#4 ApochPiQ   Moderators   -  Reputation: 14247

Like
0Likes
Like

Posted 05 December 2009 - 11:27 AM

If your program can read and understand it, anyone else's program can read and understand it. The best you can do is make it a little bit annoying to write that other program, but even then, good reverse engineers will still be able to rip apart your format pretty quickly.

Short answer: it's not worth the effort.

#5 theOcelot   Members   -  Reputation: 498

Like
0Likes
Like

Posted 05 December 2009 - 12:11 PM

Quote:
Original post by ApochPiQShort answer: it's not worth the effort.


That's not entirely true. It will stop a lot of people who aren't really determined. But anyway, I think Konfusius has the right idea.

#6 swiftcoder   Senior Moderators   -  Reputation: 9583

Like
0Likes
Like

Posted 05 December 2009 - 12:34 PM

Quote:
Original post by theOcelot
Quote:
Original post by ApochPiQShort answer: it's not worth the effort.
That's not entirely true. It will stop a lot of people who aren't really determined.
Right up until one of the 'determined' people posts a tool to decrypt your file on the internet - probably about 5 minutes after they write it for themselves.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#7 cache_hit   Members   -  Reputation: 614

Like
0Likes
Like

Posted 05 December 2009 - 12:40 PM

Encrypting your files of course only works if the encryption key isn't known to the program. If it is known to the program, then a hacker can disassemble your program, find the key, and decrypt your program.

If you want nobody else to be able to see the file, then it must be encrypted using a key that a) is not embedded anywhere in the program, yet b) is accessible to the program. Whenever the the program needs to decrypt the contents, it would need to request the key every single time. Of course, it would have to request the key in such a way that a hacker couldn't see the response. So that's not going to work, because if the key ends up anywhere on the client's machine, even for a second, the hacker could intercept it.

You could send the data to a server, so that the server could decrypt it and send it back, but then what's to stop a hacker from sending the same file to the server, and getting it back also? You could use a public/private key method but that wouldn't work either because the client program would have to know its own private key, hence embedding it somewhere in the program and suffering from the original problem.

Ultimately, it doesn't even matter, because no matter what you do at some point you're going to have to process unencrypted data. At that moment, right after your program were to decrypt it using super secure means unbeknownst to mankind, and is ready to deal with the decrypted data, a hacker could attach a debugger right then and see the unencrypted data. Or better yet, it could just copy the decryption code to his own program and be able to decrypt arbitrary files since it would be the same code.


Just manually serialize the binary format of your data structures and you'll be fine.

#8 Atrix256   Members   -  Reputation: 510

Like
0Likes
Like

Posted 05 December 2009 - 12:47 PM

To the OP: like the people above have said, you cant make a file unreadable by others but you can make it more difficult for them to read.

Encrypting your files is one way to make them more difficult to read.

You can look up encryption algorithms out there if you want to, or you can make up your own.

Here's 2 basic building blocks of simple encryption...

#1 - adding a number to your bytes on save and subtracting that number on load.

For instance, when you write out your game data you could add 42 to every byte you write to the file. That would effectively scramble the data so it would look like garbage. When you load your game data, you subtract 42 from every byte read from the file to get your REAL data back.

more advanced: instead of adding / subtracting a single number, you could have a "password" such as "thispassword" where you would add that to every byte in your data. ie the first byte would get a 't' added to it, the second would get an 'h' added to it, the third would get an 'i' added to it etc. when you run out of letters in your password, start over at the beginning again. continue til you've treated every byte in your file.

#2 - using xor to encrypt / decrypt each byte in your file.

for instance, instead of adding 42 to every byte in your file on save, and subtracting 42 on load.... whenever you save or load just xor against 42.

if A is your origional data, B is your password, and C is what you store in the file:
A xor B = C <---encrypt your data as C
C xor B = A <---read C from the file and unencrypt it to get A, your data, back.

more advanced: same thing, instead of just using 1 constant, you could use a password.

EVEN more advanced: combine xor and addition / subtraction. Also you could add into the mix bit rotation.

You use the ^ operator in C++ to do a bitwise XOR

These are simple techniques, but they are the foundation of encryption algorithms (:

hope this helps!

EDIT: btw where you said you were thinking of using "the hashing technique" im not sure what you mean by THE hashing technique, but hashes aren't going to help you get the protection you want. Hashes are "1 way", that means you could hash your data when you save it to disk, but you can't unhash data once it's hashed so you wouldn't be able to get your data back.

Not to confuse you further, but you probably DO want to put a hash of your file data at the beginning or end of your file so that you can compare the hash vs whats there to make sure it matches. Sometimes when people cant read a file and edit it, they will make random changes to see what happens. That can totally break your game and cause crashes since you wouldn't be expecting crazy values. Anyhow, the hash of your file data will let you see if anyone has blindly tampered with your file or not, and if they have, you know not to load the data.

#9 ajm113   Members   -  Reputation: 257

Like
0Likes
Like

Posted 06 December 2009 - 04:13 AM

Thanks, Erik Rufelt, cache_hit and Atrix256! You guys gave me good ideas on encrypting my files! I'm making a Embedded Language compiler and I want to compile my code that the user creates into a new file that's "more secure" that my main application can read and understand.

@Atrix256
In PHP there is a function called md5 which is refereed to md5 hashing and it's used for passwords or strings of data that need to be secure. So that's where I got my idea from.

Thanks for your help on that Atrix256! I greatly appreciate it! I was thinking this question wouldn't be a answered with such information from you guys.

Anyways I'll soon start messing around with techniques and try putting them together and see what I come up with. Thank you very much everyone! :D

#10 frob   Moderators   -  Reputation: 18827

Like
0Likes
Like

Posted 06 December 2009 - 06:27 AM

If somebody wants them they will get them. There are laws in place to protect you when attackers steal your stuff and cause direct harm.

In my experience, just dumping them in the format you will use in game is enough.

Your tools can load the data and dump it out in the same arrays, trees, or other structures you use in game. Then you simply stream the data in and set your pointers within it. Load times are faster and there is no time spent processing the data. Plus most people won't bother trying to get it back out. The downside is that it takes a bit more space, but storage is cheap these days.



#11 theOcelot   Members   -  Reputation: 498

Like
0Likes
Like

Posted 06 December 2009 - 09:47 AM

Quote:
Original post by swiftcoder
Quote:
Original post by theOcelot
Quote:
Original post by ApochPiQShort answer: it's not worth the effort.
That's not entirely true. It will stop a lot of people who aren't really determined.
Right up until one of the 'determined' people posts a tool to decrypt your file on the internet - probably about 5 minutes after they write it for themselves.


True.


#12 Atrix256   Members   -  Reputation: 510

Like
0Likes
Like

Posted 06 December 2009 - 09:52 AM

Quote:
Original post by frob
If somebody wants them they will get them. There are laws in place to protect you when attackers steal your stuff and cause direct harm.

In my experience, just dumping them in the format you will use in game is enough.

Your tools can load the data and dump it out in the same arrays, trees, or other structures you use in game. Then you simply stream the data in and set your pointers within it. Load times are faster and there is no time spent processing the data. Plus most people won't bother trying to get it back out. The downside is that it takes a bit more space, but storage is cheap these days.


Frob you bring up a good point about the laws.

There are laws in place that make encryption breaking illegal.

If you write your game data files out in the format you use them, im not sure if the courts would consider that encryption or not so you may not be protected (??).

If you do even simple encryption though (add a constant to every byte of the data), that encryption - as weak as it is - should give your data legal protection :P

(although i think that reverse engineering file formats may also be illegal??)

#13 jmau0438   Members   -  Reputation: 134

Like
0Likes
Like

Posted 06 December 2009 - 09:57 AM

Encryption is its own bag man. Even professionally made encryption such as SSL has been cracked. I applaud your effort, if you pull it off your sure to learn some new tricks, just remember everything electronical is bound to the analog hole. If someone really wants to hack into you files, they'll find a way.

#14 swiftcoder   Senior Moderators   -  Reputation: 9583

Like
0Likes
Like

Posted 10 December 2009 - 01:27 AM

Quote:
Original post by jmau0438
Even professionally made encryption such as SSL has been cracked.
Cracking file encryption when you have access to the decryption software (i.e. the game) is 100x easier than cracking a public key transport system, where you have access to neither key involved.

No one will be trying to brute force the encryption. They will crack open your game in a debugger, and either pull out the decryption algorithm to use separately, or let the game do the decryption and then dump out from memory.

I think the best idea is to just use a plain file unless you have license restrictions (i.e. commercial assets with a protection clause), and then take the minimum effort to meet the requirements. And if you do use encryption for your own assets, provide an unencrypted path - many games live and die on the modding community, s not much point locking them out from creating their own assets.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS