Undetected-Easy

Undetected Easy (UDE) is a detection scanner for finding Kernel Driver detections before they find you.
UDE was built around reverse-engineered routines primarily from EasyAntiCheat, BattlEye and Vanguard.
UDE gives developers a way around ban waves and before anti-cheats can collect any other signatures.

Table of Contents

1. How does UDE work?
2. Why use UDE?
3. What does UDE detect?
4. Tutorial
5. Roadmap
6. Conclusion

How does UDE work?

UDE is a usermode interface and a kernel detection driver.
The usermode client creates a interface and communicates with the driver to find detections.
The kernel driver handles the detection scanning logic while the usermode displays it.

The driver creates a detection packet containing the target, violation, method, address, and size.
The client displays the detections with the category, reason and how to fix it after scanning.
After scanning it writes a raw detection ude-log.txt report for review if needed.

Why use UDE?

Anti-cheats detect projects through many small integrity checks instead of one universal method.
UDE helps show which part of your project is detected, why it is detected, and how you can remove it.
This makes it easier to fix detection sources before testing against a real anti-cheat.

What does UDE detect?

UDE includes multiple scan categories based on common anti-cheat integrity routines.
It scans kernel memory, execution flow, loaded modules, objects, devices, and process/thread states.
Each scan category has different multiple integrity checks.

Module Integrity

Module integrity scans loaded kernel modules and compares their live memory against there disk memory.

What It Detects

• Modified .text or executable image sections
• Import Address Table and Export Address Table redirection
• Writable executable code pages
• Executable pages inside non-executable sections
• Code pages backed by suspicious backing
• Private COW image pages replacing trusted memory

Why It Matters

Anti-cheats commonly detect kernel drivers by checking if there code is inside of backed modules.
The only way to get around this is to map yourself into a kernel driver but there are multiple integrity checks that can detect it like:
If a driver patches another module, redirects a function table, changes page permissions, or remaps trusted code with different backing memory, module integrity checks can expose it.

Execution Integrity

Execution integrity checks where kernel execution is coming from and if the code executing is suspicious.

What It Detects

• Execution from non-backed memory
• Execution from non-code image sections
• Return addresses outside executable sections
• Return addresses backed by suspicious backing
• Stack pointers outside kernel stack bounds
• Suspicious call stack
• Thread start addresses outside trusted code
• Repeated execution from small code caves

Why It Matters

This detection is likely to happen when using public driver mappers like KDMapper, GDrv-loader, e.g.. that allocate in non-backed memory.
When you create a thread or redirect execution to your module, your execution is in unbacked memory.
This can also happen because of messy execution from hook callstacks and bad thread hiding.

Memory Integrity

Memory integrity scans kernel virtual memory and page-tables for suspicious mappings and permissions.

What It Detects

• Writable executable pages outside loaded modules
• Executable anonymous kernel pages
• Executable PE images outside the loaded module list
• Headerless executable images outside the loaded module list
• Kernel pages mapped as user accessible
• Same PFN mapped into both user and kernel ranges
• Same PFN mapped as both writable and executable
• Page-table self-consistency violations
• Suspicious present PML4 slots
• PFNs outside physical memory ranges

Why It Matters

Many unsigned or hidden drivers don't have proper backing that anti-cheats exploit.
Anti-cheats can detect these regions by looking for PE signatures and bad executable memory.
These are all usually because of a bad mapper like KDMapper, GDRV-Loader, e.g...

Pool Integrity

Pool integrity scans nonpaged pool allocations for executable memory and code-like contents.

What It Detects

• Executable nonpaged pool allocations
• Pool allocations containing PE headers
• Pool allocations containing code patterns
• Headerless executable pool regions
• Large executable allocations that resemble mapped images

Why It Matters

Executable pool is one of the most common places for hidden kernel code to live.
Even when a payload removes its PE header or avoids the loaded module list, the allocation can still be found by scanning pools.
This detection is likely to happen when using public driver mappers like KDMapper, GDrv-loader, e.g.. that allocate in pool memory.

Process Integrity

Process integrity checks process address spaces, process visibility, thread visibility, and usermode mappings of kernel or physical memory.
I specifically worked on this detection for my driverless bypass, so I would know how to hide it better.

What It Detects

• Kernel pages mapped into user processes
• Usermode physical memory windows
• Processes missing from normal system queries
• Threads missing from normal system queries
• Orphaned process address spaces
• Suspicious user mappings backed by kernel PFNs

Why It Matters

Anti-cheats often validate that processes and threads visible through one Windows path also appear through others.
If a process, thread, or address space exists in kernel structures but is hidden, it becomes a strong signal of tampering.

Object Integrity

Object integrity scans named kernel objects, sections, device links, driver objects, and dispatch surfaces.

What It Detects

• World-writable named sections
• Suspicious device object chains
• Devices owned by hidden or unloaded drivers
• Driver objects that do not match loaded modules
• Broad or memory-control-shaped IOCTL dispatch surfaces
• Dispatch routines outside the owning module
• Dispatch routines pointing to unknown memory
• Dispatch routines backed by suspicious PFNs
• Dispatch routines located in writable executable memory

Why It Matters

A kernel driver usually needs some way to communicate with usermode.
Anti-cheats scan to find drivers that expose suspicious controls or point their handlers into hidden code.

Service Integrity

Service integrity validates important kernel service pointers and service-table state.

What It Detects

• Service routine targets outside trusted kernel code
• Modified service table entries
• Kernel service pointers redirected into unknown memory
• Service routines backed by suspicious executable regions

Why It Matters

Service-table modification is a classic kernel hook technique.
Even if the hook target works correctly, the pointer itself can reveal that execution has been redirected away from the expected kernel image.

CPU Integrity

CPU integrity checks processor-level control structures and privileged execution targets.

What It Detects

• IDT handlers outside trusted code
• Processor MSR targets outside trusted code
• Syscall MSR targets outside kernel code
• CPU-controlled handlers redirected into unknown memory
• Processor entry points backed by suspicious PFNs

Why It Matters

Some kernel projects avoid normal hooks and instead modify hardware structures.
Anti-cheats can validate these targets directly because interrupt handlers, syscall entry points, and model-specific register targets have strict expectations.

DPC Integrity

DPC integrity scans Deferred Procedure Call objects and their execution targets.

What It Detects

• DPC targets outside trusted code
• DPC routines pointing into unknown memory
• DPC routines backed by suspicious PFNs
• Suspicious DPC object flags
• Deferred execution from memory that does not belong to a loaded module

Why It Matters

DPCs can be used to run code without creating a normal long-lived thread.
Anti-cheats can still inspect queued routines and validate whether their targets belong to legitimate kernel images.

Tutorial

This tutorial shows how to scan your kernel driver using UDE.
The recommended way to scan your project is by scanning before mapping your driver to compare detections.

1. Open ude.sln in Visual Studio 2022 or 2026.
   Make sure you have the Windows Driver Kit (WDK) installed before building the driver.
   

2. Enable a test certificate for the driver.
   In Visual Studio, right click the ude-driver project and open Properties.
   Go to Configuration Properties -> Driver Signing -> General and set:
   

   • Sign Mode: Test Sign
   • Test Certificate: create a new test certificate
   • Configuration: Release
   • Platform: x64

3. Build both projects in Release x64.
   Build ude-driver first, then build ude-usermode.
   

4. Open the build as Administrator.
   Run ude-usermode.exe ude-driver.sys from the build folder.
   

5. Press Continue when UDE opens.
   If test signing is not enabled, UDE will prompt you to enable it.
   After enabling test signing, restart Windows and run UDE again as Administrator.
   

6. Run a scan before mapping your own kernel driver.
   This tells you if UDE has any false positives before testing your driver.
   

7. Map your kernel driver, then run the same scans again.
   Any new detections after mapping are likely caused by your driver.
   Review the dashboard and ude-log.txt for the target, violation, method, address, and suggested fix.
   

Warning
After scanning, disable test signing and restart Windows before playing protected games.

detections.mp4

no.detections.mp4

Roadmap

• Add Changelog
• Finish Detection Categories
• Add Vulernable Driver Blocklist Check
• Add PatchGuard Context Check

Conclusion

Undetected Easy is a kernel detection scanner made to find driver detections before anti-cheats do.
Using recreated integrity checks from EasyAntiCheat, BattlEye, Vanguard, and similar anti-cheats.
So you can test your driver before exposing it to a real environment.
Found issues or want to contribute? Create an issue or contact me on Discord.