Re: Hacking The Leaderboards

This post was created for Twitter, I've left this copy as close as possible to the original. If it reads a bit strangely, that's why.  A revised copy is at https://blog.javacakegames.com/hacking-unipop-leaderboards

Well there we are. I've been backstabbed (/s) by former partner @DeveloperDoge. He's basically created a tutorial for how to cheat on the Unipop (https://javacakegames.itch.io/unipop) leaderboards. But what can we learn from this? Let's create a Twitter thread.

The first takeaway is to never trust the client. This is a very important part of basic security, and I do have some validation in place. My server only accepts alphanumeric names up to (& including) 32 characters long, numerical scores up to 3 chars long, + a sanity check hash.

But what do we do other than trust the client? We could run the game on a server, as I think is common with MMORPGs, but that's slow, and requires both a semi-decent server and the user to have a stable internet connection. The latency simply wouldn't be suitable for Unipop.

Of course, there's also alternatives to making your own leaderboards. How about something as reputable as Google Play Games? After all, Google says it "provides a leaderboard tamper protection feature that checks for suspected tampered scores and hides them automatically." Nope.

The only thing I think we could do about this is to capture as much data as possible, to store a replay of the play session and more, to either automatically or manually verify the run's legitimacy. But that involves more effort than I was going to put into a jam game.

What else can we learn from the video? Well, he uses the Firefox debugger whatsit to set a breakpoint and dig into the code to learn more about how my sanity check hash is produced. Could this be avoided? I think it could be made harder, but it can't be avoided entirely.

See, any code that runs on the user's computer can be browsed, to a degree. My rule of thumb is that the higher-level a language is, the easier it is to reverse-engineer. So it would be easier to work out English than assembly code. That's a terrible explanation.

So let's say we didn't use JavaScript, and instead had a downloadable Windows executable of some description, not even created with a game engine. Someone would still be able to open up this executable in IDA Pro, Ghidra or goodness knows what other tools to poke around.

We also see in the video how a game's method can be replicated in even a different language, albeit after a little help from eyeing the original unobfuscated source code. This could easily be run on multiple computers around the world, destroying the leaderboards.

You can also catch a glimpse of another anti-cheat method in the video. I have this "antiBallsPopped" variable, which aims to make it harder to cheat in the game by using memory editors such as CheatEngine and Game Conqueror.

Since I'm on the topic of memory-editing, let me confess my sins. Back in the day, I loaded up The Simpsons: Tapped Out into BlueStacks and used CheatEngine to acquire more Donuts (the premium currency) and buy things. Don't know why they didn't at least ban people who did that.

Eventually, EA patched this. They probably just made it slightly harder to do, but it was enough to keep me out. So at that point I just started using those modded APKs you find online, where someone else has already cracked the game for you.

In conclusion, someone with enough time will always find a way to cheat. If they don't have experience with such h4x0r things, they can always get experience. In my opinion, it's definitely worth adding some obstacles to keep casual cheaters out.

Just don't spend too much time creating your obstacles. I've found that one individual has been unable to submit any further cheated scores since I added the sanity check hash, so even if my measures seen here won't keep everyone out, they're still effective to some degree.