Arbitrary Memory Read/Write in Portwell Engineering Toolkits Driver

This repository is a small standalone Windows C++ proof-of-concept exploit for CVE-2026-3437 affecting Portwell Engineering Toolkits v4.8.2. It is not part of a larger exploit framework. The repository contains build/configuration files (CMake, VS Code tasks, presets), a README describing the vulnerability and usage, and two source files implementing the exploit logic. Core exploit behavior is split across src/entry.cpp and src/portwell.hpp. The header defines the vulnerable device path (\\.\PORTWELL_0_1), two IOCTL codes (0xEA606450 for read and 0xEA60A454 for write), request structures, and helper routines that wrap CreateFileW and DeviceIoControl. The exploit opens a handle to the driver and sends crafted buffers that specify a physical address, access width, and byte count. The read primitive returns arbitrary physical memory contents into a caller-supplied buffer; the write primitive allocates a request buffer containing the header plus attacker-controlled data and sends it to the driver. The sample entry point demonstrates the capability by reading a 32-bit value from physical address 0x1000, overwriting it with 0x1337, and reading it back. There is no automated privilege-escalation chain, token stealing, shell spawning, or persistence logic in the code; instead, it provides the low-level arbitrary physical memory R/W primitive that could be used to build LPE or BYOVD workflows. Because the payload is functional but basic and hardcoded, the maturity is best classified as OPERATIONAL rather than WEAPONIZED.

This repository is a small standalone Windows C++ proof-of-concept exploit for CVE-2026-3437 affecting Portwell Engineering Toolkits v4.8.2. It is not part of a larger exploit framework. The project is built with CMake and contains one main executable source file, src/entry.cpp, plus a helper header, src/portwell.hpp, that implements the exploit logic. Repository structure is minimal: build configuration files (.vscode, CMakeLists.txt, CMakePresets.json), a README describing the vulnerability and usage, and two source files. The actual exploit logic resides in src/portwell.hpp. That header defines the device path \\.\PORTWELL_0_1, two IOCTL codes for read and write, request structures for the driver protocol, and helper functions to initialize the device handle and perform read_phys/write_phys operations using DeviceIoControl. The exploit capability is arbitrary physical memory access from user mode through the vulnerable signed driver. The code constructs a 16-byte physical-memory request header containing a target physical address, access width, and byte count. For reads, it sends the header with IOCTL 0xEA606450 and receives raw bytes into a caller-supplied buffer. For writes, it appends attacker-controlled data after the header and sends it with IOCTL 0xEA60A454. The README explicitly states this stems from unsafe use of MmMapIoSpace without proper validation, enabling local privilege escalation and BYOVD scenarios. The main program in src/entry.cpp is a demonstration payload rather than a full privilege-escalation chain. It opens the device, reads 4 bytes from physical address 0x1000, writes the value 0x1337 to that same physical address, and reads it back to confirm success. There is no automated token stealing, shell spawning, or SYSTEM process creation; instead, it exposes and demonstrates the core primitive needed for further exploitation. Because it includes working exploit code with a hardcoded demonstration target and no generalized post-exploitation automation, the maturity is best classified as OPERATIONAL.