What I am doing is making a console blackjack for fun. I want to save the money so users can play day by day but I don't want to save it in a text file where the user can easily change the amount as they please.
I already thought of making a hidden file or a encrypted file with a password but I don't like that. I want it to be sort of like when you open some random dll file, all you see is gibberish that you can't understand.
A bulletproof way to prevent users from tampering with their stats is to store stats away from them, on a remote server. This will require users to be online during play, though. OTOH you'd be able to show a ladder of top players and so on.
An encrypted file is probably the best route if you want offline storage. You just need to hide the file properly.
Before modifying the file, read its modification time. After the update, restore the time. The user will have harder time figuring out which file has changed.
Use an innocent file used by your game with a data block inside allowed by format. It could be an XML file storing the encrypted string in a comment. It could be a JPG or PNG file storing the encrypted string in a comment or EXIF section, at a known offset (so you don't need to parse the file). WAV, OGG, MP3 also allow inclusion of non-interpreted data. This is not real steganography when you hide your data inside the actual pixel values and such, and is far easier.
I suppose you understand that a determined cracker with a disassembler and a debugger can crack this scheme. But an average user probably won't bother.
It sounds like you are talking about Steganography, but traditional encryption is probably safer and easier to implement.
You can encrypt the values within the file:
Have a look at: http://dinofilias.com/encrypt.htm
With basic encryption like this as long as the user does not have access to the key, your data is relatively secure.
You can get the effect of having a file that contains gibberish using encryption. Just save the encrypted data as bytes (not converted to ASCII representation). Since the encrypted data can have values between 0x00 and 0xFF, there will be gibberish.
Here is a simple example of how to encrypt text: http://www.exampledepot.com/egs/javax.crypto/desstring.html
Related
I have written a program to encrypt video files, however I can not open it after encryption. I want the output of the encryption to be able to play the file with encrypted bytes (i.e. Should be able to play the file in its encrypted form) like we do for.png file by keeping their header intact. Desired output reference
what you intend to do might be a little bit more complicated than what you imagine ...
in order to appear to video tools as a valid file, that can actually be played, you have to understand the corresponding file formats.
with image file-formats like bitmap or png, the header is an actual header, in other words a specific structure, usually at the start of the file, that describes what follows ...
with video formats it's the same but ... isn't...
there are different container formats, and what you need to preserve and what you can encrypt might differ from one to another...
for example mpg (the format you will find on DVDs) can contain numerous streams, which can (afaik) be distributed over multiple files, with each file containing various headers at different locations (a table of contents, headers for each video and audio stream, etc ...)
for those formats you will actually have to decode the headers and calculate the positions (and lengths) of other headers...
so ... even just finding the headers is a piece of work ... which needs to be done once per supported file format, and there are a few... https://en.wikipedia.org/wiki/Video_file_format
ok, and then we leave the headers, scramble the rest and we have playable encrypted videos, right?
... sadly ... nope...
next up: video and audio encoding/compression
you will actually have to understand how frames and audiosamples are compressed and encoded ... because the software that will decompress and render the images and audio, actually needs valid streams, depending on encoding, this includes checksums and error correction codes ...
but wait ... can't we just, let's say ... re-encode everything into some easy format without most of this crap, and then have something simple like skip the first X bytes and after that encode?
sure thing, but please remember that the original encoding was there for a reason ... maybe the video was intended to be played on certain devices that expect certain encodings -> the video would not be playable there
ok, but can't we re-encode again, just like we did before?
sure thing... but there will most likely be that slight problem with the filesize...
video encodings usually employ some sort of compression ... like using the property of a video that from one frame to another usually not all pixels change ... if we just encode every few frames and the deltas in between, we can store the same video on way less storage space ... or we could employ standard compressions like zip ... yeah... right... not with encrypted data ... you will have a very hard time to compress encrypted data, or save space with the delta approach ... read up on entropy and how compression works for this one ...
oh and one more thing about reencoding after encryption: if you ever want to decrypt, you better make sure that the new encoding can be reversed without any loss of information... not all codecs are lossless
so... why does it have to be playable? is it worth the effort?
I have searched around for the best methods for encryption in terms of what ciphers to use, methods/etc. I'v decided on using 128Bit AES for the time being. My question lies more in what method is best for encrypting various types of data. In my example, this is for a small game I am making that has map data and associated image data.
I can save the data in any format, but would prefer something simple to read (when un-encrypted). Should I actually save this to the file itself, or should I change the file itself in some way?
Likewise in terms of the image files associated to the game that are saved as PNG or BMP files, any recommendations on how to encrypt those on top of the rest of the files?
My current method for the game data is to just encrypt it in singular lines - and have it load from a file line-by-line. Each line formatting to a different data value to be put into the system (e.g. load part of a map, maybe some item data, etc). Is there a better/faster method of accomplishing this that I may not have found yet?
I was also wondering about actually taking the entire class with the data saved and serializing it - then encrypting it. That way I could load the entire thing in one go straight into a class. Would this be a reasonable idea?
For the images: you can read them using a CipherInputStream / CipherOuputStream. Note that at least older Java versions ignored padding errors for CipherInputStream.
You cannot directly encrypt to lines as the output of a cipher is binary. So you need to encode (using e.g. Base64) if you want to store the result as lines. You may ask yourself if you want things like game data to be in text. I would recommend CBC mode with random IV prefixed to the ciphertext.
If the data is serializable then serializing data could be an option. Personally I'm not a huge fan of serialization in Java due to the many pitfalls. But yes, you can certainly encrypt serialized data easily, it's binary after all.
Im trying to do something like this:
Take an swf file corrupt it, Then ..inside the device turn it readable (not corrupted)again ... I´ll check, with a device-finger-print writen by myself, if that device can uncorrupt the swf.. got?
Can I do this? what is the way? Thanx!
This requires File I/O
encrypt the swf with like base64 or anything and append any random string to the beginning or end of the file, save it somewhere, and de-encrypt it when you want to use it
There are of course many ways make reversible changes the contents of an swf file so that it is not playable by other players until the changes are reversed. At the minimum, you could reverse its 3 byte signature to make it unplayable and reverse it again.
But any such naive mechanism you employ can be cracked very easily. It will not protect you from any malicious activity and will only inconvenience legitimate usage.
If you really need to do this, look at more sophisticated encryption and DRM
I am currently writing a program which takes user input and creates rows of a comma delimited .csv file. I am in need of a way to save this data in a way in which users are not able to easily edit this data. It does not need to be super secure, just enough so that it couldn't accidentally be edited. I also need another file (or the same file?) created to then be easily accessible (in the file system) by the user so that they may then email this file to a system admin who can then open the .csv file. I could provide this second person with a conversion program if necessary.
The file I save data in and the file to be sent can be two different files if there are any advantages to this. I was currently considering just using a file with a weird file extension, but saving it as a text file so that the user will only be able to open it if they know to try that. The other option being some sort of encryption, but I'm not sure if this is necessary and even if it was where I would start.
Thanks for the help :)
Edit: This file is meant to store the actual data being entered. Currently the data is being gathered on paper forms which are then sent to the admin to manually enter all of the data. This little app is meant to have someone else enter the data from the paper form and then tell them if they've entered it all correctly. After they've entered it all they then need to send the data to the admin. It would be preferable if the sending was handled automatically, but this app needs to be very simple and low budget and I don't want an internet connection to be a requirement.
You could store your data in a serializable object and save that. It would resist casual editing and be very simple to read and write from your app. This page should get you started: http://java.sun.com/developer/technicalArticles/Programming/serialization/
From your question, I am guessing that the uneditable file's purpose is to store some kind of system config and you don't want it to get messed up easily. From your own suggestions, it seems that even knowing that the file has been edited would help you, since you can then avoid using it. If that is the case, then you can use simple checks, such as save the total number of characters in the line as the first or last comma delimited value. Then, before you use the file, you just run a small validation code on it to verify that the file is indeed unaltered.
Another approach may just be to use a ZIP (file) of a "plain text format" (CSV, XML, other serialization method, etc) and, optionally, utilize a well-known (to you) password.
This approach could be used with other stream/package types: the idea behind using a ZIP (as opposed to an object serializer directly) is so that one can open/inspect/modify said data/file(s) easily without special program support. This may or may not be a benefit and using a password may or may not even be required, see below.
Some advantages of using a ZIP (or CAB):
The ability for multiple resources (aids in extensibility)
The ability to save the actual data in a "text format" (XML, perhaps)
Maintain competitive file-sizes for "common data"
Re-use existing tooling support (also get checksum validation for free!)
Additionally, using a non-ZIP file extension will prevent most users from casually associating the file (a similar approach to what is presented in the original post, but subtly different because the ZIP format itself is not "plain text") with the ZIP format and being able to open it. A number of modern Microsoft formats utilize the fact that the file-extension plays an important role and use CAB (and sometimes ZIP) formats as the container format for the document. That is, an ".XSN" or ".WSP" or ".gadget" file can be opened with a tool like 7-zip, but are generally only done so by developers who are "in the know". Also, just consider ".WAR" and ".JAR" files as other examples of this approach, since this is Java we're in.
Traditional ZIP passwords are not secure, and more-so is using a static password embedded in the program. However, if this is just a deterrent (e.g. not for "security") then those issues are not important. Coupled with an "un-associated" file-type/extension, I believe this offers the protection asked for in the question while remaining flexible. It may be possible to entirely drop the password usage and still prevent "accidental modifications" just by using a ZIP (or other) container format, depending upon requirement/desires.
Happy coding.
Can you set file permissions to make it read-only?
Other than doing a binary output file, the file system that Windows runs (I know for sure it works from XP through x64 Windows 7) has a little trick that you can use to hide data from anyone simply perusing through your files:
Append your output and input files with a colon and then an arbitrary value, eg if your filename is "data.csv", make it instead "data.csv:42". Any existing or non-existing file can be appended to to access a whole hidden area (and every file for every value after the colon is distinct, so "data.csv:42" != "data.csv:carrots" != "second.csv:carrots").
If this file doesn't exist, it will be created and initialized to have 0 bytes of data with it. If you open up the file in Notepad you will indeed see that it holds exactly the data it held before writing to the :42 file, no more, no less, but in reality subsequent data read from this "data.csv:42" file will persist. This makes it a perfect place to hide data from any annoying user!
Caveats: If you delete "data.csv", all associated hidden data will be deleted too. Also, there are indeed programs that will find these files, but if your user goes through all that trouble to manually edit some csv file, I say let them.
I also have no idea if this will work on other platforms, I've never thought to try it.
I'm developing a program that needs to load and save data in external files, I have been searching for options and I have chosen to save the data in a binary file.
As I don't want that someone could edit the file easily, I thought about writing in the first line of the file, its md5 sum. In this case, if some data of the file is changed, the sum won't match the one of the first line.
The problem I find then is that if I calculate the MD5, and after that I write the info inside the file, it's obvious that the sum will be different, so, how could I sort this?
If you sugest me a better option than the sum, it will be equally accepted.
Thanks in advance.
What is your threat model?
If you just want to protect against casual fiddling, md5 the main data of the file, then write the md5 sum to the end. To validate, strip off the md5 sum, then md5 only the original file.
If you want to protect against malicious and skilled cracking, you're out of luck; any validation algorithm you use can be replicated, particularly if they have access to the program itself. Even a cryptographic signature could fail if the attacker extracts the key from the program binary.
If it's a big deal, a unix solution is to run as setuid or setgid to a different user and write to a directory which users cannot modify. I'm not sure what a good general Java solution is, but the point remains: users shouldn't be able to modify your data because they were prevented from doing so, not because they were detected trying to.
While it is theoretically possible to make a self-referencing MD5 file (and I recall some have been found), it's a waste of resources. It is generally necessary to store the hash somewhere outside the hashed file (traditionally named md5sums or sha1sums, respectively).
This said, I'd recommend going for SHA-1 in addition to MD5.
Bill: Ted, while I agree that, in time, our band will be most triumphant. The truth is, Wyld Stallyns will never be a super band until we have Eddie Van Halen on guitar.
Ted: Yes, Bill. But, I do not believe we will get Eddie Van Halen until we have a triumphant video.
Bill: Ted, it's pointless to have a triumphant video before we even have decent instruments.
Ted: Well, how can we have decent instruments when we don't really even know how to play?
Bill: That is why we NEED Eddie Van Halen!
Ted: And THAT is why we need a triumphant video.
Bill, Ted: EXCELLENT!
Seriously, you can't calculate the MD5 sum (or some other hash) with the calculated hash embedded, so you have to store the hash somewhere else.
If you just don't want people to easily mess with the file, maybe it's an option to obfuscate it via ROT13 or XOR "encryption" ?
What if you create a container for your data? Through a new class with two properties, CheckSum and Data, you could serialize all your data and put it in the Data property. Then, you calulate the checksum for the serialized data, and use the CheckSum property to store the checksum.
Just ignore the first line when you compute the md5. You should also add a secret salt to make sure it's not to easy to create a new MD5 after editing the content. It depends on your actual need (level of security).
you could store the MD5sum in a database instead, then when you want to see if a file has been changed you check the MD5 sum in the db. alternatively you could store the md5sum of a file in another file.