Android: how to protect data in a SQLite database?

Question

I'm currently developing an Android game which saves data into a SQLite database. This is not really "sensitive" data, but I don't want users to be able to modify it (for obvious reasons of game balance, as it would be cheating). And it's quite easy to access and modify a SQLite db when your phone is rooted (there are plenty of applications for that in the market).

So should I even worry about that, or consider users with a rooted phone can do whatever they want including cheating and that's their choice? Or could I somehow encrypt the data I don't want them to modify, or add a MD5 checksum or something similar?

Another approach would be to abandon SQLite altogether and use some kind of binary files with game data.

Please let me know if some of you already encountered similar issues, and what are the approaches you followed, as well as the "good practices" in the Android gaming development community.

Thanks.

Solution 1

Root access for everybody and security are mutually exclusive.

Any application or user with root permissions can read and modify each and every file on your system, as well as all of the main memory. That doesn't leave many places to store a potential encryption key for the database.

You could hide parts of the key in the executables, configuration files etc, but everything you could come up with would be nothing more than obfuscation and security by obscurity.

If a user opts to grant root access to everybody, that's their decision, and it's not your job as an app developer to prevent any harm that might be caused.

Update: Storing API keys in Android, is obfustication enough? is a pretty similar issue - it's about protecting API keys, but it's the same situation with regards to your options.

Solution 2

sqlcipher for Android might help here.

https://guardianproject.info/code/sqlcipher/

Solution 3

I think based on your requirement the best method is using consistency of data, for example MD5 the score and time, then put score and time and MD5 in to the table, then every time wanting to use that row of DB check the MD5 of the score and time if the one in DB and the one which calculated are same, the row is consistent otherwise it was hacked!

Comments

[Guillaume]

No, my data structure is far too complex to use shared preferences. But thanks anyway, that was indeed my first try, but that quickly became unmanageable.

[Guillaume]

Interesting, I will look into that, although it's only alpha as of now. I'm also worried about performance impact, I will need to do some testing.

[Guillaume]

True in a way, but it's my job to try and preserve a certain balance to the game I'm doing - I know no security is perfect, but as there is no financial gain involved, I don't expect users to bring the big guns to hack my database if it's encrypted :) And anyway, I'm not even sure I will add encryption or anything else in the end,. I'm just interested by potential solutions

[lxgr]

Oh, so you're worried about cheaters that use rooted phones to gain some advantage, modify scores etc.? Your best bet would then probably be obfuscation to protect against "casual cheaters". But somebody determined enough will always eventually reverse engineer your efforts in the end - you can't control your user's phones. See the link in the update for a bit more details.

[bschandramohan]

I think shared preferences are also stored as files under sharedprefs folder of the app. So, if phone is rooted, user would be able to access that too.

[Guillaume]

Ok, thanks for the link and your opinion. I'm going to go with simple obfuscation, or "obfustication" as they say in that question ;)

[Jan Slodicka]

Perf impact is probably ok. I am rather concerned with the fact that the encryption scheme is (in my opinion) implemented incorrectly. To short space to explain it here, I'm thinking of writing special topic.

[laalto]

What prevents the attacker from modifying the MD5 as well?

[Navid]

if you use your own hashing method its very hard to mimic it! although not impossible.