• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
ajm113

Binary File Writing (Making It Unreadable) C++

13 posts in this topic

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++
0

Share this post


Link to post
Share on other sites
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').
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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??)
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites

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  
Followers 0