My son and I were playing a Windows 8 game where we would get coins for completing each level and then we had to spend coins to be able to beat the next level.
Obviously, it was taking forever to get any meaningful amount of coins – which is by design, I get it. The game allows you to pay real cash for these virtual coins, in the hopes that the emotional connection you have with the game will make you think it is worth paying for.
Unlike my kid, I have lost the energy to spend on such endeavors so I began wondering how the game implemented their ‘coin storage’.
In this particular game, which I’ll leave unnamed for the sake of the developers, you can buy coins over and over, so my instinct was to assume they were simply storing the amount of coins a gamer has in the LocalSettings of the ApplicationData class, which are implemented in Win8 using Registry hives. That being the case, we can load and inspect hives manually in the registry, so I decided to give it a try.
I loaded the Registry Editor, selected the HKEY_LOCAL_MACHINE root and chose File->Load Hive. The %USERPROFILE%\AppData\Local\Packages folder contains user settings for the modern Win8 applications. Each app has its own folder and under that there is the Settings\settings.dat file, which happens to be a registry hive. We loaded that and explored the keys and values. As luck would have it, this particular game happens to store the number of coins the games has with a setting named, guess what, “coins”.
Oh, that’s too easy…
WinRT settings uses binary blobs to store the values in the registry, but I noticed a pattern among them, so it was a safe bet that part of the blob was encoding the type of the data (“integer” in this case) while the first 4 bytes of the “coins” value were the raw hex value of the number of coins we had accumulated so far in the game.
I just bumped that value up to FFFFFFFF and unloaded the hive. To be honest, I expected the app to crash, but after restarting the game I found that I was the (not so proud) owner of a lot of coins and that we could use them at will. There were other settings as well in the game that you could buy with the coins, and I suppose I could have tweaked them as well.
The whole process took a couple of minutes, if that much. Again, way to easy….
Out of that little exercise in cheating I came up with three lessons:
- For the kids who love playing the game:
The game lost its appeal. If you want to keep playing that funny addictive game you love so much, don’t cheat! After all, if you cheat and ‘beat’ the game like this you lose the emotional connection you would otherwise have with the game and then it is just not that much fun anymore.
- For the kids whose dads (like me) just won’t let them pay for games on a daily-basis, or if you just want to see how the game works without having to play for endless hours:
Emotional-connection? Yeah, right. We can try to tweak the game settings and see what happens – with the usual disclaimer that doing so can render the game unplayable if you don’t know what you are doing. There is also the option of running in the debugger – that’s always fun… 🙂
- And the real objective of this post, is for developers out there:
Do add a minimum of encryption on top of these things that people are supposed to pay for, otherwise it is a lost opportunity for profit. A little work with the DataProtectionProvider or some other API will protect these settings from quick tweaks like this and that translates to either an actual purchase or at least some more hours of game play and the ads that come along with them, and those are money in the pocket, so there’s no reason to leave things in the open.
Obviously, not every game out there makes this mistake, so this only works on a case-by-case basis.
And it is likely that the popular games that you REALLY want to do something like this will be exactly the ones where they will protect themselves.