Merits of Anti-Reverse-Engineering for MOGs

	Author:	“No Bugs” Hare  Follow:
	Job Title:	Sarcastic Architect
	Hobbies:	Thinking Aloud, Arguing with Managers, Annoying HRs, Calling a Spade a Spade, Keeping Tongue in Cheek

[rabbit_ddmog vol=”8″ chap=”Chapter 29(a) from “beta” Volume VIII”]

We have already reached Vol. VIII of the nine-volume “Development & Deployment of Multiplayer Online Games” epic. By this time, if your MOG is successful, you’re already popular enough to attract cheaters. We have discussed the motivation for cheating in Vol. I’s chapter on Cheating & Authoritative Servers, so I won’t repeat it here. However, one thing has to be re-iterated:

Even if you’re 100% sure that there is absolutely nothing for them to be gained – they will still find a way to cheat and monetize the cheat. The most glaring example I’ve seen in this regard, was a play money poker site where cheaters wrote bots to get free play chips in large quantities over different accounts, then chip-dumped them to a few dedicated accounts, and then sell these play-money chips for real dollars on eBay (so that buyers of those play chips can boast about being good players <ouch! />).

Moral of the story is that cheaters are not a function of the logic of your game – but rather a function of your game success. If you have a hundred of thousands of simultaneous players – you do have cheaters (and if you don’t see them – it is just because you’re not looking for them persistently enough).

Anti-piracy = Bad

Now, let’s see our (=”MOG developers”) side of dealing with cheaters. First of all, let’s note that

With anti-piracy protection, two separate issues arise:

• From the point of view of motivation to use anti-reverse-engineering, piracy-vs-anti-piracy is a conflict strictly between pirate and developer, and there are absolutely no other parties involved. This, in turn, implies that:
  • Software companies using anti-piracy protection are often perceived as “greedy”. Among other things, pretty often, a “non-scarcity” argument is raised, going along the lines of “hey, when I copy it, you don’t lose your copy, so there is no harm done” – known as a “non-scarcity argument”. Fortunately, we don’t need to debate merits (or lack of those) of the non-scarcity argument – as for MOG cheating, as we’ll see below, there is the harm done, and a pretty obvious one.
  • “Anti-piracy measures do NOT bring any improvements to the experience of the software customer, but at the same time can easily hurt the customer badly.Anti-piracy measures do NOT bring any improvements to the experience of the software customer, but at the same time can easily hurt the customer badly. I am not even speaking of outright stupid things such as “Sony rootkit scandal” [TODO:ref], but pretty much any usual run-of-the-mill protection is either already-broken-long-ago, or is highly-risky for the customer.
    • This means that as a customer of usual (non-MOG) software, I have all the reasons to hate any such protection (I have nothing to gain, and lots to lose).
    • As a result, I tend to agree that most of the “anti-piracy protection” measures tend to hurt producers more than benefit them.² One potential exception to this observation can be expensive CAD programs etc. (while I am not sure about the merits of anti-piracy protection even in this case, I cannot rule them out outright). What is clear though is that for mass-market programs taking any risks with protection-making-life-of-customers-worse just isn’t worth it. In other words, with a few minor reservations I tend to agree with [TODO:Kaspersky] on that “software protection is not economically efficient”.
• “Given enough time, everything can be brokenFrom the point of the ability to protect the software, there is a huge problem too. For any Client-Side software, we’re giving the software to the hands to the attacker (which means “given time, everything can be broken”); however, for non-MOGs it is even worse, as the hacker indeed has all the time in the world to get it broken. Moreover, as soon as the breach is found, the game is essentially over for protection (at least until next version comes out, but even when it happens, nothing prevents the whole world from using a-bit-outdated version).
  • Hey, even hardware protection in PS3 was eventually hacked – and it is not a coincidence, but a perfectly inevitable result.
  • Speaking of hardware, here goes a quote: Sergei Skorobogatov (one of the topmost authorities on hacking hardware) has wrote that “There is no such a thing as absolute protection – given enough time and resources any protection can be broken” [Skorobogatov]

As a side note: for non-MOGs, there are certain deployment schemas (essentially – when some absolutely-critical part of the task is delegated to the Server-Side), which don’t suffer from these problems (but then they don’t usually need anti-reverse-engineering protection as an anti-piracy measure); there are currently certain signs that these schemas MIGHT become a trend in the future, but for our current discussion on MOGs it doesn’t matter much.

MOG Protection = Good

Right above, we analyzed the reasons why anti-piracy protection techniques have such a bad name (and why they don’t really work – except maybe for some not-so-popular and one-of-a-kind software where customers are ready to jump through the hoops to get access to it). Now, let’s see why MOGs are very different in this regard.

Motivation-wise, for MOGs anti-bot protection, there are THREE parties involved in the conflict: (a) MOG developers, (b) cheaters, and (c) all non-cheating players. In other words –

“in this fight, most of the non-cheating player population will be on our sideSure, in doing it we’ll be protecting our own selfish interests too – but these will come as a side effect of the noble-goal-of-protecting-non-cheaters, so not too many people will complain. Moreover, with anti-bot protection, average non-cheating player has a LOT to gain from us dealing with cheaters, which means that in this fight, most of the non-cheating player population will be on our side,³ giving us a very powerful mandate to do whatever-is-necessary-to-do in this direction.

And from the point of view of our ability to protect – we’re inherently in a much better position than traditional anti-piracy folks. The difference is that we can update our software monthly (or even weekly)⁴ – and we can change protocols too, effectively disabling a lot of the previously-released hacks (sure, attackers can hack us again using their previously-acquired knowledge, but it is still not as easy as just doing nothing and using previous version). How to do it without spending too much time – is a subject of a subsequent discussion, for now we just have to note that it is possible (and we’ll demonstrate the feasibility a bit later).

Of course, it is not that we can provide 100% protection⁵ – but we DO have a fighting chance (and more importantly, even if we got hacked – we still can regroup and fight back).

In other words,

Myths: “Don’t write abusable games” and “Anti-Reverse Engineering is a Lost cause”

Unfortunately, with lots of people confusing anti-piracy protections and MOG protections, a lot of non-arguments against protecting MOGs are brought forward to argue we shouldn’t do it (almost-universally coming from people-having-no-idea-about-MOGs). While debunking all of these myths would take too much time, I will point out two of the most popular ones.

“I don’t know of any single competitive multiplayer game which cannot be abusedThe first popular non-argument against anti-cheating MOG protections goes along the lines of “hey, it is easy – just write only games which cannot be abused, problem solved!”. Sure, it would be an ideal solution; there is only one minor problem with it – and that it is there are no such games (at least as long as we’re speaking about at least some kind of competition). Once again – I don’t know of any single competitive multiplayer game which cannot be abused. Chess or any other strategy game? Easily abused by substituting player with a cheating computer (and these days, computers can beat humans even in Go[[TODO/wikiquote Go]]). Any team competition game with some information hidden between team players (bridge, RTS without automated sharing maps between teamplayers, etc.)? Subject to collusion by design. Anything related to reflexes/precision/… (shooters, sports, MOBAs, etc.)? Even more easily abusable than anything else.

Another popular myth about anti-cheating protection is that “it cannot be done”, which is further expanded into “we shouldn’t even try”. It is interesting to note that the most ardent supporters of this non-argument come from two completely different fields:

• Academics. From the academical point of view, if it is “security by obscurity”⁶ – it is fundamentally breakable, which is (mis-)interpreted as “it is not protection at all, so we should forget about it.”. However, in practice (which is often very different from academical research) – while it is indeed “security by obscurity”, it doesn’t mean that it is useless (after all, the whole multi-billion MOG industry relies on it – and manages to thrive).
  • In fact, according to the practically-observable-results (and to the logic above) – sure, there is no “once-and-for-all” solution to this problem. All we can hope for is to engage cheaters into an endless arms race – and this is exactly what we should aim to do.
    • Flash-back. As of 2005, the balance of the arms race between developers and cheaters was in favor of developers (at least those using C++ and having an idea about counter-cheating). As of 2017 – it is strongly skewed in favor of cheaters (at least for most of MOGs out there); however – adding certain MOG-specific tricks into our arsenal (which tricks will be described below) – this trend can be reversed for a while. Sure, then some new cheater will come and will find a way to break our improved defenses – but it still won’t mean that the battle is hopeless (as then we will be able to fight back at whatever-attack-he-comes-with).
  • Even in theory, there is a weak point when applying a generally-valid “given time, any Security-by-Obscurity can be broken” argument to MOGs; it is that we can deny giving attackers that time which they need to break us.⁷ We’ll see how it can be done, along the course of this chapter.
• Certain companies having vested interest in protection being breakable. I remember a talk on one of GDCs, where the whole point was “hey, you can do nothing to protect your game from almighty Chinese hackers, so you should pay our company – which has Connections within the Chinese Government – to protect your game”. No further comments.

What We Want to Achieve

Now, as I hopefully managed to convince you that what we’re going to do, makes sense <wink />, let’s try to state what we want to achieve with our Bot Fighting efforts:

• Increase attack costs.
  • In this regard, every bit counts. It has been discussed in Vol. I’s chapter on Cheating and Authoritative Servers, so just a brief recap of some related observations here:
    • “In lots of practically important cases, we don’t need to run faster than the bear (=”don’t need to be unbreakable”); instead, it is sufficient to run faster than the next guy (=”be better than our competition”).In lots of practically important cases, we don’t need to run faster than the bear (=”don’t need to be unbreakable”); instead, it is sufficient to run faster than the next guy (=”be better than our competition”). After all, lots of attackers are doing it for money, so when they run into a heavily guarded system – it makes perfect economical sense for them to stop wasting their time and move to the next easily-breakable target.
    • When we have multi-layer protection – attacker should spend lots of time while breaking all of them, and usually – without any cue whether whatever-he-has-already-done-makes-any-sense, making him much more likely to give up. It means that cumulative effects of multiple protections don’t just add up in a linear fashion, but that in this case the whole is greater than the sum of its parts.
    • Different layers of multi-layer protection are especially useful if they require different skillsets (which means that one single person is not likely to break all of them); if we achieved it – we already reduced chances of the attack to be mounted by orders of magnitude.
  • Economy of hack. If we can achieve that recurring costs on our side are much less than recurring costs on the attacker’s side – we won. For example, if we can ensure that on each weekly release, we can make hacker’s life more difficult at almost-zero cost to us – it qualifies as an extremely good thing protection-wise. The key here is to change things cheap and often on our side.
  • On the way of increasing attack costs, we have to be very aware of the Weakest-Link Principle. If we have an obvious heavily guarded entrance, it is quite easy to forget about that side kinda-backdoor-which-we-intended-for-testing-only and which stuck in our code forever.
    • One obvious example of the Weakest-Link Principle in action is to have a scripting language in our Client. Whatever we do to obfuscate/scramble our scripting code – itwill be revealed, and will be used against us (usually with devastating results).
      • It means that standard VMs to interpret our scripting language on the Client Side, are pretty bad for protection.
      • On the other hand, if scripting language is handled by a non-standard VM – it can be a plus protection-wise (better still, we can compile script into our own non-standard bytecode, and then use a non-standard bytecode-VM with byte codes changing on each release).
• Complicate collaboration between different hackers / hacker teams. Modern world tends to be highly specialized, and hacking world is no different. With a decent protection, is not that common that a single attacker breaks the whole thing. Rather, it usually goes as a series of minor breakthroughs. A typical attack scenario unfolds as follows (of course, for each specific attack phases involved will be different, but the fact that there are multiple phases, still stands most of the time): first, attacker A finds that we have our TLS certificate in our .exe XOR-ed with 0xAA; he can do nothing with this info himself – but publishes it. Second, attacker B, knowing it, mounts a self-MITM attack (discussed in [[TODO]] section below), and writes a tool which gets our under-TLS protocol exposed. Third, attacker C comes in and finds out a compression algo we’re using, exposing “bare” messages. Fourth, attacker D, armed with this information, manages to find out the format of our messages. And fifth, attacker E writes a proxy bot on top of all those things.
  • Our aim here is to complicate this kind of collaboration as much as possible. One way to do it, would be to change the-way-we-obfuscate-our-certificate, and the way we obfuscate our under-TLS protocol, for each release; in this way, information found by some hackers/teams, will become obsolete too soon to be useful for other hackers/teams. How to achieve it – is a separate question, which we’ll discuss in detail below.
• Our code MUST NOT be identified as malicious. In modern reality, we have to live with all the kinds of antivirus products (often of questionable quality) plaguing player’s computers. And the last thing we want to have on our hands, is if several of those AV products will start to identify our game Client as a malicious software.
  • “Avoiding being misidentified as malicious is not that trivial as it sounds – especially because LOTS of usual protection techniques are the same for both viruses and protectionsAvoiding being misidentified as malicious is not that trivial as it sounds – especially because LOTS of usual protection techniques are the same for both viruses and protections.⁸ This is especially true for protections involving OS-level protection, and/or code encryption. More on “how to avoid to become an AV false positive” in [[TODO]] section below.

On a more tactical level, we’ll try to achieve the following:

• No “single point of attack”. If we have a very complicated protection, but it can be disabled in one single point – such a protection will be broken sooner rather than later. This covers all those “code encryption” schemas which fall apart as soon as the key is extracted out of your Client.
  • Instead, what we want to have, is a multi-layer protection (known as “defense in depth” in security world), plus we want to spread it all over the code.
• Avoid relying on 3^rd-party run-of-the-mill protections. If there is a 3^rd-party protection, and it is not a custom one for your game only – it means that it is widely available. And the more protection is used – the juicier target it becomes, and more likely it will be broken. Another way to see it, is to observe that the more popular protection is – the higher reward/effort ratio it is for the hackers.
  • To make things worse, the vast majority (if not all) of the 3^rd-party protections can be disabled in one single point, going against “no ‘single point of attack’” rule above.
  • NB: I do NOT mean that “you MUST NOT use 3^rd party protections”; rather, what I mean is that “relying exclusively on a 3^rd-party protection is not a good idea”. As one of the protection mechanisms – 3^rd-party stuff may be ok, but IMNSHO if the 3^rd-party protection takes over 20% of your overall protection – you’re doing it wrong (as a rule of thumb, most of widely-known 3^rd-party protections are already broken, so disabling them is only a matter of running a ready-made script).
• Both code protection and data protection. This is one of those things where MOGs are quite different from anti-piracy solutions. For anti-piracy, the only asset they care about, is code.⁹ For MOGs, data protection is of paramount importance (in fact, as we’ll see a bit below, most – if not all – typical attack vectors rely on data being unprotected).
• Change things often at zero cost. As discussed above, ideally – we’d like to have our binary code to be changed in hundreds of different places on each release with zero source code changes. Apparently, it is possible to achieve (and we’ll see how it can be done, along the course of this Chapter).
• Keep our source code readable. Yes, I mean it – in spite of all the obfuscation we need, our source MUST remain readable. We just cannot afford to have obfuscated-C-contest in our source code.
  • It means that we should be obfuscating binary code while keeping our source code as-close-to-non-obfuscated-one as possible. As we’ll see below, with a few tricks it is not that difficult to achieve.

[[TODO: Obfuscating Open Source is Not an Oxymoron (build-time randomization, should work to mitigate cheating in open-source MOGs)]]

[[To Be Continued…

This concludes beta Chapter 29(a) from the upcoming book “Development and Deployment of Multiplayer Online Games (from social games to MMOFPS, with social games in between)”.

Stay tuned for Chapter 29(b), where we’ll start discussing more practical aspects of anti-reverse engineering protection]]

Don't like this post? Comment↯ below. You do?! Please share:

Acknowledgement

Cartoons by Sergey Gordeev from Gordeev Animation Graphics, Prague.