While video games are always more sophisticated, a merciless battle is played in the shadows: that of developers against cheaters. And it is thanks to a recent and particularly detailed analysis of ssnothat we will be able to dive into the bowels of modern anti-triche systems.

Let’s start with the base of one of these protections: Arxan. This Obfuscation system acts as a first line of defense in many Call of Duty games since Black Ops 3. Its role is to make life impossible for retro-design engineers and cheating software developers.

Note that Arxan is not content to blur the code: it also monitors the Windows environment, just to identify for example if the system is in Fashion test (a feature that allows you to load unique drivers). This verification involves in particular NtQuerySystemInformation To see if the signing of the pilots is forced or not. All that to say that, if Windows is started in test mode, you expose yourself to a flag from the game servers.

For this, Arxan uses different protection techniques:

  • Dynamic encryption : The executable of the game is encrypted and deciphered on the fly during its execution
  • Integrity checks : Continuous checks to detect any modification of the code
  • Obfuscation of jumps : The functions are fragmented and dispersed with jumping instructions
  • Entry protection : The entry point of the program is masked and protected
  • Pointers encryption : Critical memory addresses are dynamically encrypted

Coldwar

But the real innovation lies in the baptized system Tac (Treyarch Anti-Cheat). This solution fits directly into the executable of the game and implements particularly clever detection techniques.

Tac tracks attempts to analyze the game by monitoring the API hooks with recognition of known signatures, debuggers via various mechanisms such as threadhidefromdebugger but also all that is overlays which could be used to display cheat menus or Debug consoles unauthorized.

Besides, he has a few tricks to flush out the too “coarse” hooks: tac can voluntarily call NtSetInformationThread With phony settings and check that the function returns the expected error. If it ever answers OK when it shouldn’t be, it’s a bad bad hook has been there!

Now, to counter the injection of malicious code, TAC uses several strategies that are all detailed here in the source. It is quite technical but, you will see, one of the most sophisticated features of TAC is its encrypted system call system. Instead of borrowing classic Windows functions (via ntdll.dll for example), TAC will search the system memory elsewhere to find an instruction there syscall And build a custom “stub”. This stub is then masked (xor, encrypted, etc.) and placed in a random place. Suddenly, attempts to monitor system calls are much more difficult, because you never know which API is really invoked and where the instruction is syscall !

As a bonus, TAC also blocks the Signature Scanning By creating code blocks made inaccessible (PAGE_NOACCESS) at the right time. As these are “dead” code zones which should not be traveled, any scan tool that would pass on it would take a good old crash. It seriously complicates the life of cheaters who are looking for memory patterns to patcher.

Tac monitors even more things: for example, he does not like that a AllocConsole Be called in the process to debug or display information from an internal cheat. So he checks if a handle console appeared in the ProcesspaRemeters PEB or if GetConsoleWindow() Returns something. Result: the slightest non -planned console = suspicion of cheating.

On the memory scans side, there is even a “honeyypot” of allocated pages but never used by the game. If a cheat engine type tool comes to read them, this area is suddenly found physically mapped, and TAC remarks that “something” Fully gone there. Well seen to locate untimely memory scanners.

As you can see, it’s super sharp. Without forgetting that TAC also monitors local network communications that could betray the presence of cheating tools. It analyzes local TCP connections, it detects control servers & control and monitors the ports used by known cheats. Besides, he compares the Local Game with other connections on the same machine to see if a cheat would not make a local “C&C”, by transmitting internal information. The idea is to identify a ladle port opened by the same process (or by another) which would cause with the game.

Now to understand these protections, researchers like SSNO must be ingenuity. They must develop personalized analysis tools, reconstruct encryption algorithms, draw complex execution flows and of course understand the nested protection mechanisms. It’s been a lot of work but it allows us to see that the developers are constantly innovating to protect their creations. By the way, TAC will also check little more “system” things like the Allocationgranularity or the list of Windows modules (what is in InMemoryOrderModuleList) to locate a custom bone or sabotage of the PEB/LDR structure. No detail left to chance!

Besides, we are starting to see an increased use of AI for the detection of suspicious behavior but also the implementation of hardware protection via the new generation processors. And of course everything that is further behavior analyzes or homomorphic encryption for sensitive data. It’s really an exciting area!

Of course, all of these discoveries must be used ethically and responsible, because cheating, whether at video games or elections, it’s null.

For a complete and detailed technical analysis, see the Original source of this study. And a big thank you to Miguel for sharing!


Source link

Categorized in:

Technology