XMA Developer API: Firmware-Level Memory Access

In this technical demonstration, we showcase a second-PC radar overlay for CS (CS) built on XMA(eXtended Memory Access). Unlike traditional DMA solutions that rely on kernel drivers or vulnerable software interfaces, XMA operates entirely at the firmware level, giving unfiltered access to physical and virtual memory while bypassing modern Windows security mechanisms.

The key innovation is the underlying XMA platform: it enables sophisticated second-PC applications with unprecedented memory access, all without touching the target OS or kernel.

What is XMA?

XMA is a firmware-backed memory introspection framework with a clean, developer-first API. It abstracts hardware complexity and exposes high-level functions for memory operations, process/module discovery, and PE parsing.

Architecture Overview

1. Firmware layer: custom UEFI that establishes raw memory access.
2. Bridge layer (optional): transports XMA protocol over data transmission protocols; omit entirely for some setups.
3. Client library: XmaCore.dll exposes the API to applications.

Single-PC operation: identical API when running locally — no second PC or bridge required for development and testing.

Ready to build on XMA? Reach out on Discord and we’ll set you up with a purchasable dev build and current SDK access. We’ll hand you a bridge endpoint (or single-PC mode) plus the pieces you need to start reading memory in minutes.

1. Message us on Discord — we provision dev access and your build.
2. Pick transport: single-PC (local) or bridge.
3. Drop in XmaCore.dll and call the API (C/C++/Python).
4. If migrating from existing 2PC DMA tools, shims route calls automatically.

We keep engagement details streamlined: you get dev access to build your solution, and when you need customer-ready firmware, we handle per-build packaging on our side.

Initialization

// C / C++: connect to XMA over your chosen transport
bool success = XmaInitialize(connection_string, timeout);

Endpoint format is flexible; same API in single-PC mode or multi-system deployments.

Core Memory Operations

uint8_t buffer[4096];
bool ok = XmaReadPhysical(0x1000000, buffer, sizeof(buffer));
XmaWritePhysical(0x1000000, data_buffer, data_size);
XmaReadPhysicalScatter(entries_array, entry_count);

uint32_t pid = 1234;
uint64_t va = 0x7FFE0000;
XmaReadVirtual(pid, va, buffer, sizeof(buffer));
XmaWriteVirtual(pid, va, data_buffer, data_size);
XmaReadVirtualScatter(pid, entries_array, entry_count);

Process + Module Operations

uint8_t proc_buffer[64 * 1024];
uint32_t count = XmaListProcesses(proc_buffer, sizeof(proc_buffer));

uint32_t pid;
bool found = XmaFindProcess("CS.exe", &pid);

ProcessInfo info;
XmaGetProcessInfo(pid, &info); // CR3, EPROCESS, base, etc.

uint8_t mod_buffer[128 * 1024];
uint32_t mod_count = XmaListModules(pid, mod_buffer, sizeof(mod_buffer));

uint8_t export_buffer[256 * 1024];
uint32_t export_count = XmaGetModuleEat(pid, "client.dll", export_buffer, sizeof(export_buffer));

uint32_t import_count = XmaGetModuleIat(pid, "client.dll", import_buffer, sizeof(import_buffer));
uint32_t section_count = XmaGetModuleSections(pid, "client.dll", section_buffer, sizeof(section_buffer));

Advanced Features

uint8_t vad_buffer[256 * 1024];
uint32_t vad_count = XmaListVads(pid, vad_buffer, sizeof(vad_buffer));

uint64_t physical_addr;
bool ok = XmaVirt2Phys(pid, 0x7FFE0000, &physical_addr);

uint8_t driver_buffer[256 * 1024];
uint32_t driver_count = XmaEnumerateKernelDrivers(driver_buffer, sizeof(driver_buffer));

uint64_t driver_base, driver_size;
bool found = XmaFindKernelDriver("ntoskrnl.exe", &driver_base, &driver_size);

OSVersionInfo os_info;
XmaGetOsVersion(&os_info); // build, PDB GUID, age, etc.

Complete API Reference

Python Integration

from ctypes import *

xma = CDLL("XmaCore.dll")

xma.XmaInitialize.argtypes = [c_char_p, c_uint32]
xma.XmaInitialize.restype = c_bool
xma.XmaInitialize(b"connection_string", timeout)

buffer = (c_uint8 * 4096)()
xma.XmaReadVirtual.argtypes = [c_uint32, c_uint64, c_void_p, c_uint32]
xma.XmaReadVirtual.restype = c_bool
xma.XmaReadVirtual(1234, 0x7FFE0000, buffer, 4096)

proc_buffer = (c_uint8 * 65536)()
xma.XmaListProcesses.argtypes = [c_void_p, c_uint32]
xma.XmaListProcesses.restype = c_uint32
count = xma.XmaListProcesses(proc_buffer, 65536)

Dev Package Snapshot

Use shims when you need drop-in compatibility with existing 2PC DMA software; skip them for new code that directly targetsXmaCore.dll.

Shims are useful when:

• Software expects vmm.dll or leechcore.dll.
• You want zero code changes for migration.
• You need a drop-in replacement while moving to XMA.

VmmShim and LeechCoreShim

• VmmShim (vmm_shim.dll): drop-in for vmm.dll; redirects VMMDLL calls to XMA.
• LeechCoreShim (leechcore_shim.dll): drop-in for leechcore.dll; LeechCore API compatibility.

Usage

1. Build/download shims from the XMA tools.
2. Rename: vmm_shim.dll → vmm.dll; leechcore_shim.dll → leechcore.dll.
3. Place alongside the target application (replace originals).
4. No device argument changes needed — existing 2PC software works as-is.
5. Run; calls are redirected to XMA automatically.

A Python/C++ radar overlay shows how little code is needed with XMA — the same approach applies to any target process. This path is IOMMU/VT-d safe because XMA operates pre-policy at firmware level.

Architecture

• XMA Core (Python/C/C++/C#/Rust) — connects to XMA bridge, reads CS memory.
• Overlay Renderer — draws player positions, health, weapons.
• Game State Parser — extracts entities, positions, view angles.

Key Implementation Details (Python / C++)

# Find CS process
pid = xma_client.find_process("CS.exe")

# Base + CR3
process_info = xma_client.get_process_info(pid)
cr3 = process_info.cr3
base_address = process_info.base_address

# client.dll
modules = xma_client.list_modules(pid)
client_dll = next(m for m in modules if "client.dll" in m.name.lower())
client_base = client_dll.base_address

# Entity list + local player
entity_list_addr = client_base + offset_entity_list
entity_list = xma_client.read_virtual(pid, entity_list_addr, 8)

local_player_addr = client_base + offset_local_player
local_player = xma_client.read_virtual(pid, local_player_addr, 8)

# Per-entity reads
for entity in entities:
    origin = xma_client.read_virtual(pid, entity + offset_vector_origin, 12)
    health = xma_client.read_virtual(pid, entity + offset_player_health, 4)
    # render on overlay

• Initialization: ~100 ms (connection establishment).
• Process enumeration: ~10 ms (firmware-side caching).
• Module discovery: ~10 ms (firmware-side caching).
• Reads: sub-1 ms on tuned wired links; scatter cuts RTT further.
• Throughput: 30–900 Mbps depending on transport and cabling.
• Scatter: sub-1 ms for ~100 batched reads in one round-trip (lightning fast).

Tuned wired links deliver local-network latencies; firmware caching and scatter calls avoid repeated walks and round-trips.

• No kernel drivers, no process injection, no API hooks.
• Firmware-level access leaves no software traces.
• No PCI hardware required in the target machine.
• Configurable transport; protocol abstracted from the app layer.

Security software and kernel telemetry operate above the firmware boundary where XMA lives; the bridge (when used) is opaque to the guest OS.

Want access, examples, or a quick walkthrough? Reach out on Discord and we’ll provision an endpoint (or single-PC setup), plus send the latest SDK build.

XMA delivers firmware-level memory introspection with a clean, developer-friendly surface. The CS radar is one example; the same toolkit supports security research, reverse engineering, performance monitoring, development, and forensics.

XMA developer tools include: XmaCore.dll, single-PC mode, VmmShim/LeechCoreShim (optional), Python samples, documentation, tutorials, and Secure Boot non-bootstart solutions. Bulk build discounting is available for commercial deployments.

XMA — eXtended Memory Access. Firmware-level memory introspection for the modern era.