Divinity is a multi-purpose project windows kernel framework for driver mapping, communication and Dll injection.
It's personally my favorite mapper I've developed because it lets you perform operations that would be normally detected in your driver.
I've used Divinity for multiple projects like Nocturnal Hypervisor and Divinity Internal and it's been my best friend.
Table of Contents
Divinity was designed around legitimate backed memory, allowing it to perform operations that public projects cannot do because of anti-cheats.
The mapper allocates inside by splitting large pages backed by ntoskrnl.exe, allowing us to bypass memory range and stack walking checks.
The driver allocates process memory by injecting mirrored PML4 entries into the target, clone, and client address spaces.
Mapper - View Code
The mapper searches ntoskrnl.exe for unused large pages inside existing sections.
When the unused large page is found the mapper splits that large page into 4KB pages.
This gives the mapped driver backed executable memory.
Anti-cheats detect manually mapped drivers by scanning for executable memory that isn't backed by a known module. By splitting unused large pages inside ntoskrnl.exe's existing sections, the allocation inherits ntoskrnl's backing — making it appear as legitimate kernel module memory rather than an anonymous allocation. This defeats two common checks:
- Memory range checks — the address falls within ntoskrnl's known range
- Stack walking — execution traces back to a trusted module
Injector - View Code
The injector manual maps a Dll into the target process through the driver's hyperspace framework.
It allocates memory through hyperspace, resolves imports, maps missing dependencies, and executes DllMain through thread injection.
The hyperspace clones the target virtual address space and exposes the mapped pages into the client process.
Usermode writes to the addresses directly, while the driver mirrors the backing page-table entries into the target process.
This gives the injector a stable way to build the Dll image without constantly copying buffers through small read and write requests.
Traditional injection copies buffers repeatedly through read/write kernel requests, each one is an observable operation that anti-cheats can hook or count. By injecting mirrored PML4 entries, usermode writes directly to the target's backing pages without any API calls in the hot path.
- MmCopyMemory hooks — no copy APIs are called
- Write frequency — the buffer is built in one direct segment
- Page fault monitoring — pages are already mapped, no faults triggered
Allocation Caution
Portal allocations use injected PML4 entries and should be freed through free_virtual.
If the allocation is not released, the stale PML4E can cause bugchecks after the game closes.
The injector finds a target thread, suspends it, saves the current context, writes a small execution stub, and replaces Rip with the stub address.
The stub calls the mapped DLL's DllMain, reports execution status through the added .exec section, then jumps back to the original instruction pointer.
The injector watches the status fields and retries if the thread exits or times out during execution.
Driver - View Code
The driver is mapped into backed executable memory, so it can use PsCreateSystemThread for communication without needing a custom hidden thread.
We use a WNF state change subscription to receive the intialization data from the client process.
The WNF callback maps the client communication buffer, references the request and response semaphores, and initializes the shared control block.
After that, the system thread waits on the request semaphore, handles commands, and releases the response semaphore when each request completes.
Most drivers communicate via IOCTLs or named kernel threads, both are scanned by anti-cheats looking for device objects and threads executing from unknown modules. By using WNF state change subscriptions, callbacks appear as normal Windows notification activity with no device object or thread to find.
- Thread scanning — no kernel thread is created from an unsigned module
- Device object checks — no suspicious IOCTL device to enumerate
- Hook detection — WNF is a legitimate Windows mechanism, callbacks blend in
- Add large page backed allocation
- Add WNF client initialization
- Add hyperspace process cloning
- Add portal allocations
- Add recursive dependency mapping
- Add thread context execution
- Add screenshots for mapper, and injector
- Add portal allocation freeing before process closes ( will cause blue screens )
Divinity is a three piece framework for manual mapping kernel drivers through large pages, and manual mapping Dlls through hyperspacing.
The most important pieces are the large page allocator, hyperspace portal, and thread context hooking.
I love this project for the angle it takes on legitimate memory allocation and how it proved it's worthness through stress testing on multiple projects.