The core idea: Read game memory from kernel space → Send data over USB → Draw on a $4 display.
No expensive FPGA DMA hardware. No PCIe cards. Just an ESP32, a small screen, and understanding how Windows memory works.
IMPORTANT: Game offsets change every update. Get fresh ones here:
100% Educational – Teaching Hardware-Assisted Memory Reading
This project demonstrates:
- How kernel memory reads bypass user-mode restrictions
- How to stream game data over USB to an external device
- How to render positions on a cheap SPI display
The technique is academically interesting. Don't be stupid with it.
Most game anti-cheats run in user mode (Ring 3). They hook Windows APIs like ReadProcessMemory. But they cannot block a kernel driver (Ring 0) from calling MmCopyVirtualMemory — that would break the OS.
So the chain is:
Educational Focus: External hardware-based radar using kernel read operations & serial display rendering.
FOR EDUCATIONAL PURPOSES ONLY.
This project demonstrates:
- Kernel → User → Hardware data flow
- External process memory reading via
MmCopyVirtualMemory - Real-time serial communication with embedded devices
- 2D map projection & rendering on a microcontroller
Behavior that is obviously inhuman (e.g., shooting through smokes consistently) can still lead to manual review. The educational value is in understanding the chain, not evading detection.
Game Memory (CS2)
↓
Kernel Driver (MmCopyVirtualMemory)
↓
User-Mode Client (Reads player positions)
↓
Serial (USB) to ESP32-S3
↓
ST7789 Display (Radar rendering)
- Kernel Driver – Runs at Ring 0, bypasses user-mode anti-cheat hooks. Uses Windows
MmCopyVirtualMemoryto read CS2’s process memory safely from kernel space. - User Client – Reads game data (local player, enemies, bomb state) using offsets from
cs2-dumper. Converts world coordinates to radar coordinates. - Serial Handshake – Client sends
RADAR_INITover COM port → ESP32 replies withRADAR_ACK→ data stream starts. - ESP32 Firmware – Receives player/bomb data over USB serial, projects onto 240x240 screen, draws dots/indicators.
- Display – ST7789 SPI screen shows:
- Green dot = you (or spectated player)
- Red dots = enemies
- A/B = bomb plant indicator (not 100% map-accurate)
- Microcontroller: ESP32-S3 (DevKitC or similar) running CircuitPython.
- Display: ST7789 1.3" or 1.54" IPS LCD (240x240).
- Code configured for Version 1.1 displays.
- Connection: USB-C data cable (serial communication).
- Wiring (educational – shows SPI protocol):
- CLK (SCL) → GPIO 12
- MOSI (SDA) → GPIO 11
- RES (Reset) → GPIO 9
- DC (Data/Command) → GPIO 8
- CS (Chip Select) → GPIO 10
CS2-Hardware-Radar/
├── NX - Driver/ # Kernel driver – demonstrates MmCopyVirtualMemory
│ ├── NXConnect [Signed]/ # Signed driver (loads if certificate trusted)
│ └── NXConnect [Unsigned]/ # Unsigned driver (requires manual mapping)
├── NXBase/ # User-mode app – reads memory, sends to serial
│ └── src/ # Coordinate conversion, handshake logic, offsets
└── NX - DMA [ESP32S3]/ # ESP32 Firmwares
├── NXRadar [Arduino]/ # Native C++ Arduino firmware (High FPS)
└── NXRadar [Circuitpython]/ # CircuitPython firmware (Easy to modify)
├── boot.py
├── code.py # Serial receive, rendering, projection math
└── lib/ # Adafruit libraries
User-mode anti-cheats hook Windows API calls like ReadProcessMemory. By reading memory from a kernel driver using MmCopyVirtualMemory, we bypass those hooks completely.
- Prerequisites:
- Visual Studio 2022 + Desktop development with C++
- Windows Driver Kit (WDK) – matches your Windows build
- Build: Release / x64 → generates
NXWire.sys - Loading (educational note):
- Signed driver → loads normally if certificate is trusted
- Unsigned → requires manual mapping (e.g., kdmapper) – this is fragile and purely for learning
What you learn here: How kernel memory reading works, why drivers have higher privilege, and why anti-cheats detect unsigned mappings.
The ESP32 acts as a dumb terminal – it receives data over USB and renders it. You can choose either the CircuitPython or Arduino (Native) firmware. Both are fully compatible with the same NXBase client thanks to a unified handshake protocol.
- Flash CircuitPython 9.x
.uf2to your ESP32-S3 via bootloader mode. - Copy
boot.py,code.pyand thelib/folder fromNX - DMA [ESP32S3]/NXRadar [Circuitpython]/to yourCIRCUITPYdrive. - The script will automatically run on boot, handling the serial read, coordinate math, and rendering.
- Open
NX - DMA [ESP32S3]/NXRadar [Arduino]/NXRadar.inoin the Arduino IDE. - Install the LovyanGFX library via the Arduino Library Manager.
- Select ESP32S3 Dev Module as your board.
- Set USB CDC On Boot: Enabled and USB Mode: Hardware CDC and JTAG in the Tools menu.
- Compile and upload to your ESP32-S3.
What you learn here: Real-time embedded rendering, SPI communication, coordinate projection.
- Update offsets using cs2-dumper
- Build Release / x64
- Run as Administrator (required for driver communication)
What you learn here: How to read external process memory, convert game coordinates to screen space, and implement a serial handshake.
- Connect ESP32 → USB → Shows:
"WAITING FOR PROGRAM..." - Load Kernel Driver → Grants read access to CS2 memory
- Launch CS2 → Enter a match
- Run Client (Admin) →
- Scans COM ports 1–20
- Sends
RADAR_INIT\n - Waits for
RADAR_ACK\n(2 sec timeout) - On success → streams player data
- ESP32 renders:
- World coordinates → screen pixels
- Center is always you (or spectated player)
- Rotation applied to match in-game forward direction
| Step | Direction | Data |
|---|---|---|
| 1 | ESP32 → PC | RADAR_READY\n (Beacon sent every 500ms until connected) |
| 2 | PC → ESP32 | RADAR_INIT\n |
| 3 | ESP32 → PC | RADAR_ACK\n |
| 4 | PC → ESP32 | Text-based player/bomb data (p,x,y,ang;e,...) |
This ensures the correct COM port is auto-detected seamlessly, regardless of which firmware (CircuitPython or Arduino) is loaded, and confirms the display is ready.
# Lower = Zoom In | Higher = Zoom Out
scale = (WIDTH / 2) / 2100.0 How it works: world units → pixels. 2100 is ~half the visible radius in game units.
# +50 moves player down (see more in front)
RADAR_CY = RADAR_Y_START + (RADAR_HEIGHT // 2) + 50 This shifts your dot, effectively changing what you see ahead vs. behind.
| Symptom | Likely Cause | What You Learn |
|---|---|---|
| Black screen | Wrong SPI wiring or missing libs | Hardware debugging |
| Windows crash | Outdated offsets | Memory structures change with game updates |
| No enemies | client_dll.hpp mismatch |
Game schema changes |
| COM port not found | Wrong baud or handshake mismatch | Serial protocol debugging |
Create out.txt on Desktop → client logs:
- COM port scan results
- Handshake success/failure
- Read errors
Useful for understanding the auto-detection flow.
| Component | Cost | Why it works |
|---|---|---|
| ESP32-S3 | ~$7 | USB native, fast enough for real-time rendering |
| ST7789 240x240 | ~$4 | SPI display – simple protocol to learn |
- 24AWG cables, 8cm
- Dupont lines, 10cm
- Mixed PCB set
- 2.54mm pin headers
Why optional: The educational core is software + wiring. Breadboards work fine for learning.
- Kernel vs. user mode memory access
- Windows driver development basics (
MmCopyVirtualMemory) - Reading external game memory using offsets
- Coordinate transformation (world → screen)
- Serial communication & handshake protocols
- Embedded rendering (CircuitPython + SPI display)
- Real-time data streaming over USB
This is not a "cheat" – it’s a hardware-assisted memory visualization tool built for learning OS, embedded, and game hacking countermeasures.
License & Ethics
Use this code only on systems you own, for educational research. Reverse engineering game memory violates almost all game EULAs. Understand the technique, don't abuse it.