A summative of EAC EOS cheat detection
A synthesis of public EAC reverse-engineering notes covering kernel monitoring, injection detection, memory integrity, driver validation, and platform inspection.
I’ve been collecting notes from several Easy Anti-Cheat (EAC) reverse-engineering repositories, along with additional research notes covering kernel callbacks, memory scanning, driver validation, and hardware-level inspection. I wanted to bring the findings together into one reference rather than leave them scattered across different write-ups.
The main takeaway is that EAC detection isn’t limited to identifying a cheat executable or checking whether a driver is signed. The research describes several layers of inspection, ranging from process handles and memory regions to kernel integrity, loaded modules, debugging state, and platform configuration. Some of the implementation details below come from community notes and have not been independently verified against a current EAC EOS build.
1. Overview of detection surfaces
The following table summarizes the main areas covered by the research.
| Detection surface | Areas of interest | General purpose |
|---|---|---|
| Process inspection | Processes, threads, handles, access rights | Identify suspicious interactions with protected processes |
| Injection detection | Module loading, executable memory, thread activity | Investigate unexpected code execution |
| Kernel integrity | Loaded drivers, executable mappings, hooks | Identify unexpected kernel code or modifications |
| Driver validation | Signatures, certificate chains, known vulnerable drivers | Assess driver trust and integrity |
| Memory scanning | Page contents, PE structures, signatures | Detect known patterns or unexpected modifications |
| Hypervisor inspection | CPU features, timing, virtualization state | Investigate inconsistencies in the execution environment |
| DMA and firmware | PCI devices, ACPI, SMBIOS, boot measurements | Examine platform-level integrity |
| Anti-debugging | Debugger state, exception behavior, timing | Identify debugging or instrumentation environments |
| Communication interfaces | Device objects, handles, shared resources | Understand how components communicate across privilege boundaries |
These categories overlap. An unusual memory region, for example, may be relevant to both injection analysis and memory integrity, while a driver can be examined through module enumeration and signature validation.
2. Injection and process manipulation
The supplied notes describe several common injection techniques and the kinds of evidence that may be associated with them.
| Technique | Relevant detection surface | Notes |
|---|---|---|
| LoadLibrary injection | Image-load notifications and module inspection | Conventionally loaded images provide module information that can be inspected |
| Manual mapping | Memory mappings and execution provenance | May not have the same module bookkeeping as a conventional image |
| Reflective DLL loading | Memory contents and PE structure analysis | Image-like content can exist without ordinary module registration |
| APC injection | Thread activity and execution context | Relevant behavior may occur during asynchronous procedure call delivery |
| Thread hijacking | Thread context and control flow | Unexpected changes to thread execution can be investigated |
| Process hollowing | Process creation and image integrity | Differences between expected and observed process images are relevant |
| Module stomping | Image contents and section integrity | In-memory modifications may differ from the original image |
| DLL sideloading | Image loading and module provenance | A legitimate loading mechanism can still introduce an unexpected dependency |
| Shellcode execution | Executable memory and stack inspection | Code execution may not correspond to a conventional loaded module |
| Section-based injection | Section mappings and process memory | Shared or mapped sections can introduce executable content |
| Threadless injection techniques | Memory and execution behavior | Detection depends on the implementation and the evidence available to the monitor |
The detection labels in the original notes should not be interpreted as guarantees. Whether a technique is detected can depend on the implementation, the game, the EAC version, and the surrounding behavior.
The important distinction is between identifying a technique by name and identifying the artifacts it produces.
3. Kernel drivers and integrity checks
Kernel-level components introduce additional concerns because they operate with privileges unavailable to ordinary user-mode applications.
The supplied notes discuss unsigned and test-signed drivers, known vulnerable drivers, manually mapped code, revoked certificates, and build artifacts that may reveal development environments.
| Driver characteristic | Relevant inspection |
|---|---|
| Signature status | Code Integrity and certificate validation |
| Test-signing configuration | Boot configuration and system integrity state |
| Known vulnerable drivers | Driver identity and known-driver reputation data |
| Revoked certificates | Certificate-chain and revocation checks |
| Manual mapping | Module registration and executable memory characteristics |
| Unexpected kernel modifications | Code integrity and hook inspection |
| Development artifacts | Module metadata and other identifying information |
A valid signature does not establish that a driver is safe. Signed but vulnerable drivers can still provide dangerous capabilities, which is why vulnerable-driver blocklists and other integrity mechanisms matter.
Likewise, a missing module-list entry is not proof that kernel code is invisible. Module enumeration is only one source of information about executable memory.
The research also mentions image-verification callbacks and Code Integrity-related routines. Their exact behavior and relationship to EAC should be checked against the relevant Windows and EAC versions before drawing implementation-specific conclusions.
4. Kernel callbacks and monitored operations
One of the more useful parts of the supplied material is its inventory of Windows kernel interfaces relevant to anti-cheat monitoring.
These interfaces can provide visibility into process activity, thread creation, image loading, handle access, and filesystem operations.
| Interface or mechanism | General purpose | Relevance to integrity monitoring |
|---|---|---|
ObRegisterCallbacks | Register object callbacks for supported process and thread operations | Observe or mediate certain handle operations |
PsSetCreateProcessNotifyRoutineEx | Register process creation and exit notifications | Track process lifecycle events |
PsSetCreateThreadNotifyRoutine | Register thread creation notifications | Track thread lifecycle events |
PsSetLoadImageNotifyRoutine | Register image-load notifications | Observe image mapping events |
SeRegisterImageVerificationCallback | Image-verification-related functionality | Relevant to investigating driver verification behavior |
FltRegisterFilter | Register a filesystem minifilter | Observe filesystem activity within the filter’s scope |
KeRegisterNmiCallback | Register a non-maskable interrupt callback | Relevant to specialized low-level diagnostics and monitoring |
These mechanisms have different scopes and contracts. They do not automatically provide unrestricted visibility into every operation, and registration alone does not establish what a particular EAC version records or how it uses the resulting information.
Kernel routines used during inspection
The supplied notes also identify several routines associated with process lookup, memory access, stack inspection, and system information queries.
| Routine or family | General purpose |
|---|---|
PsLookupProcessByProcessId | Resolve a process identifier to a process object |
PsLookupThreadByThreadId | Resolve a thread identifier to a thread object |
MmCopyVirtualMemory | Support memory-copy operations involving process address spaces |
MmCopyMemory | Copy data from supported virtual or physical memory sources |
RtlWalkFrameChain | Capture stack-frame information |
RtlLookupFunctionEntry | Locate function-table information used for unwinding |
NtQuerySystemInformation | Retrieve supported classes of system information |
PsGetProcessImageFileName | Retrieve a process image name through a kernel routine |
These are Windows interfaces and routines, not proof of EAC-specific usage by themselves. Establishing that EAC invokes a particular routine, uses a particular information class, or calls it at a specific frequency requires evidence from the analyzed build.
5. Memory scanning and image integrity
The research notes describe multiple approaches to examining memory. These methods answer different questions and should not be treated as interchangeable.
| Method | What it examines |
|---|---|
| Page-content hashing | Whether memory contents differ from expected data |
| Byte-pattern scanning | Whether known signatures occur in a memory region |
| PE header comparison | Whether in-memory image metadata differs from an expected image |
| Section integrity checks | Whether image sections contain unexpected modifications |
| Section-permission analysis | Whether memory protections are consistent with the expected layout |
| Import and export validation | Whether resolved addresses and image metadata are consistent |
| Marker-bounded integrity checks | Whether a defined region matches an expected integrity value |
| Kernel code integrity | Whether important executable regions have been modified |
The notes also mention SIMD-based scanning and hardware-assisted integrity checks. These are implementation details whose exact use, scope, and performance characteristics need to be established from the relevant code or binary.
Memory scanning has inherent limitations. A hash mismatch can indicate a modification without explaining why it occurred. A signature match can identify a known pattern without establishing the intent of the program containing it. Legitimate updates, relocations, and runtime modifications also need to be accounted for.
6. Hypervisors, DMA, and firmware
Another notable aspect of the supplied research is its focus on the platform below and around Windows itself.
Hypervisor and virtualization inspection
The notes describe checks involving CPUID, model-specific registers (MSRs), timing measurements, and virtualization-related state.
| Area | General inspection goal |
|---|---|
| CPUID features | Examine reported processor and virtualization capabilities |
| Hypervisor vendor information | Inspect virtualization-related identification data |
| Feature consistency | Compare related processor feature reports |
| MSR state | Investigate selected processor-control and system-call state |
| Timing measurements | Look for unexpected differences in execution timing |
| Hypervisor binaries | Compare expected files with observed integrity information |
| VBS and HVCI | Examine virtualization-based security configuration |
Timing and feature checks are not definitive on their own. Hardware differences, firmware configuration, virtualization products, and system load can all affect observations. A particular CPUID value or timing result should not automatically be interpreted as proof of cheating.
DMA and firmware inspection
Direct Memory Access (DMA) devices and firmware provide another source of platform information.
| Area | Potential integrity concern |
|---|---|
| PCI device enumeration | Unexpected devices or device configurations |
| PCI configuration space | Device identity and configuration consistency |
| DMA protection | Whether platform protections are enabled and configured as expected |
| ACPI tables | Firmware-provided platform descriptions |
| SMBIOS data | Firmware-reported system information |
| Secure Boot | Integrity of the boot chain |
| TPM measurements | Recorded measurements of relevant boot components |
| Kernel image integrity | Differences between expected and observed system-image contents |
The original notes include specific claims about FPGA-based DMA hardware, firmware table checks, boot measurements, and hypervisor artifacts. Those details should be considered hypotheses until verified against a specific EAC build and platform.
7. Anti-debugging and tool detection
The supplied material also identifies debugger state, exception behavior, timing, process names, and build artifacts as possible inspection areas.
| Area | General approach |
|---|---|
| Debugger state | Inspect operating-system debugging indicators |
| Exception behavior | Examine how execution responds to debugging-related exceptions |
| Timing | Compare execution timing under controlled conditions |
| Process identification | Identify known development or debugging tools |
| Module inspection | Examine loaded components and their provenance |
| Build artifacts | Look for metadata associated with development environments |
The original notes mention tools such as Cheat Engine, x64dbg, ReClass.NET, Process Hacker, System Informer, IDA Pro, and WinDbg.
The presence of a process name is not equivalent to proof of malicious activity. These tools have legitimate uses, and a robust interpretation must distinguish tool identification from evidence of unauthorized manipulation.
8. Communication and monitoring frequency
The notes describe several classes of communication objects, including device objects, named sections, pipes, and shared-memory arrangements. They also discuss recurring inspections and callback-driven monitoring.
Communication objects can expose useful information about how components interact, but the visibility of any particular object depends on its type, ownership, access rights, and the inspection mechanism involved.
The supplied notes also contain specific numerical claims about callback sampling, process and thread scan counts, module-list passes, and timing checks. I have not reproduced those figures as established facts because their validity depends on the underlying build and the methodology used to obtain them.
A more useful distinction is between event-driven and periodic inspection:
| Inspection model | General characteristic |
|---|---|
| Event-driven callbacks | React to supported events such as process creation, image loading, or handle operations |
| Periodic scanning | Revisit selected system state at intervals |
| Integrity comparisons | Compare observed state with an expected representation |
| Platform queries | Collect information about devices, firmware, or system configuration |
| Behavioral analysis | Interpret events and state changes in context |
These models can complement one another. Event notifications provide information about specific transitions, while periodic inspection can reveal state that is not adequately explained by a single event.
9. Sources and limitations
This write-up consolidates the supplied notes with general Windows kernel concepts. The source repositories are useful starting points, but the detailed claims should not be assumed to describe every current EAC EOS release.
- EntityRealm/EACKernelReversal — kernel reverse-engineering research.
- girther9399-gif/EAC-REVERSED-WRITEUP — EAC analysis and community research notes.
- adamvalves/easyanticheat-kernel-driver-re — kernel-driver reverse engineering.
- RejiDev/game-hacking-guidelines: EAC — additional anti-cheat research notes.
The specific detection labels, API inventories, scan frequencies, and implementation details in the collected notes have not all been independently confirmed. Public reverse engineering can reveal useful behavior, but a claim about a particular callback, hash, signature, or detection decision needs supporting evidence from the relevant version.
10. What remains to be verified
The main unanswered question is how these different sources of information are combined into an actual detection decision. Identifying a callback or a memory scanner does not establish its exact role, and observing a system query does not prove that it independently triggers a detection.
The next step is to compare the claims against the relevant binaries and documented Windows behavior, record which findings are reproducible, and keep version-specific observations separate from assumptions. That should make this a more useful reference for future EAC research without treating community notes as a definitive specification.