Robust method for storing data outside of a program

I have a program that I need to save data from, it is information about a number of players and their scores. I want to keep a running record of the scores when the program is not running and use the scores the next time the program boots up.

The information shouldn't be editable and I don't know a way to store this, at the very least I could use a text file reading the scores but a text file isn't very robust and is readily editable, is there any other option available?

You could use some kind of data-base ... I've heard good things about http://www.sqlite.org/

SQLite would be a good choice as one of its uses is as a replacement for fopen(). However, you probably need some kind of encryption, otherwise a user could write a program to edit the SQLite database file, or just use the SQLite shell provided on sqlite.org.

This is easier said than done though: if everything is stored clientside, the user may be able to circumvent whatever encryption you use by finding the key.

You could make the program store scores on a central database server that you run, which would make it extremely difficult for users to hack the scores, but, if they reverse engineer your server communication, password, etc., then everyone's scores will be compromised.

Use Boost libraries.

It really depends on how secure you want the scores to be. If you just want the average use double-clicking on "scores.txt" out of curiosity to not be able to do anything, you could get away with something as simple as using the OR's complement operator (~) on every byte you write to the file, or XOR encryption.

There is no totally secure way of keeping high scores. There just isn't. We had a similar thread a few months back, and all ideas basically amounted to security through obscurity.

You can also use boost::serialization libraries to save data to the files.

thanks twomers, I've had a chance to look at sqlite, it looks like it might be ideal for what I'm doing now and another couple of ideas in the pipeline.

Thanks for the other responses guys, I'll keep them in mind. I suppose there is no way to make scores absolutely safe but I guess thats the same with everything, it's just up to us to make it more difficult to penetrate such files and storage methods.

You could write the data as byte data rather than text.

Quote:

---

Originally Posted by CornedBee

There is no totally secure way of keeping high scores. There just isn't. We had a similar thread a few months back, and all ideas basically amounted to security through obscurity.

---

I suppose the only way to do it would be to have a server that would handle pretty much everything. Then the OP could run an official server, which would presumably have valid high scores because he or she would control the server and no one else could modify it.

But that would involve a lot of data transfer. The client would pretty much have to send every keypress to the server for it to handle. It would be doable, but since the server would only communicate with one client at a time (i.e., it's a single-player game, not a multiplayer one), it would probably be overkill.

Anything else would indeed be "security through obscurity".

Using some sort of stored checksum on a server would also work reasonably well - whilst it's POSSIBLE to do stuff to overcome complex checksums, if you also make sure that the file-size is intact, and that the content is "correct" after decryption, it makes it fairly complex to come up with a combination of bytes that are both matching the checksum, and makes good name/numerical ASCII characters, for example - so by storing a string like this:
"Mats 12345678" as the high-score value, then you should only have valid letters in the name and only valid digits in the score - so inserting random garbage in the score-file makes it invalid.

It's still sort of security-by-obscurity, but by restricted use of letters/numbers make it quite hard to make arbitrary changes without invalidating the score table - of course, someone can always bypass the checksum check if they patch the binary - so it's still not impossible to bypass the scheme - just harder.

--
Mats

I was thinking more along the lines of this scenario:

There's a highscores server somewhere reasonably public. Every once in a while someone adds a score to the table. But what's to prevent the scores from being generated and submitted by hand?

So my post was dealing with the possibility that false data could be generated, not the possibility that the already-stored data could be modified. I realize that the latter is probably closer to what the OP was looking for. I think I've got UberTube on the brain. :) http://cboard.cprogramming.com/showthread.php?t=77630

Your solution has a few flaws: it only checks the validity of the data -- there's nothing to prevent the data from being modified in the first place. Also, where are you going to store the checksum? Because a cracker could always re-generate the checksum if you stored it in plaintext somewhere.

There may be something I've missed, but as far as I can see it basically comes down to this, for secure security: there needs to be more interaction between the server and the client, rather than a highscore just showing up out of the blue; or else there needs to be a location that is private.

In a private location you could store the entire file, or if that is not possible, a checksum of the file or whatever. But I don't think that you'd often have access to a private location like this.

So that just leaves extensive communication between a client and a server if you want completely secure data. In a way, this is the same thing, with the server executable itself being the immutable data storage location. :)

Which is why I suggested:

Quote:

---

Using some sort of stored checksum on a server would also work reasonably well...

---

But there's no such thing as an "impossible to break" system. Someone can still generate a different checksum and send that to the server somehow.

--
Mats

Mmm, well, as I already mentioned, I would prefer encryption, which would prevent the data from being modified in the first place. It's no use if you know that the scores have been tampered with unless you kept a backup somewhere. More security, more obscurity, more obfuscated-ity . . .

You're right about no such thing as impossible to break, however. (Well, at least until quantum computers come along.) Even my example, with the server doing everything and the client basically a terminal, could be cheated by a program which generated the keypresses, creating a "player" with extremely fast thinking and reflexes . . .

BTW, how would you calculate checksums in C? What library would you use, if any?