This post is the third part of my series on poker bots and their threat to online poker. If you’d like to be notified whenever I make a new post, please subscribe to the RSS feed or follow me on Twitter. (See the sidebar on the left.) In this post, we’ll look at detection methods poker sites use to detect bots, and the ways botters circumvent these. Some descriptions will be rather technical: feel free to skip over those parts.
The cat and mouse
Poker sites don’t accept bots. All sites have rules in their terms & conditions prohibiting the use of bots. Most sites actively attempt to enforce this, to some degree. In this part of the series, we’ll look at some ways the sites do this right now. I will not be speculating about ways sites can improve these measures, nor will this list be exhaustive. This is for several reasons:
- Public disclosure warns botters, so both existing unknown and new methods should not be published.
- I am currently in talks with one or more poker sites to work with them (together with Noah Stephens-Davidowitz) to help mitigate the bot problem. (As we publicly offered here.)
So, this article will talk about the current measures being taken by poker sites, and how they are generally bypassed by botters. If I mention something here, it is probably common knowledge among good botters – I won’t be teaching them anything new.
The strength of detection measures taken by poker sites differs greatly between poker sites. Botters have a general clue which poker sites take which measures, so they start their botting adventure on the least-protected sites. Once they are making money there, they can spend time working on more advanced anti-detection measures to expand to other sites.
Let’s look at some of the anti-botting measures I’ve seen over the years in this cat-and-mouse game. We can split these into two types of measures:
- Detection of the presence of the bot.
- Interference with the workings of the bot. (Coming in the next article)
There are several ways sites are attempting to detect running bots without actively interfering with them (e.g. popup windows asking “Are you a bot?”). The effectiveness varies. I’ll describe some of the most commonly used methods.
Detecting the program executable
Botters: Run a poker bot on the same computer as the poker client.
Back when there was no detection, one could simply run any poker bot on the same computer as the poker client.
Sites: Detect the process by name.
At first, sites simply scanned the list of running processes for known bots, like winholdem.exe.
Botters: Dynamically rename the executable.
Many poker bots that were sold publicly (like Winholdem) allow the user to change the name of the executable.
Sites: Detect the process by other properties.
Sites took other properties of the executable (its size), and scanned for those.
Botters: Use rootkit-like techniques to hide the process.
Windows keeps track of the running processes in something called an EPROCESS struct. This contains a doubly linked list of all the processes (.exe files) running on the system.
A linked list is a way of storing a bunch of objects, here references to running processes. Wikipedia has a simple explanation of linked lists, for the cool people. You can see such lists as chains, every link being an item of the list.
So, a poker site looks for illegal processes by going through this list one by one, comparing every process to its internal list of known evil processes. To circumvent this check, simply remove your link from the chain!
To do this, find this list in memory, and point the pointer that was pointing to the bot process to the next process. (Since it’s a doubly linked list, twice.) Now, the process will not be found using any usual methods, and the poker site will not be able to find and scan it. Interesting enough, the process will still run. This is because Windows internally doesn’t run processes, but it runs threads, which are part of processes.
For more information on this and similar material, see the excellent ”Rootkits: Subverting the Windows Kernel” by Hogland & Butler.
Sites: Use different ways of detecting the running executable.
If you go deep enough into the system, you will be able to detect the process no matter what. I do not know how deep most poker clients go. Absolute Poker used to use something called ”WinRing0” ((As far as I can see, winring0 used to be open-source, hosted on http://openlibsys.org/ – it’s no longer on there now.)) which is basically a kernel driver that allows the client kernel-level access to your PC for scanning for bots and such. I’ll write a short note about Absolute Poker’s security in some time.
Botters: Move the executable to a different pc.
If there’s nothing on the pc, the poker site will not detect anything. This can be achieved in several ways, of which the main two are:
Remote control software.
By using programs like RDP or VNC, one can control a computer over a network. The graphics are sent to the computer with the bot, the action is made remotely, and sent back using the RDP or VNC client. These programs might be used by regular players as well to play poker on their main PC, if they don’t have a poker client installed on the PC that they are on.
Virtualization allows a person to run one or more virtual (client) operating system on his (host) operating system. By running the poker client inside, and the poker bot outside a virtual machine, the poker bot can see and control the poker client, without the poker client being able to see any trace of the bot. Virtual machines are frequently used by normal poker players for several reasons, including:
Security: by doing everything in (different) virtual machines, your poker operating system will stay safe from trojans.
Operating system: a poker player might normally use a non-Windows operating system (like Linux or Mac OS X), and run their poker clients within a Windows-based virtual machine.
As you can see, both ways have legitimate uses, and both ways completely prevent poker sites from detecting the presence of the executable. At most, they can flag the account for using these techniques, and look into their play better.
Note that sites can only detect an executable if they know what to look for. This works for downloadable bots (which always have the same name and properties), but not for custom-made bots. In the case of custom-made bots, the most a site can do is look for tools that are commonly used for development of poker bots. This has happened
A few years back, a blog published a basic framework that could be used for botting. A few weeks later, people who had downloaded and opened that in Visual Studio (a programming environment) while PokerStars was running received an email from PokerStars, warning them that poker botting was against the rules. So, some poker sites go quite far to detect running programs: in this case, the program in question wasn’t even a working bot.
To be able to play, a bot needs to know what’s going on. There’s various ways of doing this. In the first article, we mentioned some of these. One included taking screenshots, and interpreting those. Other methods directly read the relevant data. This can be done in multiple ways, including:
- Intercepting the data by hooking Windows API functions.
- Requesting the data using the Windows API functions.
- Direct memory reading.
One way to get the current game state is to act as a proxy between the poker client and the operating system. For example, many sites write the dealer chat text to a box on the screen. To draw this on the screen, the poker client calls a Windows function, which does the actual drawing. Poker clients can intercept this (”hooking”), and get the text themselves.
Sites: Perform the drawing in another way, and/or attempt detect the hooks.
If you don’t call an external drawing function, there’s nothing there to intercept.
Botters: Use the Windows API to request the data from the poker client.
If the poker client shows the dealer chat, chances are that it’s done in a way so that poker bots can simply ask to receive a copy of that chat. How? Well, Windows has some nice features for us in store. On Windows, programs send messages to one another. One of these messages is WM_GETTEXT. The poker bot simply tells the poker client “WM_GETTEXT your chat box to my input” and the poker client complies, as most Windows programs will do.
Sites: Block the WM_GETTEXT message.
This is pretty easy to do, in low-level languages. The poker client will simply refuse to respond with the text from its dealer-chat box.
This leads to…
Botters: Directly read the memory of the poker client.
If the dealer chat is displayed, it’s also somewhere in the computer memory. If you know a few words of it, you can search the entire memory of the poker client for the rest. Implemented properly, this is hard to detect. (Especially because it can be done from outside a virtual machine.) This method is very difficult to implement reliably for anyone but advanced hackers.
In the end, the poker client has to know the game state to be able to display it to the user. So, poker bots will always be able to read it in some way. However, the existence of “dealer chat” in the chat box, displaying everything a bot needs to know, makes it way too easy to reliably subscribe to the game state.
Botters: When the AI makes a decision, the bot clicks the corresponding button.
When a bot needs to act, it usually has to click an action button to transmit its decision to the poker client. ((Unless it hooks into the client on a deeper level. )) The straightforward way of doing this is just clicking some predetermined position in the poker window when a decision has been made.
Sites: Analyze the position of mouse clicks on the action buttons, as well as the time it took to act.
Humans don’t always act quickly. They have to think longer about harder decisions, and there’s some variance here. Similarly, humans don’t always click the exact same position on a button. So, sites try to detect bots by looking at both of these things.
Botters: Randomize action timing, randomize mouse clicking location.
Botters now simulate humans moving the mouse, clicking the buttons with some human-looking distribution. They might even misclick from time to time.
A potential button-click position distribution. Lighter colors indicate regions that are clicked more frequently.
Players found bots on World Poker Exchange playing limit hold ‘em. These bots would instantly sit out when there were less than four players playing, and instantly sit back in when there were four or more. So, if you were the fourth player at a table, you could toggle the sit-out button, and the bot would instantly mirror your choice. ((This is a few years ago, so the details might be wrong.))
Similarly, WPEX had a bug where it was possible for one player (heads-up) to get the button every hand, by sitting out and back in. Players did this to bots for hundreds of hands at a time, and the bots would never notice.
Humans don’t play 24/7. Nor do they start and finish at exactly the same time every day. Some botters do (or did, until they were banned).
Sites: Keep track of when players play.
This data can be analyzed to see how human it looks. Good sites probably have automated scans doing this, flagging suspicious players.
Botters: Randomize session times, take breaks, etc.
Once again, this is a measure botters can circumvent.
I remember seeing bots that played sessions of exactly 8 hours (at NL100). After that, they’d leave the tables, and the next 8-hour shift began with different accounts. This was done with a total of 18 accounts (if I remember correctly, it’s been a while).
Botters: “Wow, we’ve got a winning bot! Let’s let it play on 16 accounts at once!”
If a bot can make $1,000/month on one account, it can make $16,000/month on 16 accounts, so why not scale up!
Sites (or, frequently, players): “Hey, there’s 16 identical players in these games!”
It’s pretty much impossible for 16 different people to play exactly the same style, so this is a dead give-away.
Botters: Make every account play slightly differently.
The poker community (e.g. poker players) has frequently found bots ((Or, as it turns out in some cases, groups of players who share one very specific style which they studied together.)) because it noticed a group of identical players playing in some games. For example, the recent supposed bots players found on OnGame were found in this way.
It’s interesting to note that botters have the last word in each of the above examples. However, all of these described detection methods are quite basic. There are more complex methods that can be used, but I will not talk about those here and now. The second part of this article will contain some techniques you probably didn’t know sites are using!
To stay informed, please follow me on Twitter, or subscribe to my RSS feed. If you like this series, please tweet about it, send it to friends, etc. The more people read it, the stronger the incentive for me to hurry up and continue writing.