Pay 2 Cheats: How Do They Really Work?, Blindage Research Group

A paid cheat is not just an executable that knows where the target game keeps its player list. Before it can draw anything, it has to get the right build onto the machine, decide who may use it, obtain memory access, interpret game state, and get pixels onto the screen.

This implementation splits those jobs across a protected native loader, a downloaded product executable, and a legacy hardware-access driver. The driver is a temporary dependency. The interesting part is the state the product tries to retain after asking Windows to unload it.

This case study follows one Windows x64 implementation, from the loader's first callback to the product's memory reader and renderer.

Analysis scope: The files were obtained through authorized download-only sessions and examined statically. The paths below describe the implementation and its dependencies, not a recorded execution of the payload or driver.

Three Components, Different Jobs

The loader owns the delivery side. It contains the sign-in workflow, device identity, product selection, download handling, and the process launch that hands control to the product. The product owns game integration, memory access setup, the software x64 interpreter, feature workers, and rendering.

The legacy hardware-access driver supplies the initial privileged memory operations. Its device interface lets user-mode code request physical-memory transfers. The product uses that access during setup, then switches to a memory-access mechanism of its own.

Following only the first executable gives an incomplete picture. The loader stages the driver but the downloaded product opens its device and uses it. Conversely, finding a dangerous driver does not explain licensing, the local launch context, or the rendering path.

The three components and their interfaces
Component	Main responsibility	Interface
Protected loader	Authenticate, retrieve assets, launch product	Browser authorization, encrypted requests, child-process launch
Product executable	Prepare memory access, interpret game code, build UI	Local resources, target memory, overlay framebuffer
Legacy hardware-access driver	Bootstrap physical-memory reads and writes	Device requests for privileged memory transfers

Before the Entry Point

The original loader stores its native code encrypted. A TLS callback performs protector work before the ordinary executable entry point. Here TLS means Thread Local Storage, a Windows executable mechanism. It has nothing to do with the Transport Layer Security used for HTTPS later.

The callback derives a 16-byte metadata key using CRC32C over part of the PE header together with fixed material. It decrypts protection metadata with RC4 after discarding the first 1,024 keystream bytes. Section contents use another RC4-drop-1024 stage with a 20-byte section key derived from that metadata and the section's relative address.

Recovering those contents exposes ordinary native x64 functions. Individual strings remain less convenient. Code reconstructs literals from XOR-obfuscated constants, often behind one-time initialization guards. Decrypting a section does not automatically turn every string reference into readable text.

That distinction matters when interpreting a sparse string scan. A missing plain-text URL or function name can mean it is assembled later. It does not establish that the behavior is absent.

After section decryption, the remaining work is ordinary native-code analysis mixed with literal reconstruction. The section encryption and string builders are separate layers. Removing the outer layer exposes the application, but does not remove the obfuscation inside every function.

Checking for Analysis Tools

The loader checks debugger state through IsDebuggerPresent and native process-information queries. It also queries kernel-debugger information and inspects thread debug registers used for hardware breakpoints. These checks cover different observation points rather than relying on a single debugger flag.

Recovered inspection labels also refer to modified system-library code, suspicious executable memory, header integrity, unexpected threads, and hostile handles. Those labels identify additional inspection areas, although their implementations were not traced to the same depth as the debugger queries.

The loader also queries Windows security configuration, including virtualization-based security and Memory Integrity status. These values describe the security environment around the later driver-loading path. A legacy driver remains subject to the host's code-integrity and driver-blocking policies.

For analysis, this creates two separate problems. The code must first be recovered from its encrypted form. The recovered application can then inspect the process, its threads, and the surrounding Windows configuration. Unpacking the image removes neither the checks nor their failure paths.

The native sign-in path uses the browser rather than asking the user to type credentials directly into the loader. It creates a PKCE-style verifier and challenge, starts a local loopback listener, opens an authorization page, and receives a callback carrying an authorization result. The native client then exchanges that result for credential state.

PKCE connects the authorization exchange to the client that generated the verifier. The browser handles the interactive sign-in, while the loopback listener returns the result to the local application. The native client uses its verifier when exchanging that result for tokens.

The loader also combines machine information into a hashed hardware identity and uses a persisted P-256 signing key through Windows CNG. The software key-storage provider holds the private key and restricts its export. The application obtains the public key and requests signatures through the provider rather than exporting private-key bytes.

Above HTTPS, native requests use another cryptographic envelope. Recovered code performs P-256 ECDH, derives key material with HKDF-SHA256, and uses AES-GCM for authenticated encryption. Session state, counters, request and response directions, and key epochs influence that wrapping. Device proofs tie requests to the local signing identity.

These layers have different jobs. HTTPS protects transport. The application envelope binds messages to its own session machinery. The device proof and hardware identity support licensing and account binding.

Authentication therefore has state beyond an access token. An encrypted request belongs to a session and counter, while its device proof belongs to a persisted signing identity. Copying a bearer token alone does not reproduce a valid native request.

From Download to Child

The loader writes the downloaded driver bytes to a randomized cache file and places its path in an environment variable. It obtains the product executable separately, creates a suspended copy of its own executable, maps the downloaded image into that child, adjusts execution state, and resumes it.

The launch combines manual PE mapping with startup redirection inside a suspended child. The reviewed branch establishes those operations, but not a separate step that unmaps the child's original image. The useful detail is the replacement startup path, rather than forcing the sequence into one process-hollowing label.

The child-creation call uses the normal inherited environment. That connects the earlier path setter to the product's later environment lookup, provided the setter succeeds. The environment variable carries a location, not the driver image itself.

The product consumes that path, clears the variable from its own environment, and makes a generated temporary driver copy for loading. The randomized cache file and the temporary service image are two distinct file contexts. Hunting only for an original driver filename would miss the point.

The Product Expects Local Context

The downloaded executable reads a local profile, extracts username and role strings, and checks that both are nonempty. It also locates local assets and configuration and reads product-scoped resources from the registry.

This startup check validates the presence of expected local context. Service authorization belongs to the loader's earlier exchange. Profile data, configuration, and resource lookup give the product the state it needs after the loader has delivered and launched it.

The directory layout and consumer calls suggest that the surrounding launcher prepares this state. Fonts, images, profile information, and configuration are consumed locally rather than fetched again by the initialization functions described here.

Startup prepares its memory-access support before attaching to the target game. It then identifies the target process and modules, initializes game-runtime metadata, and starts its workers. Delivery, local initialization, and game attachment are distinct stages with their own dependencies.

A Temporary Driver, Not Temporary Privilege

The product creates a generated driver-service registry entry, points it at a temporary image, requests driver-loading privilege, and calls NtLoadDriver. It then opens the hardware-access driver's device. Registry creation, loading, and device access each have their own failure paths.

The process token must already contain the necessary privilege. Driver policy and code integrity also remain part of the loading decision. An embedded certificate is one input to that decision, not an exemption from current Windows policy.

On the application side, the selected device requests perform physical-memory reads and writes. On the driver side, the dispatcher routes those requests to handlers that call MmMapIoSpace, copy in the appropriate direction, and unmap the range.

The driver also exposes other hardware-oriented facilities, but this bootstrap uses its physical-memory operations. That turns a general hardware-access interface into a privileged setup dependency for the product.

Why unload a dependency that supplies memory access? Because the product is trying to use it to create something longer-lived than the device handle.

Keeping the Window

The product uses driver-backed access to locate kernel code and attempts a temporary kernel-call redirection. At a high level, it saves existing code, alters a kernel entry, invokes a native call as a bridge to selected kernel routines, and attempts to restore the original bytes. This is kernel-code tampering, not an ordinary file operation.

That bootstrap gathers kernel-only information and modifies the current process's paging state. The initialization and its later read/write consumers strongly support a user-accessible physical-memory window: a retained virtual base through which the product addresses physical memory.

A normal application pointer refers to virtual memory within an address space. This window is intended to make physical addresses reachable through a retained virtual base. The steady-state helper range-checks physical requests and copies through that base rather than issuing another driver request for each transfer.

The retained object is a mapping, not an allocation equal to every physical address it can cover. Address coverage is not RAM consumption. Later readers use the mapping base rather than the driver's device handle.

The design ties ongoing access to the product's address space. Its privileged setup depends on Windows paging behavior, available kernel information, and host protections. The driver provides the bootstrap, while the product's own memory routines provide the steady-state access path.

Reading Across Pages

A physical-memory window alone does not identify which physical bytes belong to a target virtual address. The product also implements a software page-table walk. It finds a candidate target address-space root, translates known image addresses, and uses expected image headers as corroboration before retaining that translation context.

The read path then splits requests at page boundaries. For each chunk it translates the relevant target virtual address and copies the corresponding physical bytes. Adjacent virtual pages need not be adjacent in RAM, so translating only the first byte and copying the whole request would be wrong.

Consider a structure that begins near the end of one page and continues into the next. The reader handles the tail of the first page, translates again, and handles the remainder. Each translation is made against the target's page tables, not the product's ordinary virtual-address layout.

It is also not an atomic snapshot. The target may change between chunks. A later translation or copy can fail after earlier bytes have already reached the destination. Code consuming those buffers still has to deal with failures and inconsistent state.

The steady-state backend contains both read and write helpers. Its access path differs from ReadProcessMemory and WriteProcessMemory: the product walks the target's page tables and transfers bytes through its physical-memory window.

Evaluating Game Code in Software

The product embeds a software x64 interpreter. It maintains simulated registers and flags, fetches instruction bytes, decodes operands, dispatches instruction semantics, and advances simulated execution. Selected calls into game code are evaluated through that machinery rather than being native calls made inside the target game.

Each emulated call starts with prepared CPU state, a simulated stack, and local thread-related storage. A completion marker ends the call. An instruction budget bounds execution, while failed memory reads, unsupported execution paths, and incomplete calls return failure.

The interpreter uses code-page and decoded-instruction caches to avoid repeatedly fetching and decoding the same instructions. Write invalidation keeps those caches consistent with changes to its simulated memory. External-call dispatch and the memory backend connect that execution engine to the rest of the product.

Its memory callbacks explain the boundary. Reads first consult local simulated storage. A sparse local byte map supplies another view. If those cannot satisfy the request, the callback falls back to the product's target-memory reader. Emulated writes go into local buffers or that sparse map, not straight back into the target game.

That permits a calculation to change its simulated stack and heap without changing the real target memory for every emulated store. It does not constrain the product's other write paths. A local interpreter write and a real physical-memory write are different operations.

External calls also need an environment. Some hooks model allocation and return behavior. Others return simplified results. Simulated thread-local state is not the host thread's actual state, and a modeled system call is not automatically a real kernel transition. The interpreter can only be trusted for the behavior it implements.

Pixels Need a Path

The product turns game state into visual primitives, targeting-related indicators, a menu, keybind display, and HUD elements. Its output is a software framebuffer.

The renderer opens an existing shared-memory object associated with a third-party overlay and maps it using OpenFileMappingA and MapViewOfFile. It checks the available region and framebuffer dimensions before using the storage. The overlay participant supplies the shared object.

The drawing path finds changed pixel spans, copies them into the mapped framebuffer, and increments a shared update counter. It publishes pixels through an existing rendering channel rather than creating a separate graphics swapchain in the inspected path.

That makes the shared-memory layout part of the rendering interface. The producer and consumer need to agree on dimensions, buffer capacity, pixel storage, and update signaling. A valid game-memory reader alone is not enough to put the resulting UI on screen.

Cleanup Is Also Tampering

The teardown path does more than release handles. It attempts to alter driver bookkeeping associated with MmUnloadedDrivers, PiDDBCacheTable, kernel hash records, and conditionally WDFilter. Some paths depend on the Windows build or skip work when a target is unavailable.

These operations target Windows bookkeeping about the driver and its image. Their effects are specific to the structures they modify. Other event sources and security components can retain independent records of the same activity.

Teardown also closes the device, requests driver unload, deletes the service key, and attempts file removal. Those operations have different lifetimes: closing a handle, unloading code, deleting a registry entry, and changing bookkeeping are separate actions.

For detection, the useful picture is the relationship between artifacts: staged bytes, a generated service image, registry writes, a driver-load request, physical-memory operations, altered kernel or paging state, and later bookkeeping changes. Correlating these surfaces is more useful than expecting one record to describe the whole chain.

A driver no longer appearing in one list would not settle whether its earlier activity happened. Equally, a randomized file or a shared-memory mapping alone is weak evidence. Correlating the sequence and retained state is more useful than treating one filename as a verdict.

The Access Outlives the Driver

The loader solves delivery and authorization. The product solves game integration and ongoing memory access. The driver supplies the privileged operations needed during bootstrap. The software interpreter and overlay interface then turn game data and selected calculations into visible output.

The key design choice is the separation between creating access and using it. The product is built to retain a physical-memory window after asking Windows to unload the helper. Subsequent transfers use that window rather than reopening the driver for every read.

Temporary describes the helper's intended lifetime. It does not describe the lifetime of the access mechanism it helped create.

Pay 2 Cheats: How Do They Really Work?