ETOC - Every Type Of Communication

A comprehensive demonstration of kernel-mode to user-mode communication methods for Windows driver development, reverse engineering, and game hacking applications. This is a vast generalization, and there are about 50 million ways to communicate data between kernelmode and usermode, but this repo gives you the ability to have a starter to work with.

Overview

ETOC is a repository showcasing various inter-process communication (IPC) techniques between Windows kernel drivers and usermode applications. Each implementation demonstrates a different communication method with complete, working examples suitable for game hacking, anti-cheat bypass research, and reverse engineering projects.

Architecture

┌─────────────────────────────────────┐
│         Usermode Application        │
│  (communication.cpp + main.cpp)     │
└─────────────────┬───────────────────┘
                  │
                  │ Various IPC Methods
                  │
┌─────────────────▼───────────────────┐
│         Kernel-Mode Driver          │
│     (Method-Specific Driver)        │
└─────────────────────────────────────┘

The usermode application uses a unified interface with region-based implementations - simply define the appropriate preprocessor flag to switch between communication methods.

Communication Methods

Method	Status	Description	Use Case
IOCTL	Implemented	Device control codes via DeviceIoControl	Standard driver communication, command/response patterns
Shared Memory	Implemented	Session objects mapped between KM/UM	Zero-copy data transfer, high-performance scenarios
Named Pipes	Implemented	Read/write operations with buffering	Stream-based data transfer, sequential I/O
Registry Keys	Implemented	Persistent storage via Windows registry	Configuration data, persistent state management
File System	Implemented	File I/O operations for data exchange	Persistent storage, logging, configuration files
Direct Memory	Implemented	Kernel process context attachment	Direct usermode memory access from kernel
Kernel Hook	Implemented	Inline function hooking for interception	Stealth communication, anti-cheat bypass
Callbacks	Planned	Registered user callbacks	Event notifications from kernel
ALPC	Planned	Advanced Local Procedure Call	Secure inter-process messaging
Sockets	Planned	Winsock Kernel (WSK)	Network-style communication

Project Structure

ETOC/
├── README.md                           # This file
├── Shared/
│   └── common.h                        # Shared structures and constants
├── IOCTL/                              # IOCTL-based communication driver
│   ├── driver.c                        # Driver implementation
│   ├── driver.h                        # Driver header
│   ├── IOCTL.inf                      # Driver installation file
│   └── IOCTL.vcxproj                  # Driver project
├── SharedMemSessionObjects/            # Shared memory communication driver
│   ├── driver.c                        # Driver implementation
│   ├── driver.h                        # Driver header
│   ├── SharedMemSessionObjects.inf    # Driver installation file
│   └── SharedMemSessionObjects.vcxproj # Driver project
├── NamedPipes/                         # Named pipes communication driver
│   ├── driver.c                        # Driver implementation
│   ├── driver.h                        # Driver header
│   ├── NamedPipes.inf                 # Driver installation file
│   └── NamedPipes.vcxproj             # Driver project
├── RegistryKeys/                       # Registry keys communication driver
│   ├── driver.c                        # Driver implementation
│   ├── driver.h                        # Driver header
│   ├── RegistryKeys.inf               # Driver installation file
│   └── RegistryKeys.vcxproj           # Driver project
├── FileSystem/                         # File system communication driver
│   ├── driver.c                        # Driver implementation
│   ├── driver.h                        # Driver header
│   ├── FileSystem.inf                 # Driver installation file
│   └── FileSystem.vcxproj             # Driver project
├── DirectMemory/                       # Direct memory communication driver
│   ├── driver.c                        # Driver implementation
│   ├── driver.h                        # Driver header
│   ├── DirectMemory.inf               # Driver installation file
│   └── DirectMemory.vcxproj           # Driver project
├── KernelHook/                         # Kernel hook communication driver
│   ├── driver.c                        # Driver implementation
│   ├── driver.h                        # Driver header
│   ├── KernelHook.inf                 # Driver installation file
│   └── KernelHook.vcxproj             # Driver project
└── Usermode/                           # Usermode test application
    ├── communication.h                 # Communication interface
    ├── communication.cpp               # Region-based implementations
    ├── main.cpp                        # Test application
    └── Usermode.vcxproj               # Usermode project

Building

Requirements

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

Build Steps

1. Open ETOC.sln in Visual Studio 2022

2. Select the communication method by editing Usermode/communication.cpp:

   • Uncomment the desired #define USE_<METHOD> at the top

3. Build the solution:

   • Right-click solution → Build Solution
   • Or press Ctrl+Shift+B

4. The outputs will be:

   • Driver: x64/Debug/<Method>/<Method>.sys
   • Usermode: x64/Debug/Usermode.exe

Usage

1. Install the Driver

For test signing (development only):

bcdedit /set testsigning on
# Reboot required

Install the driver:

# Navigate to driver output directory
sc create <DriverName> type=kernel binPath="<full path to .sys file>"
sc start <DriverName>

2. Run Usermode Application

cd x64/Debug
Usermode.exe

The application will:

• Connect to the driver using the selected communication method
• Send test data
• Receive and validate the response
• Display results

3. Uninstall Driver

sc stop <DriverName>
sc delete <DriverName>

IOCTL Implementation

Driver Side

• Creates device: \\Device\\ETOCDevice
• Creates symbolic link: \\??\\ETOCLink
• Handles IOCTL_ETOC_SEND_DATA control code
• Echoes received data back to usermode

Usermode Side

• Opens device via \\\\.\\ETOCLink
• Sends data using DeviceIoControl
• Receives response in output buffer

Control Codes

#define IOCTL_ETOC_SEND_DATA \
    CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS)

Shared Memory Implementation

Driver Side

• Creates section object: \\BaseNamedObjects\\ETOCSharedSection
• Maps section into kernel address space
• Processes requests by monitoring shared buffer flags
• Uses interlocked operations for synchronization

Usermode Side

• Opens device for control operations
• Maps same section object into user address space
• Writes request data directly to shared memory
• Uses IOCTL_ETOC_PROCESS_REQUEST to signal driver
• Polls response flag for completion

Synchronization

typedef struct _SHARED_COMM_BUFFER {
    volatile LONG requestReady;
    volatile LONG responseReady;
    ETOC_REQUEST request;
    ETOC_RESPONSE response;
} SHARED_COMM_BUFFER;

Zero-copy data transfer - data written once to shared memory, accessible to both kernel and usermode without additional copying.

Named Pipes Implementation

Driver Side

• Creates device with read/write support
• Implements IRP_MJ_READ and IRP_MJ_WRITE handlers
• Maintains internal buffer for stream-based communication
• Uses spinlock for synchronization

Usermode Side

• Opens device for read/write operations
• Writes request data using WriteFile
• Reads response data using ReadFile
• Natural stream-based interface

Data Flow

Usermode calls WriteFile to send data → driver stores in internal buffer → usermode calls ReadFile to retrieve data → driver returns buffered content.

Registry Keys Implementation

Driver Side

• Creates registry key at \Registry\Machine\Software\ETOC
• Handles IOCTL_ETOC_PROCESS_REQUEST to trigger processing
• Reads request from "Request" registry value
• Processes data and writes response to "Response" registry value

Usermode Side

• Opens device for IOCTL operations
• Opens registry key at HKEY_LOCAL_MACHINE\Software\ETOC
• Writes request data to "Request" value using RegSetValueEx
• Signals driver via IOCTL to process request
• Reads response from "Response" value using RegQueryValueEx

Note: Usermode application must run with administrator privileges to access HKEY_LOCAL_MACHINE with write permissions.

Data Flow

Usermode writes ETOC_REQUEST to registry value → usermode signals driver via IOCTL → driver reads from registry, processes, writes response → usermode reads ETOC_RESPONSE from registry value.

Persistent storage - data persists in registry between reboots and can be used for configuration or state management.

File System Implementation

Driver Side

• Creates directory C:\ETOC if it doesn't exist
• Handles IOCTL_ETOC_PROCESS_REQUEST to trigger processing
• Reads request from C:\ETOC\request.bin file
• Processes data and writes response to C:\ETOC\response.bin file

Usermode Side

• Opens device for IOCTL operations
• Creates directory C:\ETOC if needed
• Writes request data to C:\ETOC\request.bin using WriteFile
• Signals driver via IOCTL to process request
• Reads response from C:\ETOC\response.bin using ReadFile

Data Flow

Usermode writes ETOC_REQUEST to file → usermode signals driver via IOCTL → driver reads from file, processes, writes response to file → usermode reads ETOC_RESPONSE from file.

Persistent storage - data persists on disk and can be used for logging, configuration, or data exchange between processes.

Direct Memory Implementation

Driver Side

• Handles IOCTL_ETOC_DIRECT_MEMORY to trigger processing
• Receives process ID and usermode buffer addresses from usermode
• Uses PsLookupProcessByProcessId to get target process object
• Attaches to process context using KeStackAttachProcess
• Uses ProbeForRead and ProbeForWrite to validate usermode addresses
• Reads request directly from usermode buffer using RtlCopyMemory
• Writes response directly to usermode buffer
• Detaches from process using KeUnstackDetachProcess

Usermode Side

• Opens device for IOCTL operations
• Allocates local buffers for ETOC_REQUEST and ETOC_RESPONSE
• Passes PID and buffer addresses to driver via IOCTL_ETOC_DIRECT_MEMORY
• Driver directly accesses usermode memory from kernel context

Data Flow

Usermode allocates buffers → usermode sends IOCTL with PID and buffer pointers → driver attaches to process context → driver directly reads/writes usermode memory → driver detaches from process.

Direct memory access - kernel driver attaches to usermode process context to directly read and write process memory without copying to kernel buffers.

Kernel Hook Implementation

Driver Side

• Hooks EtwEventWrite kernel function
• Writes 14-byte absolute jump to redirect execution to hook handler
• Uses ZwProtectVirtualMemory for page protection modification
• Processes intercepted calls containing communication buffer
• Passes through legitimate calls to original function

Usermode Side

• Loads win32u.dll and resolves NtOpenCompositionSurfaceSectionInfo
• Calls syscall with pointer to HOOK_COMM_BUFFER
• Syscall internally triggers EtwEventWrite which hits the hook
• Receives processed data directly in buffer

Data Flow

Usermode calls NtOpenCompositionSurfaceSectionInfo → syscall triggers EtwEventWrite → hook intercepts → driver extracts buffer from UserData[0].Ptr → driver processes request → driver writes response to buffer → hook returns to usermode.

Inline hook communication - demonstrates function hooking for stealthy kernel-usermode data exchange without traditional device objects, leveraging Windows syscall infrastructure for anti-cheat bypass scenarios.

Extending the Project

To add a new communication method:

1. Create a new driver project in its own directory
2. Add a new #pragma region in communication.cpp
3. Implement the communication functions
4. Update this README with method details
5. Add to the communication methods table

Security Considerations

Important: These implementations are for reverse engineering and research purposes. Production use requires:

• Proper input validation
• Security descriptors on device objects
• Least privilege access controls
• Comprehensive error handling
• Thorough testing

License

This is research code. Use at your own risk.

Contributing

Feel free to:

• Add new communication methods
• Improve existing implementations
• Fix bugs or documentation issues
• Suggest optimizations

References

• Windows Driver Kit Documentation
• Kernel-Mode Driver Architecture
• IOCTL Implementation Guide