DXComm - DirectX Shared Surface Kernel-User Communication

A proof-of-concept implementation demonstrating novel inter-ring communication between kernel and user mode using DirectX shared GPU surfaces. This method provides an alternative IPC channel that operates through graphics memory, bypassing traditional kernel communication mechanisms.

Overview

Traditional kernel-user communication relies on well-known mechanisms like IOCTLs, shared memory sections, or callbacks. DXComm explores a different approach: leveraging DirectX's shared resource capabilities to establish a bidirectional communication channel through GPU-accessible memory.

The technique uses Direct3D 11 shared textures as a communication buffer. The usermode application creates a shared DirectX surface and passes its handle to the kernel driver, which maps the same GPU memory into kernel address space. Both sides can then read and write to this shared region to exchange commands and data.

Architecture

Components

Kernel Driver (KernelDriver)

• WDM-based kernel driver that registers a device object (\Device\DXComm)
• Receives shared surface handles via IOCTL
• Maps DirectX shared resources into kernel virtual address space
• Processes commands from usermode (read/write memory operations)
• Writes responses back to the shared surface

Usermode Client (UserMode)

• DirectX 11-based client application
• Creates shared texture with D3D11_RESOURCE_MISC_SHARED_NTHANDLE flag
• Manages staging texture for CPU read/write access
• Implements command/response protocol over shared surface
• Provides high-level API for memory operations

Shared Protocol (common.h)

• Defines communication structures (Command, Response)
• Memory layout specification for shared buffer
• Synchronization primitives (commandReady, responseReady flags)

Technical Details

DirectX Shared Surfaces

The implementation uses a 4096x4096 RGBA texture (64MB total) as the communication buffer. This provides substantial bandwidth for command/response exchange.

Usermode Creation:

D3D11_TEXTURE2D_DESC desc = {};
desc.Width = 4096;
desc.Height = 4096;
desc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;
desc.MiscFlags = D3D11_RESOURCE_MISC_SHARED_NTHANDLE | D3D11_RESOURCE_MISC_SHARED;

The D3D11_RESOURCE_MISC_SHARED_NTHANDLE flag enables NT handle-based sharing, which provides better security and lifetime management compared to legacy shared handles.

Handle Sharing:

The shared handle is obtained via IDXGIResource1::CreateSharedHandle() and passed to the kernel driver. This handle represents the underlying DirectX allocation and can be opened by the kernel.

Kernel Mapping:

The kernel driver uses undocumented D3DKMT (DirectX Kernel Mode Thunk) functions to map the shared resource. The implementation:

1. Resolves D3DKMT Functions at Runtime: Enumerates loaded kernel modules to find dxgkrnl.sys, parses its export table, and resolves function pointers:

   • D3DKMTOpenAdapterFromLuid() - Opens DirectX adapter in kernel mode
   • D3DKMTCreateDevice() - Creates a kernel-mode DirectX device
   • D3DKMTOpenResourceFromNtHandle() - Opens the shared resource from usermode NT handle
   • D3DKMTLock2() - Locks the GPU allocation and returns a CPU-accessible pointer
   • D3DKMTUnlock2() - Unlocks the allocation

2. Maps the Shared Surface:

   • Opens the default GPU adapter
   • Creates a kernel-mode DirectX device context
   • Opens the shared resource using the NT handle from usermode
   • Locks the allocation to obtain a kernel virtual address pointing to the GPU memory
   • Both kernel and usermode now have pointers to the same physical GPU memory

Synchronization

The implementation uses simple spin-lock style synchronization with volatile flags:

• commandReady - Set by usermode when command is written
• responseReady - Set by kernel when response is ready

This POC uses polling with sleep intervals. Production implementations could use keyed mutexes (D3D11_RESOURCE_MISC_SHARED_KEYEDMUTEX) for proper GPU-level synchronization.

Memory Access

The POC demonstrates read/write operations on the calling process's own memory for safety. The kernel driver uses SEH (Structured Exception Handling) to safely access memory addresses:

__try {
    RtlCopyMemory(destination, source, size);
} __except (EXCEPTION_EXECUTE_HANDLER) {
    // Handle access violation
}

Building

Prerequisites

• Visual Studio 2022
• Windows Driver Kit (WDK) 10
• Windows 10 SDK

Build Steps

1. Open DXComm.sln in Visual Studio 2022
2. Select configuration (Debug or Release) and platform (x64)
3. Build Solution (Ctrl+Shift+B)

The build outputs:

• bin\x64\Debug\KernelDriver.sys - Kernel driver
• bin\x64\Debug\UserMode.exe - Usermode client

Installation and Usage

Driver Installation

1. Enable Test Signing (Administrator command prompt):

bcdedit /set testsigning on

Reboot after enabling test signing.

2. Create Driver Service:

sc create DXComm type=kernel binPath="C:\full\path\to\KernelDriver.sys"

3. Start Driver:

sc start DXComm

4. Verify Driver Loaded:

sc query DXComm

Running the Client

Once the driver is loaded:

UserMode.exe

The client will:

• Initialize DirectX 11
• Create shared surface
• Register with kernel driver
• Run test suite (heartbeat, memory read/write, performance)
• Display results

Expected Output

========================================
  DXComm - DirectX Kernel Communication
  POC Implementation
========================================

[+] driver handle opened successfully
[*] initializing DirectX communicator...
[+] DirectX initialized successfully
[*] registering shared surface with kernel driver...
[+] shared surface registered successfully

[*] running heartbeat test...
[+] heartbeat successful

[*] running self memory read/write test...
[*] original test data:
42 45 48 4b 4e 51 54 57 5a 5d 60 63 66 69 6c 6f
...
[+] all tests passed!

Technical Limitations

1. GPU Dependency: Requires DirectX 11-capable GPU
2. Driver Signing: Requires test signing or proper code signing certificate
3. Performance: Polling-based synchronization introduces latency (1-2ms average)
4. Platform: Windows 10+ only (D3D11_RESOURCE_MISC_SHARED_NTHANDLE)
5. Adapter Selection: Currently opens default GPU adapter (LUID 0:0). Multi-GPU systems may require adapter matching between usermode and kernel
6. D3DKMT Functions: Uses undocumented APIs that may change between Windows versions

Research Context

This POC demonstrates a novel IPC technique for security research purposes, including:

• Anti-cheat system evaluation
• Kernel communication method analysis
• GPU-based covert channels
• Alternative IPC mechanism research

The implementation is intentionally simplified to demonstrate the core concept. Production use would require significant hardening and optimization.

References

• Direct3D 11 Shared Resources: https://docs.microsoft.com/en-us/windows/win32/direct3d11/overviews-direct3d-11-resources-shared
• DXGI Shared Resources: https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/d3d10-graphics-programming-guide-dxgi
• D3DKMT Functions: Undocumented, reverse-engineered

License

This is a proof-of-concept for security research and educational purposes. Use responsibly and only in authorized testing environments.