I'm making a scored game, and want to save the high scores. I want to save the scores in a file that the program can access (of course), but the scores shouldn't be editable by the user (a read-only file, probably). The problem with a read-only file is that, obviously, it's read only, so I can't write the high scores to it. Is there any way to create a file that can be edited by the application but not by the user, or do I have to encrypt the file in some way?
Note: I prefer the C (stdio.h) method of file writing.
Even encryption won't stop editing of the file by something other than your application.
Can I suggest that one option is to simply store the data in binary format? You then save the complication of implementing an encryption, but still prevent any accidental editing of the file.
You could also make your application set the file to be read-only by all, and then make it writeable only while using it. Again, this won't prevent someone else changing those permissions, but it will prevent accidental editing.
There is an established means of accomplishing this on Unix-like systems, but I don't know how you'd do it on other platforms. The idea is to give the high scores files the group ID of a special group just for this purpose, usually simply called games. The games themselves are then setgid games, so that ordinary users can run games, and the games can edit the high scores files, but users cannot directly write to the high scores files.
More details over on Unix & Linux: https://unix.stackexchange.com/a/59059/14308
Related
I'm making a desktop app with wxWidgets but I can't figure out how it can have a more complex save system. For example, a project in Sony Vegas is saved in one file, and it's a (.veg). My save system will have to save mostly text from user, but in different areas. To be able to do this, do I need to save each thing I need separatly and load them all when I wish to re-enter the app? Sorry if this question seems obvious, I'm new fairly new at using wxWidgets.
Saving data to one or more files depends on how you organize your app.
It may read data from a file only when needed. Different tasks may use different files.
It may store everything in a single file. Read it all once. Or read parts of it for different tasks. If the file is too much big (my opinion, greater than 50 MB), obviously this is not the best option.
For the second option you may use std <fstream> functions. Or some of those provided by wxWidgets, which you will appreciate if you need to deal with text encodings, or other features as well.
Also, wxFileConfig may be useful if you wish to set several "sections" of your data.
I'm developing an engine for a 2D game in C ++ and for some days I've been looking for a way to protect the images and audio of my future game. I know there is no 100% protection and that someone would be able to open these files, but I mean the regular user who just installed the game, prevent it from modifying the sprites, change the sound, overwrite the xml files with game map data.
I downloaded some games made in Unity and noticed that a .assets extension is used, in Diablo 2 it is used .ma0, .mpq, .data, in FEZ .pak, in Super Meat Boy only a .tp file. In other words, you can not open and edit any of these files in a text editor or unzip with winrar, they offer a minimum level of protection. How is this done? Do I have to create my own binary file format or is there any program that makes it easier to work?
You can't.
That "minimum level of protection" is even more minimal than you think. You can open those files in a hex editor and hack away at them. This activity is something that has been commonplace for many decades.
You can encrypt the data, but since the key must be stored in your application and the user has a copy of your application, that can be extracted and/or changed too.
You can add a digital signature to prevent people from modifying the assets then using them ("modding") but, again, this can be altered in your application.
You can obfuscate the assets by shipping them in a proprietary format, but this is usually done purely for functional reasons because, again, someone will reverse engineer them.
Once a thing is on someone else's computer, you have lost control of that thing.
There are actually multiple questions here, iirc:
How can users be prevented from reading game assets?
How can users be prevented from manipulating game assets?
What file format can be used to store game assets?
If you're using an existing engine, it probably has some support for this, and if it is sufficient for your purposes you only need to learn how to use it.
If you need to roll your own, you need to define your requirements clearly and pick a solution which fulfills them. For asset storage, a ZIP based format is probably easiest to handle, all languages have some form of support for that. To protect integrity, you should use cryptographic algorithms: digital signatures to detect tampering, and encryption to prevent reading. These will probably slow down the opening of assets a little bit, but in most cases this should be acceptable.
I am using visual studio to develop a windows form application in c++ to detect certain anomalies and log it.
The log file that I am intending to create will be of a common format such as .txt. I do not want users of the computer to modify this file that is I want only my program to modify it( I want users to read this file not modify it).
Is there any way to achieve this??
if you want to hide the content from other users then encrypt the file or use a binary format that only your program will be able to understand.
As long as the file resides on a publicly accessible area in the file system, then other users will be able to access it.
You can put the file in a specific user's Documents area, which might go some way to protecting the file from other users of that machine, but not from administrators.
You could even set the file attributes to "hidden" or something along those lines, to further make it hard for people to find it. But a complete access block is difficult (if not impossible).
After all this, you can also use NirMH's method to ensure that even if someone finds and attempts to read the file, then the encryption should make it difficult to crack it open. A binary format can still be read with a hex editor, if someone is really keen to read your file.
I want to verify if the text log files created by my program being run at my customer's site have been tampered with. How do you suggest I go about doing this? I searched a bunch here and google but couldn't find my answer. Thanks!
Edit: After reading all the suggestions so far here are my thoughts. I want to keep it simple, and since the customer isn't that computer savy, I think it is safe to embed the salt in the binary. I'll continue to search for a simple solution using the keywords "salt checksum hash" etc and post back here once I find one.
Obligatory preamble: How much is at stake here? You must assume that tampering will be possible, but that you can make it very difficult if you spend enough time and money. So: how much is it worth to you?
That said:
Since it's your code writing the file, you can write it out encrypted. If you need it to be human readable, you can keep a second encrypted copy, or a second file containing only a hash, or write a hash value for every entry. (The hash must contain a "secret" key, of course.) If this is too risky, consider transmitting hashes or checksums or the log itself to other servers. And so forth.
This is a quite difficult thing to do, unless you can somehow protect the keypair used to sign the data. Signing the data requires a private key, and if that key is on a machine, a person can simply alter the data or create new data, and use that private key to sign the data. You can keep the private key on a "secure" machine, but then how do you guarantee that the data hadn't been tampered with before it left the original machine?
Of course, if you are protecting only data in motion, things get a lot easier.
Signing data is easy, if you can protect the private key.
Once you've worked out the higher-level theory that ensures security, take a look at GPGME to do the signing.
You may put a checksum as a prefix to each of your file lines, using an algorithm like adler-32 or something.
If you do not want to put binary code in your log files, use an encode64 method to convert the checksum to non binary data. So, you may discard only the lines that have been tampered.
It really depends on what you are trying to achieve, what is at stakes and what are the constraints.
Fundamentally: what you are asking for is just plain impossible (in isolation).
Now, it's a matter of complicating the life of the persons trying to modify the file so that it'll cost them more to modify it than what they could earn by doing the modification. Of course it means that hackers motivated by the sole goal of cracking in your measures of protection will not be deterred that much...
Assuming it should work on a standalone computer (no network), it is, as I said, impossible. Whatever the process you use, whatever the key / algorithm, this is ultimately embedded in the binary, which is exposed to the scrutiny of the would-be hacker. It's possible to deassemble it, it's possible to examine it with hex-readers, it's possible to probe it with different inputs, plug in a debugger etc... Your only option is thus to make debugging / examination a pain by breaking down the logic, using debug detection to change the paths, and if you are very good using self-modifying code. It does not mean it'll become impossible to tamper with the process, it barely means it should become difficult enough that any attacker will abandon.
If you have a network at your disposal, you can store a hash on a distant (under your control) drive, and then compare the hash. 2 difficulties here:
Storing (how to ensure it is your binary ?)
Retrieving (how to ensure you are talking to the right server ?)
And of course, in both cases, beware of the man in the middle syndroms...
One last bit of advice: if you need security, you'll need to consult a real expert, don't rely on some strange guys (like myself) talking on a forum. We're amateurs.
It's your file and your program which is allowed to modify it. When this being the case, there is one simple solution. (If you can afford to put your log file into a seperate folder)
Note:
You can have all your log files placed into a seperate folder. For eg, in my appplication, we have lot of DLLs, each having it's own log files and ofcourse application has its own.
So have a seperate process running in the background and monitors the folder for any changes notifications like
change in file size
attempt to rename the file or folder
delete the file
etc...
Based on this notification, you can certify whether the file is changed or not!
(As you and others may be guessing, even your process & dlls will change these files that can also lead to a notification. You need to synchronize this action smartly. That's it)
Window API to monitor folder in given below:
HANDLE FindFirstChangeNotification(
LPCTSTR lpPathName,
BOOL bWatchSubtree,
DWORD dwNotifyFilter
);
lpPathName:
Path to the log directory.
bWatchSubtree:
Watch subfolder or not (0 or 1)
dwNotifyFilter:
Filter conditions that satisfy a change notification wait. This parameter can be one or more of the following values.
FILE_NOTIFY_CHANGE_FILE_NAME
FILE_NOTIFY_CHANGE_DIR_NAME
FILE_NOTIFY_CHANGE_SIZE
FILE_NOTIFY_CHANGE_SECURITY
etc...
(Check MSDN)
How to make it work?
Suspect A: Our process
Suspect X: Other process or user
Inspector: The process that we created to monitor the folder.
Inpector sees a change in the folder. Queries with Suspect A whether he did any change to it.
if so,
change is taken as VALID.
if not
clear indication that change is done by *Suspect X*. So NOT VALID!
File is certified to be TAMPERED.
Other than that, below are some of the techniques that may (or may not :)) help you!
Store the time stamp whenever an application close the file along with file-size.
The next time you open the file, check for the last modified time of the time and its size. If both are same, then it means file remains not tampered.
Change the file privilege to read-only after you write logs into it. In some program or someone want to tamper it, they attempt to change the read-only property. This action changes the date/time modified for a file.
Write to your log file only encrypted data. If someone tampers it, when we decrypt the data, we may find some text not decrypted properly.
Using compress and un-compress mechanism (compress may help you to protect the file using a password)
Each way may have its own pros and cons. Strength the logic based on your need. You can even try the combination of the techniques proposed.
I want to know what are the best ways/practices of handling user settings in a program. I'm writing a program and want to allow users to save settings which can be loaded automatically as soon as the program starts. I'm not just asking for codes, but the best practices of handling such as how to handle the settings at run time, should I need to create an object such as UserSettings (I'm using Java)? Which format is best for saving the settings (XML/JSON?)? Is it good to have the file format human readable? what are the things that I should take care of? I like to hear the thoughts/advices of some professional stackoverflow users out there.
Having a human-readable format is great; if for some reason a setting makes the program completely unusable it is then possible to go in and frob the setting to something sane.
If your users will roam from computer to computer then having user settings in a database or some centralised repository makes sense.
Otherwise, a locally-saved, human-readable .INI (with named sections) or a .XML file.
If using a .XML file, try to avoid making it too 'dense', and sprinkle with appropriate comments.