Undetected-Easy

KO | EN

gitlite — search

#docker #mcp #nodejs #pytorch #ai-agent #cpp #terminal #chatbot #awesome #kubernetes

Undetected-Easy

(★ 32)

Undetected Easy (UDE) is a detection scanner for finding detections before they catch you, using reversed routines from EasyAntiCheat, BattEye, e.g..

File Explorer

ZIP Download

- - defs.h
  - entry.h
  - types.h
- entrypoint.cxx
- includes.h
- ude-driver.vcxproj
- ude-driver.vcxproj.filters
- ude-driver.vcxproj.user
- - scan-failed.png
  - scan-success.png
  - shield.png
- includes.h
- main.cxx
- ude-usermode.vcxproj
- ude-usermode.vcxproj.filters
- ude-usermode.vcxproj.user
README.md
ude.sln

# Use via CDN

jsDelivr

jsDelivr serves any public GitHub repository as a CDN with zero setup. Pick a version and a file to get a ready-to-paste link and snippet.

Version

File

Link

Example

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

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**.

<details>
 <summary>Table of Contents</summary>
 <ol>
 <li><a href="#how-does-ude-work">How does UDE work?</a></li>
 <li><a href="#why-use-ude">Why use UDE?</a></li>
 <li><a href="#what-does-ude-detect">What does UDE detect?</a></li>
 <li><a href="#tutorial">Tutorial</a></li>
 <li><a href="#roadmap">Roadmap</a></li>
 <li><a href="#conclusion">Conclusion</a></li>
 </ol>
</details>

# 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.

<details>
 <summary>Module Integrity</summary>

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.

</details>

<details>
 <summary>Execution Integrity</summary>

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**.

</details>

<details>
 <summary>Memory Integrity</summary>

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..**.

</details>

<details>
 <summary>Pool Integrity</summary>

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.

</details>

<details>
 <summary>Process Integrity</summary>

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**.

</details>

<details>
 <summary>Object Integrity</summary>

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**.

</details>

<details>
 <summary>Service Integrity</summary>

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.

</details>

<details>
 <summary>CPU Integrity</summary>

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.

</details>

<details>
 <summary>DPC Integrity</summary>

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**.

</details>

# 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.

https://github.com/user-attachments/assets/f961544d-8c7e-4de9-b48e-0ffb615ed956

https://github.com/user-attachments/assets/b477a50b-409b-481a-afcd-d28c1b759b6f

## Roadmap
- [x] Add Changelog
- [x] 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.

Undetected-Easy

Owner Repos

File Explorer

# Use via CDN

Was this content helpful?

Recent Feedback

Undetected-Easy

Owner Repos

File Explorer

# Use via CDN

Was this content helpful?

Recent Feedback

Download README