How Escape from Tarkov ensures game integrity

Game-hacking is an always-changing landscape, and this requires anti-cheat developers to innovate and implement unique, unidentified detection mechanisms. In this article I will shed some light on the mysterious routines that are getting hundreds of cheaters banned in Escape from Tarkov . So let’s start from the beginning.

(1) A hash value is a serialized, fixed-size value that represents an arbitrarily-sized input. Usually used for fast comparisons

Escape from Tarkov (herein “Tarkov”) runs on the game engine Unity through Mono , which opens up for some interesting security issues that game-hackers can abuse to gain an advantage while playing. First of all, the Unity game assemblies are very hard to integry-check when they’ve been JIT-compiled. This is because you can’t simply store a hash value (1) of the code, as the JIt-compiled methods might differ depending on what processor features are enabled.

This leaves the anti-cheat developers in a tough spot. It is not possible to ensure the integrity of JIT-compiler functions without either:

• Initialising before the game does then hooking the responsible JIT-engine. This hook can be used to cache hashes for all compiled functions for later comparison
• Resorting to alternative ways for ensuring game integrity, like checking image metadata.

While Tarkov actually has integrity checks (simple file hashing) in their Battlestate Games launcher application, this is trivial to patch out of the executable by opening the launcher executable in a tool like dnSpy and simply removing the entire thing. The fact that this integrity check (internally called “consistency check” in the launcher) was so easy to circumvent, enabled thousands of cheaters to simply patch the game assembly on disk. This could include features such as “wallhack”, “no recoil” et cetera.

It seems like Battlestate Games got tired of this vulnerability, and to fix it, they likely called up the developers of the commercial anti-cheat BattlEye, which they’ve been utilizing for quite some time now. This article will explore a previously-unknown anti-cheat module that is being dynamically streamed and executed to Tarkov players circa 15-20 minutes into their raids.

The following code snippet is an accurate representation of the new anti-cheat module, that I have reverse engineered and decompiled. If you are intimidated by the code, skip this section and go straight to my explanation further down!

auto paths = {
    "EscapeFromTarkov_Data\\Managed",
    "EscapeFromTarkov_Data"
    "EscapeFromTarkov_Data\\StreamingAssets\\Windows\\assets\\content\\characters\\character\\bear\\bear0";
}

auto report_buffer = (std::uint8_t*)malloc(0x5000);
report_buffer[0] = 0x00;
report_buffer[1] = 0x49;

for (auto index = 0; index < 3; ++index)
{
  _mm_lfence();

  // CALCULATE CONTAINING PATH
  PathCombineA(&combined_path, 
               &paths[index], 
               index == 1 ? "sharedassets*.assets" : "*");

  auto search_handle = FindFirstFileA(&combined_path, &file);

  if (search_handle != INVALID_HANDLE)
  {
    // LOOP ALL FILES
    while (true)
    {
      // SKIP DIRECTORIES
      if (!(file.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY))
      {

        // CALCULATE STRING LENGTH
        for (filename_size = 0; file.cFileName[filename_size]; ++filename_size)
          ;

        // CHECK FOR BUFFER OVERFLOW
        if ((buffer_ptr - report_buffer + filename_size + 5) > 0x5000)
        {
          break;
        }

        // COPY FILENAME
        *buffer_ptr = filename_size;
        for (i = 0; i < *buffer_ptr; ++i)
          buffer_ptr[i + 1] = file.cFileName[i];

        // GET FINAL FILENAME
        PathCombineA(&combined_path, &paths[index], file.cFileName);
        if (index > 0 || memeq_wildmark(file.cFileName, "NLog????.nlo"))
        {
          buffer_ptr += *buffer_ptr + 1;
          *(_DWORD *)buffer_ptr = 0;

          if (GetFileAttributesExA(&combined_path, false, &file_attributes))
            *(_DWORD *)buffer_ptr = file_attributes.nFileSizeLow;

          buffer_ptr += 4;
        }
        // GET MONO INFORMATION FROM MEMORY
        else if (GetFullPathNameA(&combined_path, MAX_PATH, &full_path, 0)) 
        {
          auto mono_image = mono_image_loaded(&full_path);
          if (mono_image)
          {
            buffer_ptr += *buffer_ptr + 1;
            *(_DWORD *)buffer_ptr = mono_image->image_size;
            buffer_ptr += 4;
          }
        }
      }

      // GOT TO NEXT FILE
      if (!FindNextFileA(search_handle, &file))
      {
        break;
      }
    }

    FindClose(search_handle);
  }
}

battleye::send_packet(report_buffer, buffer_ptr - report_buffer, false);
free(report_buffer);

The module itself is quite simple. It stores a hardcoded list of folders to scan that all reside inside of the Tarkov game folder:

EscapeFromTarkov_Data\\Managed
EscapeFromTarkov_Data
EscapeFromTarkov_Data\\StreamingAssets\\Windows\\assets\\content\\characters\\character\\bear\\bear0

All files in these folders are scanned, with their image size, file name and size uploaded to the BattlEye servers. This can be used to detect anyone tampering with the assemblies on disk , specifically. These folders contain game related assemblies, character details and map data. But this module has some huge oversights, that cheaters can use, and will use, to continue cheating in Tarkov.

First of all, the API-calls used to iterate files are ascii-specific, which means that if any part of the game path is encoded with unicode, this check will simply be skipped by anti-cheat. A second issue is also present: the hardcoded buffer length of 0x5000 bytes is not necesarily large enough to contain the information required. Nothing stops a cheater from creating 100+ files with names long enough to take up MAX_PATH amount of characters in the buffer. This will essentially make the anti-cheat only upload the first 100 garbage files instead of checking the actual game assemblies. Lastly, the mono image size in memory can easily be overwritten by any game-hacker with memory access.

Another thing we noticed is the presence of the _mm_lfence intrinsic, which ensures all previous load instructions are completed before continuing. The use of an out-of-order execution barrier is a little bit puzzling, but it may be for string serialization. The use cases are obscure and in this case we believe the compiler may have emitted a useless fence.