Recently David Titarenco presented the idea of a hardware anticheat device, focused on mouse input control of the player [1].
It is basically a black box (or should be, more on this later) with USB in+out and ethernet. The player plugs in his mouse into the device and another cable from the device into his computer.
The device also needs access to the internet, therefore a seperate ethernet interface.
The device then communicates with a anticheat server and reports the users mouse data (while also relaying the mouse signal to the computer), which in turn can be compared with the game servers input logs of the players viewangles.
In theory they should match up, but as the author notes, there are several issues with this. Talking about comparing mouse y-input graphs, the author notes:
Obviously, the two don’t “line up” perfectly and unfortunately, the two will never be isomorphic. Windows (and OSX/Linux) tends to provide various mouse features that consist of smoothing, acceleration, deceleration, interpolation, etc.
Finally he resorts to just logging the x and y directions for each time slice, for x or y being: -1, 0 or 1.
This interestingly has very important ramifications, i will talk about at the end.
So this promises to be an aimbot-detecting hardware-anticheat (not aiming to detect and/or prevent other non-input kind of hacks like Wallhacks or ESPs).
Let’s talk about some things.
Anticheat-concept: Input Control
Input control is not really a new idea, albeit not really used that much and not usually realized with hardware devices.
Demo analysis:
Demo-Analysers (like FPS-Death) check a recording for input plausability, for example perfect bunnyhopping timings.
It is also possible to detect certain kinds of silent aimbots or in general hack features where client/server angles are desynched on purpose or as a side-effect of the hack.
Demo analysis can of course be easily thwarted by keeping client recordings plausible.
Heuristic server plugins:
David also briefly touched on this in his article and called it „stochastic“ method to detect hacks.
The idea is – again – to check for plausible input and determine if reaction, precision, timing and „imperfect information based actions“ (like hitting someone behind a wall pretty often) are humanly possible. The biggest problem is to determine the tresholds. What reactions, precisions, timings and actions based on imperfect information are too implausible to be only human input?
This is not an easy question to answer – there might even be crossovers. Humans who cheat and keep being below the treshold and very good players who break the treshold.
This will possibly generate false positives and negatives.
Monitor-Drivers:
Monitor Drivers do just that – they monitor input directly as a HID filter driver and compare them with client or server data.
Davids device could in theory be completely modelled and implemented as a driver with an interesting advantage. It could weed out some of the adjustments to the mouse movement done by the operating system, being more comparable to the angle-differences the client engine processes and reports to the game server. It would also be thinkable to calculate in the engines mouse processing to match it even further.
The main disadvantage of course is the shifted attack surface, which David mainly had in mind. Cheat developers can more easily distribute only-software hacks and with lower prices.
David of course hopes that hardware manipulation or extra devices will be necessary to aimbot, costing the hacker knowledge, ressources and distribution problems.
On the other hand some well known anticheat drivers have a pretty good track record to show for and serious attacks have largely been just propaganda by payhack-sellers.
Blackbox requirements
The first thing that comes to mind: Can’t we just emulate that whole thing?
We just contact the anticheat-server ourselves with our hack and splice our aimbot-data to it, pretending it to be genuine mouse data.
And if the data/traffic is encrypted/encoded in a way we can’t inspect over sniffing the network, let’s just dump the software from the device and reverse engineer it. Afterall this is a user-friendly Arduino, isn’t it?
In the worst case we just fizzle out Flash or EEPROM and read it out on our own device.
Now these thoughts tell us something about the security implications and requirements such a project should have.
David briefly touches on this saying:
I need to implement HMAC (or a variation of it) to make sure that the device itself is tamper-proof
… which would be far from complete. Having a static HMAC secret is also very dangerous, making timing side-channel-attacks very easy. And once the static secret is recovered, it is game over. Harder – but not impossible – would be TLS with mutual authentication, having ephemeral session keys, even rolling out new keys on the fly maybe.
Cryptography-wise there is a lot to say and consider when developing devices the potential adversary comes in contact with. Which is the exact situation we have.
To not blow this blog post out of proportion, more on this here [2].
There is also pure operational security at play here. The device must defend its secrets also physically to prevent someone to just carefully solder out memory chips, reading out the contents in order to reverse engineer and remodel the entire device in software.
To counter this many agencies and the military (in case of stolen devices) use some sort of anti-tamper coating of crucial cryptograhic chips containing secrets [3].
Hardware – man in the middle
The most obvious point of failure of course is:
How can the device ever confirm that the device plugged in its USB slot is actually a real mouse? Maybe its another arduino plugged into the pc with the hack running, feeding fake input data.
Or it is a cable from a USB Device Controller controlled by the PC – and the software controlling the fake HID is the hack itself. The possibilities are almost endless.
David does acknowledge this in the comments and says that the goal of the device is to at least eliminate all aimbots solely based on software.
Restriced direction aimbot (aim assistance)
At the beginning we touched a bit on the fact that the input graphs (when comparing raw mouse input on the device and the server viewangle data) will not match up and have several error margins.
His solution is testing for correct X/Y directions per time-slice, with -1 moving in the negative X/Y direction, 1 moving in the positive X/Y direction and 0 not moving in that X/Y direction at all.
As a player we can be in the following situations with our mouse movement:
X: -1 (left) 1 (right) 0 (still)
Y: -1 (down) 1 (up) 0 (still)
X Y
====
-1 -1
-1 0 // neither moving up nor downwards
-1 1
0 -1 // neither moving right nor left
0 0 // mouse not moving at all
0 1 // neither moving right nor left
1 -1
1 0 // neither moving up nor downwards
1 1
Some movement pairs are really rare. Try to move your mouse in a straight line up/downwards or left/right without even going one pixel in the perpendicular direction. Try it in MS Paint: Do one straight line without using any tools and see if you can do it. 🙂
Being completely still (0,0) does happen more often, though. For the kind of aimbot presented here, this is slightly disadvantageous; just something to keep in mind or to at least compensate through readily move the mouse at the right moment.
So most of the time the mouse is moving in one of the following ways: left and down, left and up, right and down, right and up.
Being in a fight and trying to aim at an enemy, MOST of the time as a player, one starts to aim at least in the direction of the enemy player.
So if the head is left and above the crosshair, the first reaction is to move towards it, in this case (-1, 1: left and up).
The problem is: One overshoots the correct destination or stops to soon or changes direction in an unfavorable way. But the general aiming trend, the rough direction is indeed correct (-1,1).
This is where the aimbot kicks in. It locks the movement of the mouse with the speed and precise direction (more than just the trend) while the correct trend direction is being administred by the players real mouse.
If it so happens that the player moves his mouse in an unfavorable direction trend, the aimbot moves the mouse just as slow as possible in the wrong direction.
In a way (helping out the player keeping the trend of correctly aiming) works like aim assisting features mostly found in console games.
A picture to illustrate:
In conclusion and as it stands now (i know this is yet just a prototype):
– The basic idea of mouse input control and matching isn’t that revolutionary or new
– Davids claim that software aimbots are completely eliminated and ruled out with his device is untrue
– The problem of man-in-the-middling hardware can’t be realistically mitigated and stands as disadvantage
– Many cryptographic and physical security concerns are yet unadressed
– In some sense the same thing can be implemented (with better input-matching) with drivers and in combination with combatting other types of cheats (like wallhacks, ESPs)
– the costs (ressources, management, shipping) for the device may be disproportional to its real advantages
These are just my first thoughts. This article does not touch upon further operational questions that are important to handle (like intentional disruption of the network connection, also known as „fakelagging“ or or being able to update the devices firmware for the clients using it, while at the same time fully limiting access to the device for hackers) and the problems and hacking advantages that come with these problems.
Seeing that this project is barely in a workable phase, i’ll leave it at that and maybe follow up on this when things have developed more.
Also: This article provides some critical thoughts possible investors should consider before putting money into this project.
[5/2/2015] Update: Another good analysis of the device:
http://www.reddit.com/r/GlobalOffensive/comments/34l05k/im_emozilla_long_time_developer_and_member_of_the/
[1] http://dvt.name/2015/finishing-what-intel-started-building-the-first-hardware-anti-cheat/
[2] https://www.era.lib.ed.ac.uk/bitstream/handle/1842/860/Spadavecchia_thesis.pdf
[3] https://siliconpr0n.org/wiki/doku.php?id=physical_protection
#debuglog 