Moss macro check
All along the session , Moss checks keys and mouse events , and their relative timing. At the end it analyses the data collected and eventually presents graphs with some sequences which need to be clarified.

If there is no graph , there is no suspicion on macro side.

What is a “macro” ?

It’s a sequence of keys (including mouse clicks) handled by an automation system and triggered by a single action , it can be achieved for a single key ( click click to bypass recoil system) or different keys (space C  to bunny). It can be done for just 2 events or more.

Moss doesn’t care which actual key is pressed but only of the result seen by system and by the game, neither Moss doesn’t consider the program which generates the macros, Thus Moss can spot software or hardware macros.

If a set of events is considered as significative enough (sorry I wont detail which and why), Moss stores it to build the graph.

Of course, the same events in a macro can be achieved by legit players but with some differences :

• No player is able to double click faster than 80ms on a regular basis, by regular basis I mean the delay beetween clicks is always more or less 80ms (let’s say with 10% tolerance)
• No player is able to double press a key faster than 100ms on a regular basis
• A player is able to press 2 close key simultaneously with a single finger but if he presses QW at the same time , he will press WQ too time to time, even more if he needs 2 fingers.

Reading the graph

A graph doesn’t mean a player used a macro , to confirm it’s a macro you have to eliminate legit events. a pic a 5 events and dispatched from 0 to 140 ms is not a macro but someone pressing both key more or less  simultaneously.

To have a simple rule : the bigger and the sharper is the pic on graph, the higher is the macro suspicion.

note : some devices uses a polling rate of 125Hz, so events will be dispatched with a minimum interval of 8 ms (1000/125) , it’s a clear disadvantage for the player but it may hide a macro anyway as you have to consider a set of 8ms as a single sample.

Macro sample

4143 keystroke, 15 Patterns found
=> the player hit 4143 keys during the session , and there are 15 keys or mouse buttons combinations encountered.
of course only some will be displayed if potentially macros

below some macro or look like macros :

https://pastebin.com/raw/DSyJ2BHP
=> the player used 324 times C C , the quantity is large, the delay beetween keys stroke is always more or less 8 ms , it’s a macro

No recoil Macro (mouse moves down graph)

another kind a macro spotted is no rec macro , where the mouse is automatically moved to compensate guns recoil , here is a sample of such a macro :

a no rec macro is created this way  : bound to fire ( usually left click ), the macro send a command to move down the mouse to counter balance the recoil generated by the game, usually it’s done game by game and gun by gun.

the macro may send a single pixel move repeated many times or the whole move at once, depending the event rate it will appears as huge peak of hundreds of 1 or 2 pxs moves or a smaller ones with higher px values.

Aimbot ( fast mouse moves graphs)

this graphs tracks mouse speed events, a player move his mouse from 0 to 800 px/s , an aimbot moves a mouse (seen by the game) at an infinite speed. 

however to avoid to kill the pc , Moss does the measure at a moderate frequency but fast enough to see aimbots moves as more than 1000 px/s events.

Keep in mind it’s humanly possible to move a mouse at this kind of speed but not in game conditions.

 

more samples can be found in forum…

if you still have doubt , share the log on twitter or on this forum …