Bot Fighting 104. Known Bots and Environment Scans.

	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(l) from “beta” Volume VIII”]

One technique which is used by quite a few gamedev teams out there, aims to identify known bots, and to get respective players banned. Let’s take a look at this class of techniques in more detail.

Motivation: Publicly Available Bots are The Biggest Threat

One reason

Indeed, one single bot writer writing a single bot will get his unfair advantage and will spoil game experience of a few other players; however, if the same bot writer publishes the very same bot (or starts selling it for a few bucks) – it will be used by thousands of wannabe-cheaters, increasing the negative effects on the honest players by orders of magnitude. In extreme cases, it is these publicly-available (or commercially-available) bots which will create a feeling that “cheating is rampant in such-and-such game”, which, in turn, can easily lead to the players starting to leave your game <very-sad-face />.

“That’s why most of multi-million-dollar games have a special team dealing specifically with public and semi-private botsThat’s why most of multi-million-dollar games have a special team dealing specifically with public and semi-private bots (more on the latter in [[TODO]] section below).

Arms Race

Fortunately enough, as soon as we’re dealing with a known bot – we’re playing on our home turf. For a detailed discussion of home-vs-road-games with regards to bots – see Vol. I’s chapter on Cheating, but very briefly – as soon as we have a known bot, the tables are turned, and basically we can use the-same-reverse-engineering-techniques which were used against our game Client, to dissect the bot and to disable its attack vectors.

On the other hand, as soon as we release our updated Client which disables bot’s attack vectors – the fight gets back to the attacker’s home turf, so they can dissect our defences, and release a new version of their bot.

Environment Scans

One popular (and surprisingly-still-working) way of detecting publicly available bots is based on scanning the environment-where-our-Client-is-running, looking for the artifacts typical for known publicly-available-bots. There are apparently lots of ways how the bot can reveal itself to such scans; this includes very naïve (but still working) things such as:

• Looking for window with a specific title (yes, there are bots out there for which it still does work)
• Looking for a specific registry key
• Looking for a file with a specific name
• etc. etc.

Signature Scanning

Going a bit further than naïve environment scanning mentioned above – it is possible to scan RAM-or-modules of the processes-running-on-the-same-box, looking for well-known signatures (which is BTW more-or-less what antiviruses do). Technically, this consists of two parts:

• Choosing which API to use to get access to the other process. On Windows, it is at least possible to use ReadProcessMemory() – or to use Toolhelp32 (either to heapwalk the snapshot, or to enumerate modules of the running processes, and to scan .exe/.dll files of those modules for the signatures). As for what-to-choose-for-this-purpose – doesn’t matter too much except for potential AV false positive, more on it in [[TODO]] section below).
• Rabin–Karp algorithm Rabin–Karp algorithm or Karp–Rabin algorithm is a string searching algorithm... that uses hashing to find any one of a set of pattern strings in a text.— Wikipedia —The second part of the puzzle is choosing an algorithm which scans large volumes of RAM-or-executables efficiently. This is a well-known field of academic research (usually referred to as “multi-pattern matching”), and I don’t want to go too deep into it, just mentioning that from what I know, for our not-really-AV-purposes, Rabin-Karp algorithm tends to work good enough.

Legality Issues

IANAL IANAL is a Usenet and chat abbreviation (initialism) for 'I am not a lawyer'. It may be used by non-lawyers who are seeking to avoid accusations of unauthorized practice of law and are not making any recommendation to the particular addressee of their remarks.— Wikipedia —There are claims out there that environment scanning (especially memory scanning) is illegal (see, for example, [Honorbuddy]). I have to emphasize that IANAL,

however, from whatever-accidental-knowledge-I-have, the legality of scans is rarely a problem in the real world: even if such scanning requires explicit consent from the player, such consent is usually requested in ToC-which-player-agrees-with, and as long as information-obtained-from-scanning is used only for the relevant purposes (such as ensuring game integrity) – it tends to be ok (however, once again – do NOT trust me, and make sure to ask your legal team about it).

The most widely-known case for such scanning is Blizzard Warden, which was claimed by EFF to be a spyware¹  – but caused no real trouble to Blizzard business whatsoever. Moreover, most of the non-cheating players did support Blizzard on it – see, for example, [Ward] (and there were reports that the-guy-who-complained-the-loudest, was a bot writer himself). BTW, I am not trying to judge whether doing scans is “right” or “wrong” in a theoretical sense² – but from my purely-practical perspective I can tell that by now, it is a standard accepted practice for MOGs – and is the one which, if implemented properly, tends to cause much less trouble than if not implemented at all.

“it might help to ensure that whatever-information-you-collect, DOES NOT leave the player’s box (except that tiny-bit-of-absolutely-relevant-information that “this player is running such-and-such-bot”)Also, it might help to ensure that whatever-information-you-collect, DOES NOT leave the player’s box (except that tiny-bit-of-absolutely-relevant-information that “this player is running such-and-such-bot”); BTW, enforcing such limitation is a really good idea even regardless of the potential legal issues (we do NOT want to get any sensitive information even accidentally; as we’re not Google – we might not be able to get away with a StreetView-like scandal). While it can be difficult to prove it to the community – it is still a Really Good Thing™ to ensure. Oh, BTW, as the discussion in [SchneierOnSecurity] indicates – there is a significant perceived concern about even sending hashes of the scanned data back to the Server-Side (opposed to sending just-result-of-the-comparison).

On Permissions and Services/Drivers

One thing which can easily limit our ability to scan things – is OS-level permissions; and even if currently your scanning does work from a non-admin account, as the time goes – I am sure that restrictions for scan-like operations are going to become more and more severe. One surefire way to deal with it is to install your own service (or even driver); however,

The reason for it is simple – at early stages of your game, asking to install a service (or even worse – driver³) will look suspicious to the player, reducing their desire to play (which can lead to catastrophic results early in the game life cycle); moreover – at early stages of your game you’re unlikely to need such drastic methods of dealing with cheats. It is when your game becomes a household word, you (a) may have a legitimate reason to use driver-based scanning, and (b) may be able to get away with it.

On AV False Positives

One danger with scanning-like techniques for our Client app is to be misidentified by some antivirus product as malware. The only way to learn about it – is to have a procedure of testing your Clients on boxes-with-different-AVs (and you should certainly perform such testing). As for ways to avoid such false positives – all the evidence in this field is very anecdotal, but there are a few potential hints (with absolutely no warranties of any kind):

• Looking-for-something-specific (such as FindWindow()) is generally safer than enumerating (such as EnumWindows()).
• Reading executables and DLLs is generally safer than scanning memory directly (so it might be better to use Toolhelp32 to get a list of modules for running processes, and to scan EXEs-and-DLLs-from-the-list for known signatures).

On VMs

If the bot is running in a VM host, while our game runs in a guest VM – all the scanning is hopeless to start with. Moreover, for certain game types, VM-based bots have become a standard more than a decade ago.

“Some games decide to prohibit running within VM outright. Personally – I doubt it is wise, preferring to report VM-being-used to the Server-Side, where a “red flag” is raised, which actually means such-players-using-VMs to be scrutinized more than the othersThe only thing which we could achieve in such case – is to detect the fact that our Client is  running within VM (more on it in [[TODO]]). Some games (such as LoL) decide to prohibit running within VM outright. Personally – I doubt it is wise (both because there are legitimate reasons for using VMs, and because giving an explicit feedback about protection is rarely a good thing), preferring to report VM-being-used to the Server-Side, where a “red flag” is raised, which actually means such-players-using-VMs to be scrutinized more than the others (and additional scrutiny may include using captchas, server-side stats analysis, comparing-game-patterns-when-playing-under-VM-and-without-it, human-reviews-when-such-players-reach-certain-level, and whatever-else-you-can-think-of).

On Obfuscation

One further thing which is going to get in a way of signature-based scanning, is publicly available obfuscation libraries such as ithare::obf⁴. While (as discussed in [[TODO]] section), such obfuscation techniques can be an invaluable tool to protect our Client executables from reverse engineering, it would be silly to assume that bot writers won’t use them too <sad-face />. In particular – nothing would prevent serious commercial cheating team from compiling randomly-obfuscated executable for each and every customer, which makes signature-based detection pretty much hopeless <sad-face />.

On the other hand, given the existence of VM-based bots, it is not expected to change the landscape too much; in addition – on the balance of pros and cons of obfuscation techniques, they will push the battle into more-professional field (with higher entrance barrier), where professional gamedev/protection teams should have an advantage in the long run.

Reverse Engineering Arms Race

As soon as the bot is smart enough to get out of sight during our environmental scan – we’re back to the good ol’ arms race between cheaters and bot fighters. Unfortunately, this reverse engineering arms race cannot be generalized (and moreover, whatever-is-written-about-it-in-public, loses its value almost immediately <sigh />⁵). Just a few very basic examples which fly surprisingly often (and which are already known well-enough so revealing them won’t be anything new for bot writers), range from simplistic stuff such as “hey, this guy clicks with a distribution of mouse clicks being too-evenly-distributed-around-certain-point and doesn’t change when we move this button by 5px (which can happen because we got a complaint about him cheating)”, and detecting grinding-bots playing 24/7 (you will be surprised of the numbers of bots doing this kind of stuff) all the way to things such as “hey, this bot tends to detect this kind of corner-case and reacts in exactly this manner – which is better-than-human-being-can-possibly-do, or is statistically impossible to have exactly the same reaction all the time”.

However, what is perfectly clear, is that all such fights are 100% down to the question

Most of the time, it is us (=”gamedevs”) who have more to lose in such a fight, so we tend to be more persistent. On the other hand, IF we slacked long enough to allow forming of a thriving-hacking-community-which-lives-from-selling-cheats – we have already increased the reasons for the cheaters to persist by many orders of magnitude (if selling-cheats is how-the-guy-pays-his-bills – he will be MUCH more persistent with breaking-our-additional-defenses than somebody who has just got his first $10 out of it). The point here is:

Mechanics of Anti-Public-Cheats Team. Procuring Cheats. Semi-Private Cheats

As noted above, quite a few serious games have their anti-publicly-available-cheating-teams. Mechanics of these teams are rather similar across the board and tend to include most of the items from the following list:

• Identifying a publicly available/commercial cheat. Usually done by monitoring relevant forums.
• Procuring it. Usually trivial, just make sure not to buy from your headquarter’s IP address <wink /> (though anonymized IPs are usually fine).
• Finding its signature and incorporating it into the Client’s signature detection.
• If necessary – reverse engineering it to find out its attack vectors and developing specific antidote.

“the-more-widely-spread-the-cheat-is – the more harm it causes for the game – but at the same time the easier it is to obtain <phew />One special case of such cheats – is semi-public/semi-private cheats. As cheaters have realized that for public/commercial cheats, the advantage is on gamedev’s side – they started to cover their tracks, offering the cheat only in private forums. This, in turn, means that identification/procurement subteam has to infiltrate such forums (which can be tricky and can require lots of time); however – let’s keep in mind that the-more-widely-spread-the-cheat-is – the more harm it causes for the game – but at the same time the easier it is to obtain <phew />.

[[To Be Continued…

This concludes beta Chapter 29(l) 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(m), where we’ll start discussion on dealing with ‘Ultimate Bots’]]

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

Acknowledgement

Cartoons by Sergey Gordeev from Gordeev Animation Graphics, Prague.