# Finishing what Intel started — Building an Arduino-powered anti-cheat

In 2007, during Research@Intel Day, an interesting tech demo took place; but in spite of the project being featured prominently in the media, users throwing money at their screens, and the concept being genuinely fascinating, it never came to fruition. Maybe it was the right idea at the wrong time. Maybe Intel didn’t pour enough man-power into it. Maybe it was the economy on the down-swing. Who knows. But it unquestionably fizzled out of existence…

What was it? A hardware-based anti-cheat system dubbed “Fair Online Gaming” developed by Intel engineers Travis Schluessler and Daniel Pohl, pictured to the right. At the time, I only found out about it because I was working in the same domain: the Cyberathlete Amateur League had begun prototyping their client-side anti-cheat and I helped develop the first incarnation of the CAL-AC alongside Wim Barelds (one of the creators of zBlock) and Andres “misty” Gunaratne (now with Fantasy Esports). The CPL was acquired by WoLong Ventures and CAL went along with it. Professional and casual gamers alike left CAL for ESEA, CEVO, and the ESL. After a not-too-shabby career, I decided to quit gaming and go back to school. The story doesn’t end there, but let’s rewind a little. How does an anti-cheat like Intel’s FOG work, and, more importantly, why do we need a hardware anti-cheat?

## Software Sucks

It’s not fair to accuse Intel of completely dropping the ball here. After all, FOG was, in some ways, a vision of the future that got many things right (and a few wrong, but more on that later). First of all, it was a hardware-based anti-cheat solution. Software ACs rely on a few methods of detecting whether or not a player is cheating and most of these methods are, unfortunately, quite easily beatable. Let’s look at a couple.

### Signature-based detection

Signature-based detection (SBD) is a relatively simple method of virus or cheat detection. SBD begins when a change is noticed either on (a) the file system (e.g. a new file is downloaded from the internet) or (b) in user-space memory. Suppose we have a large database of known cheats. This database consists of some identifiable “fingerprint” that the cheat possesses when either on disk or in memory. For example, given the following database:

Cheat name Fingerprint
SuperWallhack 0xAH 0x44 0x32
Aimbot2000 0x00 0x04 0xFF
...

And given the following memory layout (note the highlighted sections):

...
0x33
0xF0
0x00
0x04
0xFF
0x58
0x33
0xF0
0x58
0x47
...


We can conclude that the player is aimbotting. To do this search, variations of Boyer-Moore are used; often times in conjunction with suffix trees or suffix arrays. As long as the fingerprint is long- and unique-enough, collisions should be a rare happenstance.

The drawback of SBD is, unsurprisingly, that it requires a database. For a virus to be detected, it must have already been detected (or, at the very least, isolated) in the past. This is not only problematic for anti-virus software, but exponentially more problematic for anti-cheat software. Consider a private cheat that is sold through various grey markets online. The “benefit” of a virus is that it behaves unruly: no computer user wants a virus on their PC. This means that whenever a PC is infected with an “under the radar” virus, it quickly becomes quarantined and recorded in an AV database. This is not the case with cheats. Players that want to cheat have an interest in keeping their cheats private (lest they get caught). Therefore, it is virtually impossible for any SBD-like methods to catch them.

Furthermore, SBD has another drawback. Consider cheats or viruses that are non-static in nature; that is, use self-modifying code (e.g. are polymorphic or metamorphic in nature), or download encrypted parts of their own source code over the internet. Catching viruses with SBD methods might be a first step, but as far as cheats are concerned, the method seems untenable from the get-go.

So, in conclusion:

• False positives? None, given a large-enough key. Collisions should realistically never happen.
• False negatives? Many. Almost all purchasable cheats will not be caught as they update fairly regularly.
• How to beat? If you’re writing a cheat yourself, don’t release the source code. If you do release the code, make it polymorphic or metamorphic.

### Monitoring API Calls

Monitoring API calls is a more heuristic approach used by anti-cheat software. A cheat may hook into, say, a rendering function with code that looks like the following (this code uses the Microsoft Detours library and assumes a double F(double) function signature):

#define ADDRESS 0xDEADB33F					// this is the address where our targeted function begins
double (__cdecl* originalFunction)(double);	// pointer to the function we are going to hook, must be declared same as original

// modified function code that is going to be executed before continuing to the code of original function
double hookedFunction(double a) {
std::cout << "original function: argument = "<< a << std::endl; // we can access arguments passed to original function
a = 42;															// modify arguments
return originalFunction(a);										// before returning to normal execution of function
}

BOOL APIENTRY DllMain(HANDLE hModule, DWORD dwReason, LPVOID lpReserved) {
switch (dwReason) {
case DLL_PROCESS_ATTACH:
// magic
break;
}
return TRUE;
}


To prevent such hooking, anti-cheat software may implement a white-list and monitor OS API calls like DetourFunction, LoadLibrary, CreateRemoteThread, and WriteProcessMemory. After all, some applications that hook into games are not malicious. Consider Fraps, the Mumble overlay, OBS, etc. If an application is not white-listed, bad things happen. Case in point: ENB series — a shader beautifier — was ban-worthy for several months. Hundreds of Dark Souls II players were unjustly banned on Steam when using a DLL proxy instead of the vanilla DirectX.

More advanced methods, e.g. virtual method table hooking, are still undetected (and will most likely always be undetected). Hooking vtables is difficult, but not impossible. The most difficult part is finding the method offsets (which often change from update to update). Since VAC3 has implemented some modules that may prevent internal vtable hooking (via sanity checks), this has not stopped cheaters from vtable hooking third-party libraries like Direct3D, OpenGL, and DirectInput. Here’s a code snippet that does just that:

class CGame;
class cVMT;
class cD3D;

class CGame {
public:
cVMT* pVMT; //0x0000

};//Size=0x0004

class cVMT {
public:
DWORD pD3D; //0x0000

};//Size=0x0004

typedef HRESULT(WINAPI* tEndScene)(LPDIRECT3DDEVICE9 pDevice);
tEndScene pEndScene;

HRESULT WINAPI hkEndScene(LPDIRECT3DDEVICE9 pDevice) {
MessageBox(0, L"Hello world from EndScene", 0, MB_OK);
return pEndScene(pDevice);
}

DWORD_PTR dwEndScene = NULL;

while (pGame != NULL) {
pEndScene = (HRESULT(WINAPI*)(LPDIRECT3DDEVICE9 pDevice)) *(DWORD_PTR*)(pGame->pVMT->pD3D + 0xA8);

VirtualProtect((LPVOID)(pGame->pVMT->pD3D + 0xA8), sizeof(DWORD_PTR), PAGE_EXECUTE_READWRITE, &dwEndScene);

while (TRUE) {
*(DWORD_PTR*)(pGame->pVMT->pD3D + 0xA8) = (DWORD_PTR)hkEndScene;
}

VirtualProtect((LPVOID)(pGame->pVMT->pD3D + 0xA8), sizeof(DWORD_PTR), dwEndScene, &dwEndScene);
}
return 0;
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) {
if (fdwReason == DLL_PROCESS_ATTACH) {
}
return TRUE;
}


0xA8 happens to be the magic number here — it’s the offset for IDirect3DDevice9::EndScene, so anything we draw will be drawn on top of the current frame. An AC could monitor VirtualProtect or CreateThread, but a lot of legitimate code use these. Not only that, but there are many ways to cleverly get around using them. Often times, for example, cheat writers use undocumented features of an OS. It goes without saying that as cheats bury themselves in ring1 and ring0, they become virtually impossible to catch by non-invasive methods. So how does API monitoring look?

• False positives? Assuming a perfect whitelist, none. Real-life cases show otherwise. Carrying heavy penalties can hurt innocent people and going back on a ban can hurt credibility.
• False negatives? Many. Most purchasable cheats don’t rely on naive injection methods.
• How to beat?
1. Don’t write memory in the game’s space
2. Don’t use obvious hooking methods
3. Do run it in ring0

### Stochastic Methods

And finally, we have stochastic methods. Stochastic methods of anti-cheat detection are based on past behavior and a well-defined probabilistic model. Even though these kinds of methods often catch the most disruptive of players, it would be a grave mistake to rely solely on a probabilistic model. Consider, for example, the following video:

The 15%-20% aim enhancement shown in the video can hardly be noticed by a human viewer, let alone be considered an outlier in a probabilistic model. This is how GameBlocks’ FairFight works — a popular XBOX anti-cheat tool. According to the company,

Fairfight uses two overlapping and mutually supportive approaches to identify cheaters: algorithmic analysis of player statistics and server-side cheat detection. FairFight uses algorithmic models to evaluate gameplay against multiple statistical markers to identify cheating as it occurs. FairFight crosschecks these indicators using objective server-side reporting tools. It takes action when both approaches correlate to cheating — and because you establish FairFight’s tolerances and the in-game actions to be taken against the hacker, you are in control of your game like never before. Learn more about integrating FairFight Into your game today.

Unfortunately, a tightly-tuned cheat could never be caught. In some cases, simply using SBD would be more advantageous than a purely stochastic method.

• False positives? Depends on the tolerance.
• False negatives? Depends on the tolerance.
• How to beat? Make sure your cheat’s behavior is not an outlier.

## Hardware Rocks

But let’s get back to Intel’s FOG. Here’s how it was supposed to work:

The fundamental premise behind the Fair Online Gaming technology research is that platform hardware can help detect cheating in online games. If this technology makes its way into PCs, gamers who want to play without cheaters can choose to turn it on and play with other gamers that also turn the technology on in their systems. The Fair Online Gaming technology itself is a collection of hardware, firmware and game software running on client PCs and servers. In our labs, we’ve tested the concept’s effectiveness at detecting entire classes of cheating, not just specific cheats.

I previously mentioned that Intel made a few mistakes, so here they are. First of all, making a vendor-specific anti-cheat creates a rift in the gaming community. Some gamers are diehard AMD fans, others Intel; some nVidia, some ATI, and so on. A cursory glance at the diverse demographic will yield the fact that a hardware anti-cheat would have to be vendor-agnostic. Second of all, Intel’s Fair Online Gaming was (when developed) using Intel’s “Active Management Technology” feature. A major part of AMT is the programmable (read: flashable) firmware. A hardware solution should not be bound by any PC-specific software constraints. It should work out of the box without any client-side software, lest we open the can of worms that is client-side anti-cheat. In short, what we should have is something like this:

### The Prototype

What would this device look like? Could I actually build it? Before I did any development, I quickly scribbled down some notes; it had to meet the following requirements:

• Price: somewhere between 30 and 100 dollars
• Size: portable
• Ports: USB in, USB out, Ethernet out
• Input latency: < 1ms

Just a few months ago, I knew very little about Arduino, but I started doing some research. I wasn’t sure what the hardware platform would be and I was skeptical about reaching a sub-1ms latency, but I was absolutely sure that I could do some kind of “USB passthrough”. Ironically, what I thought would be tough to do ended up being trivial and what I thought would be trivial ended up being difficult. I settled on the Arduino Mega ADK (which has a host USB shield embedded) and an Ethernet shield. What followed was relatively painless. I used the USB_Host_Shield_20 library to grab mouse states from a Razer mouse I connected to my Mega ADK board. Using the OnMouseMove callback, I was getting a stream of dx and dy values. About 2000 lines of code later, I had an almost-fully-functioning prototype, temporarily dubbed “Valkyrie” . Here’s the class definition:

class Valkyrie : public UniversalReportParser {
public:
void Setup();
void Loop();
protected:
virtual void Parse(HID *hid, bool is_rpt_id, uint8_t len, uint8_t *buf);
private:
// C++ is so fucking stupid
static void Heartbeat();
HIDMouseReport *in;
HIDMouseReport out;
EthernetClient client;
Timer timer;
};

#endif // VALKYRIE_H_INCLUDED


There’s nothing too fancy about it, just a lot of housekeeping. It was basically a fancy USB HID pass-through:

void Valkyrie::Parse(HID *hid, bool is_rpt_id, uint8_t len, uint8_t *buf) {
in = (HIDMouseReport *) buf;

// in/out transaction
out.dx      = in->dx;
out.dy      = in->dy;
out.buttons = in->buttons;
out.wheel   = in->wheel;
out.i0      = in->i0;
out.i1      = in->i1;
out.i2      = in->i2;
out.i3      = in->i3;

// send packet to AVR controller
Serial.write((uint8_t *) &out, SMALL);
// ... and to AC server
client.sendData(String(out.dx) + " " + String(out.dy));
}


The real magic happens in the LUFA-powered firmware that enables the Arduino to be “seen” as an HID device (specifically a mouse). Some still-pending issues are making the mouse wheel work and making mouse buttons 4 and 5 work. Here’s a picture of the real thing:

### Testing Counter-Strike: Global Offensive

To test the prototype, I wrote a small server-plugin for CSGO that relays player view angles back to a local server (this would be the anti-cheat server in the diagram above):

public Action:OnPlayerRunCmd(client, &buttons, &impulse, Float:vel[3], Float:angles[3], &weapon, &subtype, &cmdnum, &tickcount, &seed, mouse[2]) {
if (prev_x[client] != angles[0] || prev_y[client] != angles[1]) {
new data[128];
Format(data, 127, "%f:%f::%f:%f", angles[0], angles[1], prev_x[client], prev_y[client] );
prev_x[client] = angles[0];
prev_y[client] = angles[1];
SocketSend(socket, data);
}
}


As soon as I started getting data from both the Arduino as well as the game server, I had a realization: “holy crap, this is working.” First if all, I could catch triggerbots with 100% accuracy. This alone has amazing ramifications. Triggerbots don’t only affect first person shooters like CS and the Battlefield series, but they can be generalized to DOTA2 and League of Legends where new “instant click” or “instant ability” cheats have started cropping up — cheats that simulate either mouse button presses or keyboard presses.

The data started pouring in and I started graphing it. For example, here’s the y-axis movement of the mouse (straight from the optical sensor) alongside the angle movement in-game — both are given in differentials.

Obviously, the two don’t “line up” perfectly and nfortunately, the two will never be isomorphic. Windows (and OSX/Linux) tends to provide various mouse features that consist of smoothing, acceleration, deceleration, interpolation, etc. Furthermore, the “raw” graph tends to be noisier. This is due to the fact that mice can fire new events up to 1000 times a second, whereas Counter-Strike’s best tick rate is about 128 ticks/second. One way of “tightening” the data is to simply look at whether or not the mouse is moving in a positive or negative (x or y) direction ignoring the actual distance the mouse moved. Given this constraint (1 = moving up, -1 = moving down, 0 = stationary), we have this:

Why this graph is interesting is that we clearly see the causal relationship between the Arduino data (in red; fresh from the mouse) and the game data (in blue). When this causal relationship breaks, the player is cheating. The test? A resounding success.

## Conclusions & Future Developments

So what are the next steps and what did I learn? Well first of all, I learned that Intel has really good ideas — FOG seemed awesome 8 years ago and building my own version of it is both humbling as well as exhilarating. I also learned that the Arduino community is the absolute best. The amount of help and resources that are out there is beyond staggering. I didn’t pick the easiest “first hardware project ever” but I couldn’t’ve done it without the code-base and tutorials that are already out there.

What are the next steps? Well, I need to brush up on some signal processing and figure out a good way of weeding out the aimbotters from the non-aimbotters, I need to implement HMAC (or a variation of it) to make sure that the device itself is tamper-proof, I need to fix some bugs in the firmware that are screwing up overflow bits in the HID report, and I need to also make sure that buttons 3, 4, and 5 work on every mouse I hook up to the Arduino.

And even though I’ve been away from gaming for a while now, I also learned that this may be the device the gaming community needs right now. Among cheating allegations at the highest levels in CS:GO, as well as new cheats coming out for mainstream games like DOTA2 and League of Legends — not to mention the fact that the cheating industry is growing at a ridiculous pace — it’s becoming clear that something needs to be done. Who knows, maybe there’s a Kickstarter on the horizon…

### 64 comments on “Finishing what Intel started — Building an Arduino-powered anti-cheat”

1. Kelly Clayborne says:

What about hacks that are firmware based in mice? It seems like your device would have a difficult time detecting those because wouldn’t the signals from the mouse be fraudulent?

1. PhiloteSplitter says:

I’m no expert, but I believe the mouse itself does very little processing, and a cheat would not be able to run within it. My guess is the mouse simply installs the cheat along with its own driver for the computer to run.

1. $moke$ome\'eed says:

This is correct.

2. Dykam says:

It’s actually not entirely out of the realm of possibilities, but it would be extremely involved.

2. Kierany9 says:

This is a really nice prototype. There are some people using controllers(Pretty much nobody) and +left/+right commands(A few more people) for mouse movment, however.

3. xkreative says:

I need to say, i love the idea and i think we need this in professional esport, but there are already 2 problems.

1. Network sniffers, for example the csgo cheat netshark by DeepBlueSea already bypasses your decice. Netshark reads csgo packets and finds players position to draw them on an external device(in this case on pc, but for example organner uses an android phone).

2. Hardware hacks, for years there are already concepts of hardware cheats, which could be put between your device and the mouse. For example in windows xp you were able to exploit so you can read ram of another device trough firewire(correct me if im wrong). In that case you already get the modified data. This concept isnt usable on lan tho

And 3rd i think people could exploit the anticheat by putting usb hubs in it messing the data up.
Anyways good concept, needs to be released for esport 😀

1. cho says:

I don’t think you know what you’re talking about.

1. xkreative says:

How do you think so?

2. HI BILLY MAYS HERE says:

shut up faggot.

1. xkreative says:

Why you call me faggot? I just stated out, that there are stil ways to cheat. The project is a great idea, why you hate? xD

1. hansi says:

Shut up fag

1. kaka says:

STFU FAG

3. niggernigga says:

You have no idea what you are talking about, nigga. Anything bypassing the device would still mean you get a DIFFERENT DATASET from Hardware-AC to Game, because THE CHANGE NEEDS TO HAPPEN BETWEEN YOUR INPUT AND THE GAME and the difference IS DETECTABLE.

No amount of hacking can make the AntiCheat Hardware detect the same movement data as the game if the movement is altered in any way between game and AC Hardware..

1. xkreative says:

First im not ur nigga, second im not sure if you just troll. The hardware hack is a device like the anticheat device, which is just manipulating input instead of reading out the input. You put this device between the mouse and the anticheat device. The anticheat device has the same info as the game and you dont get banned. Just you have no creativity to bypass such things, there is still a way.

4. Dykam says:

1. Walls’s etc are not detectable by this, but they already are effectively impossible on LAN since, you know, what you see the lan organizer can see

1. xkreative says:

Im aware of that, netshark was one example that this does not ban all cheats that can be used in leagues. If you look at the organner hardware hack sold 20 times for 800€ there still exists this issue on lan. It works the same way as netshark, but has a built in lan mode, which makes your android smartphone(its an app on your phone without any data on pc) vibrate when an enemy is in your set up range/crosshair range. So you dont see the visual, but you “feel” when the enemy is around the corner. Not accusing anyone, but with that cheat you could check walls without wallhack like the flusha videos and no one would notice without phone check.

1. Zack says:

Netshark is not a thing anymore after valve implemented PKI Infrastructure on their servers.

1. xkreative says:

Netshark is still working with an exe on the gaming pc to read out the needed key. Not released to public, but still possible.

Pki infrastructure is only used on official valve servers= netshark still works in leagues.

5. dtitarenco says:

Hi! Thanks for your post. Just wanted to mention a few things.

1: The device (in its current incarnation) has no way of preventing wall-hacks or ESP-style cheats. As the article mentions, this vulnerability lies squarely on developers.
2. The goal of this device is twofold: (a) eliminate all software cheats in online games and (b) eliminate 100% of cheats in LAN events. Both goals are attainable and the prototype is a testament to that.
3. USB hubs don’t mess anything up. The technical details are a bit complex, but you could even (theoretically) feed both a mouse and a keyboard through the anti-cheat and be able to differentiate between them (and map the data appropriately). This is after some software grunt work, of course.

4. Q says:

It really seems like a good idea, but dosnt the audroino mess up the mouse’s special firmware. I for one have specific settings for each game I play directly via logitechs software, but that only works with logitechs products and the way this works is it on the pc side makes it look like a generic mouse right?

1. Dykam says:

Yes, definitely. But AFAIK in tournaments you can’t install custom software anyway, besides possibly drivers. Most mouses like that do store their profile in the mouse itself. You just can’t switch on the fly.

5. 11214888 says:

Does it cause any increase in input lag on the mouse?

1. niggernigga says:

The author wrote the added input differential is <1ms, so it should not matter even in the tightest clutch situations, as that is the possible difference even between two mice of the same product line.

6. yolojim says:

What about mice with more than 5 buttons?
Think this technique would mess up the mouse driver

7. Will Tange says:

I don’t understand what would stop me from implementing this in software (and subsequently exploiting said software). Two ethernet ports – one for CS/other data and one for a Valkyrie emulator. Sure the devices are DRM’d, but we all know how that tends to pan out. One of the strengths of software anti-cheat is the fact that it can be updated on a whim.

8. Lloyd Davis says:

best thing I’ve read all week

9. DeepBlueSea says:

Nice post.
Input monitoring as an idea and concept has already been around in the gamehacking community for some time, though not as extra hardware but as input drivers. It was never implemented.
There are only some passive approaches via demo analysis i can think of.

However: It suffers – as already stated by a commentator and hinted upon in the article – from the basic fact that the cheater controls his environment: Man-in-the-middling input devices.

Even if you blackbox the device,use military-grade anti-tamper coating on the hardware, encrypt the heartbeat with TLS and secrets from the coated chips, how could you ever confirm that the device plugged in is just a regular mouse?

10. NASTY says:

The kid who’s video is linked here is Jon Summartano – http://pastebin.com/L281uX1Q He told me to make sure you credit the video under his name. If his account gets hacked and somehow removes the video let me know so i can upload a backup for “Educational Purposes”

11. rokk says:

I believe something like this could (and should) completely be relevant to any major and seriously taken e-sport.

12. Yeah says:

So many attack vectors I wonder why you’re even bothering to spend the time on this. Such a wasted effort.

13. bob102938 says:

You had my curiosity, but nothing is stopping me from getting another Arduino and hooking it up to your box and emulating a mouse via USB.

http://arduino.cc/en/Reference/MouseKeyboard

If you can figure out how to validate (probably via machine learning/statistical analysis of input patterns across a large user base) that the attached mouse is the real thing, then you would have my attention.

The best solution in my opinion is to market a mouse product to customers or a security module to manufacturers that contains a public key in its firmware that encrypts+timestamps+compresses all mouse movements/actions and sends them up a separate data channel to the system. At this point you could send the mouse data to a validation server that decrypts and checks against the game server’s data. The mouse would obviously have to be hardened to the extent that it would “self destruct” the security nvram/asic upon tampering. Obviously you would have to contend with the existing mouse market (or partner with manufacturers), and it would heavily compromise customizability in favor of maintaining strict security.

14. Pascal says:

As a CS:GO-Player I hope this tool will have a future. Best of luck for you and you project, quite a nice idea.

15. Anubis_9292 says:

You should really rethink the practical usage of such a device. So, official tournaments where I play from home? The following steps to subvert this box:

Buy a PS/2 USB adapter cable. Write a basic listening server in preferred language of choice (Delphi) to hook into USB port, use a modified kernel driver to allow this server to masquerade as PS/2 compatible mouse. Plug in cable to game:ref device. Calls made to local server will now reach the box, to all intents and purposes, as if a human had made them legitimately.

Any existing cheats simply pass mouse signals to the local server which then fires them off to PS/2, can be done very easily by exporting server interfaces as a DLL and injecting resulting DLL into game as required.

You will find that the only way to prevent this very easy complete bypass (the “anticheat server” doesn’t even come into this whatsoever because the human-mouse link is the weakest most vulnerable part of the chain) is to use specialised mouse hardware and utilise cryptograpic authentication of data to ensure it is not tampered with. I do not think you have thought about this at all yet, article implies you can plug and play any mouse.

Ultimately because of this flaw, your hardware solution whilst a good gimmick, will not work. Companies would only buy into this if it improved upon the software alternatives significantly, the only available sector here is a 100% rate of cheat prevention.

Eliminate cheats in online multiplayer games? Bypassed.
Eliminate cheats in LAN tournaments? Feasible… a USB PS/2 adapter would give the game away. By this token, your solution is on the same level as going around each computer manually and checking for obvious cheats, defeating the purpose I believe.