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 → usermod