RnW-Drv Framework — Saku Grossarth

Three-Tier Architecture

RnW-Drv uses a layered design that separates kernel access from user interface through a well-defined API:

┌─────────────────┐
│  Python GUI     │  User interface with tkinter
│  (frontend.py)  │  Handles user interactions
└────────┬────────┘
         │ HTTP API (localhost:8080)
         ▼
┌─────────────────┐
│  Backend Server │  C++ HTTP server
│  (backend.cpp) │  Bridges user/kernel
└────────┬────────┘
         │ IOCTL
         ▼
┌─────────────────┐
│  RnW-Drv        │  Kernel driver
│  (kernel)       │  Memory R/W operations
└─────────────────┘

Layer 1: Kernel Driver

The kernel driver provides primitive memory operations:

ReadProcessMemory — Read at arbitrary address
WriteProcessMemory — Write at arbitrary address
GetProcessBase — Main module base address
EnumerateProcesses — List running processes

Driver Design

Unlike stealth-focused drivers, RnW-Drv is designed for usability:

Traditional IOCTL interface
Device object \Device\RnWDrv
Symbolic link for user access
Handles are validated but not aggressively restricted

Layer 2: Backend Server

The C++ backend bridges the kernel driver to HTTP:

HTTP API

Endpoint	Method	Description
/processes	GET	List all processes
/attach	POST	Attach to process by PID/name
/read	POST	Read memory at address
/write	POST	Write value to address
/status	GET	Server/driver status

Example Request

POST /read
{
  "pid": 1234,
  "address": "0x7FF6A0000000",
  "type": "int32"
}

Response:
{
  "value": 12345,
  "success": true
}

Using HTTP as the inter-process protocol makes the system language-agnostic. The Python frontend could be replaced with a web UI, mobile app, or automation scripts without changing the kernel driver.

Layer 3: Python Frontend

The GUI provides a user-friendly interface built with tkinter:

Features

Process List — Searchable process browser
Memory Editor — Read/write with type selection
Watch Mode — Continuous monitoring of address
History Log — Operation history with undo

Data Types Supported

Integers: int8, int16, int32, int64
Unsigned: uint8, uint16, uint32, uint64
Float: float, double
Other: bool, char, bytes16, string32

Why This Architecture?

Separation of Concerns

Each layer has a single responsibility:

Driver: Raw memory operations
Backend: Protocol translation and session management
Frontend: User interface

Language Flexibility

The HTTP API allows the frontend to be rewritten in any language without touching kernel code. This is valuable for:

Web-based interfaces
Automation scripts
Third-party integrations

Safety

The backend can implement additional validations before passing requests to the kernel:

Address range validation
Rate limiting
Audit logging
Permission checks

Comparison to Direct Driver Access

Aspect	Direct Driver	RnW-Drv System
Speed	Fastest	Fast
Safety	Low	Medium
Ease of Use	Hard	Easy
Flexibility	Limited	High
Remote Access	No	Possible

Building and Running

Driver

# Build with WDK
cd RnW-Drv
# Open in Visual Studio with WDK, build Release|x64

# Load with kdmapper
kdmapper.exe RnW-Drv.sys

Backend

# Compile backend
cd Standard/Usermode
cl backend_server_simple.cpp ws2_32.lib

# Run
backend_server_simple.exe

Frontend

# Install dependencies
pip install requests

# Run
python frontend.py

What I Learned

This project taught me about designing APIs that cross privilege boundaries. The HTTP layer seems like overhead but provides valuable abstraction: the kernel driver stays simple while the backend handles complexity like session management and request validation.

The multi-language approach (C++ driver, C++ server, Python client) is more maintainable than a monolithic C++ solution. Each language is used where it excels: C++ for kernel/driver code, Python for UI.

Use Cases

Game Modification — Edit game memory values
Research — Analyze application memory layout
Debugging — Alternative to Cheat Engine
Education — Learn about process memory