Home Inside anti-cheat:Packman
Post
Cancel

Inside anti-cheat:Packman

Overview

Packman is an anti-cheat solution developed by the Riot Inc. It has been created by former hobby reverse engineer to stop scripting software from taking advantage over gamer. Packman itself is a ring3 (usermode) anti-cheat which uses its own pe file encryption to protect the game executable. The protected game loads a DLL at startup to decrypt and initialize detections.

File encryption

Sections of game executable

Entrypoint of game executable

When opening the game executable file in IDA or Ghidra, it is not possible to analyze it. There are two new sections which has been added to the game executable (.stub).

In addition, the entrypoint is nopped and only encrypted functions can be found:

Sample of encrypted function

Usermode module

Stub.dll is the main organ of the anti-cheat. It detects cheat tools and prevents attacker from accessing the memory. The usermode module installs a VEH handler and performs decryption of the memory pages in runtime by catching ERROR_ACCESS_VIOLATION exceptions. Each section gets remapped with the flag SEC_NO_CHANGE which means a change will not be applied using VirtualProtect. Instrumentation callbacks (also known as “nirvana hooks”) are installed at initialization to catch API calls from external processes. Packman also performs manual syscalls.

String encryption

The following image below demonstrates the string encryption used in the usermode module.

String encryption used in DllMain

Function traps

Since the rework of the anti-cheat, the game executable seems to have installed checks inside specific functions. It verifies that the return address is somewhere inside the game executable. Once a call is not the range, it will set a byte pointer to true which will lead to a ban.

Usermode hooks

The main module detours low level nt api functions to catch and block manipulations. The usermode module hooks the following functions:

  • ZwTestAlert
  • NtCreateThreadEx
  • ZwCreateSection
  • NtContinue
  • ZwReadFile
  • LdrInitializeThunk
  • RtlAddVectoredExceptionHandler
  • NtQueryInformationProcess
  • NtQueryVirtualMemory
  • NtCreateThread
  • NtProtectVirtualMemory
  • DbgUserBreakPoint
  • DbgBreakPoint

Usermode detections

The current module is virtualized using VMProtect 3, but here is a list of the detections as of 22th December 2019:

  • Process detection (using EnumWindows and OpenProcess)
  • Thread detection (using hooks)
  • Thread manipulation detection (=suspending a thread will not work)
  • WaitForSingleObject is used to detect whether a thread is running or not.
  • DLL detection (Loading a dll using LoadLibrary will result in a ban)
  • ZwCreateSection trap
  • Page modifications
  • Any modification to the page protection is detected. (VirtualProtect is hooked)
  • Each page is being checked for byte patches.
  • Debugger detections
  • Debugger detection

  • There are a lot of debugging checks found in the client (not all are listed below) :
  • IsDebuggerPresent check
  • DbgUserBreakPoint and DbgBreakPoint modifications (the windows debugger will not run through it)
  • Context checks (GetThreadContext is used to detect hardware breakpoints in stub threads)
This post is licensed under CC BY 4.0 by the author.