Radar Cheats Explained: Minimap Overlays and Position-Only Reads

Radar cheats are the smallest thing you can build that still wins games. One memory read per tick, one dot on a second monitor, no code injected into the game process. That minimalism is the entire pitch: less surface area for anti-cheat to notice, less rendering to hide, less math to get wrong.

This post walks through how a modern radar external actually works on Windows 11 24H2, why it survives longer than a full ESP overlay, and where it still gets caught. It also covers where KyTech sits in this category (spoiler: we do not currently ship a radar-only SKU, and there is a reason).

What a radar cheat actually reads

A radar cheat reads two things per entity: a world-space position and a team identifier. That is it. No bone matrices, no view matrix, no health, no weapon, no visibility flag. Compare that to a full ESP, which typically pulls skeleton bones, hitboxes, held weapon, current health, shield state, view angles, and derived world-to-screen coordinates for every player.

In Apex Legends Season 25 (current at the time of writing), the relevant per-entity data lives at fixed offsets inside the CPlayer / CBaseCombatCharacter blob. A radar external only needs the m_vecOrigin field (an XYZ float triple) and the team number byte. On a sixty-player lobby that is roughly 60 entities times 16 bytes, under a kilobyte per tick.

Counter-Strike 2 (build 10000+ on the Source 2 engine) exposes similar structure through the client DLL. Radar tools polling CCSPlayerController and CCSPlayerPawn need only origin and team affiliation for the enemy list. Overwatch 2 and Call of Duty Black Ops 7 follow the same broad shape, differing only in offset stability across patches.

That tiny read pattern is the whole reason radar cheats are dangerous to anti-cheat vendors: there is very little for a hypervisor-backed telemetry system to notice.

The data plane: one read per tick

The typical radar architecture on Windows is a two-process design plus a kernel component:

1. A signed kernel driver, either a [legitimately-signed third-party driver turned against itself](/blog/signed-driver-abuse chain-bring-your-own-vulnerable-driver) or a custom-signed one on a compromised leaked certificate, exposes a read primitive.
2. A user-mode collector process opens a handle to the driver and issues one IOCTL per tick.
3. A separate renderer draws dots on a window.

The driver side is minimal. In a signed-third-party-driver build the primitive is usually a wrapper around MmCopyVirtualMemory, targeting the game process by PID:

NTSTATUS ReadTargetMemory(HANDLE targetPid, PVOID targetAddr,
                          PVOID buffer, SIZE_T size)
{
    PEPROCESS target = NULL;
    NTSTATUS s = PsLookupProcessByProcessId(targetPid, &target);
    if (!NT_SUCCESS(s)) return s;

    SIZE_T bytesRead = 0;
    s = MmCopyVirtualMemory(target, targetAddr,
                            PsGetCurrentProcess(), buffer,
                            size, KernelMode, &bytesRead);
    ObDereferenceObject(target);
    return s;
}

Compared to a full ESP that pulls bones and matrices every frame at 240 Hz, a radar reads a flat position array at 30 to 60 Hz. The kernel-side read volume drops by more than an order of magnitude, and the access pattern is a single contiguous block per player entity rather than scattered chases through bone tables.

The user-mode polling loop is equally boring:

struct EntityDot {
    float x, y, z;
    uint8_t team;
};

static EntityDot dots[MAX_ENTS];

for (;;) {
    uintptr_t list = ReadU64(driver, entityListPtr);
    for (int i = 0; i < MAX_ENTS; ++i) {
        uintptr_t ent = ReadU64(driver, list + i * 8);
        if (!ent) continue;
        ReadBytes(driver, ent + OFF_ORIGIN,
                  &dots[i].x, sizeof(float) * 3);
        ReadBytes(driver, ent + OFF_TEAM,
                  &dots[i].team, 1);
    }
    PushToRenderer(dots, MAX_ENTS);
    Sleep(16); // ~60 Hz
}

No view matrix. No bones. No screen projection. If the collector process crashes, the game keeps running and the user loses their radar. Nothing gets injected into r5apex.exe or cs2.exe; the game process is a passive victim of a read.

Rendering out of process

Radar overlays never render into the game window. That is deliberate. Rendering into the game window means either DirectX hooking (a bright red flag for Easy Anti-Cheat and BattlEye) or a layered top-most window that Vanguard, Ricochet, and modern EAC will enumerate and complain about.

The two common layouts:

+---------------------------------------------------------+
| MAIN MONITOR                    | SECOND MONITOR        |
|                                 |                       |
|   [   Game in fullscreen   ]    |   +---------------+   |
|                                 |   |    RADAR      |   |
|                                 |   |               |   |
|                                 |   |   o     .     |   |
|                                 |   |      x        |   |
|                                 |   |   .     o     |   |
|                                 |   +---------------+   |
+---------------------------------------------------------+
    x = you   o = teammate   . = enemy

That is the second-monitor layout. The radar window lives on a display the game engine never sees. Anti-cheat can enumerate top-level windows on the same session all it wants; the radar is not over the game.

The other layout uses a separate machine on the same LAN. The collector still runs on the gaming PC, but pushes coordinates over a socket to a laptop running the renderer. This is the layout used by streamers and cheat resellers demoing product without appearing on their own capture.

Stream-safe variants

The stream angle is worth its own section because it is a real product category. Streamers who cheat need to avoid two problems: OBS accidentally capturing the overlay, and NVIDIA ShadowPlay clips catching it.

The mitigations, in decreasing order of paranoia:

• Separate machine over LAN. The radar renderer runs on a different physical PC. Nothing the streaming PC captures can contain it. This is the setup that catches operators when the second PC ends up visible in a webcam angle.
• Capture-blocked window. On Windows 10 2004 and later, SetWindowDisplayAffinity(hwnd, WDA_EXCLUDEFROMCAPTURE) marks a window as invisible to BitBlt, DWM thumbnails, PrintWindow, and Windows Graphics Capture. OBS renders it as a black rectangle. That is a real Microsoft API, documented on Microsoft Learn, and it is the same primitive used by DRM apps like Netflix in browsers.
• Second monitor plus scene composition. OBS is told to capture only the primary display. Works until the streamer alt-tabs and drags the wrong window.

The KyTech position on stream-safe features: we do not build them. Selling a "hide from OBS" checkbox is selling a feature whose only market is people trying to appear honest while cheating on camera. That is a distinct customer we choose not to serve.

Why radars outlive full ESP

Every anti-cheat telemetry system in 2026 is looking for the same broad signals: unusual read patterns against the game process, foreign code executing in the game's address space, GDI/DirectX overlays composited on top, and behavioral anomalies from the input stream.

A radar external is nearly invisible on the first three:

• Read pattern. One contiguous block per entity, per tick, at low frequency. Full ESP walks bone tables, dereferences model pointers, and often follows chained pointers through the entity system dozens of times per frame. Ricochet's driver in Call of Duty has been public since 2021 about tracking read frequency and correlation to enemy positions; the higher the polling rate, the harder it is to hide.
• In-process code. Zero. The game process has no injected DLL, no manually mapped image, no hooked function. PsSetLoadImageNotifyRoutine callbacks see nothing unusual because nothing is loaded.
• Overlay compositing. The radar window is not composited onto the game surface. EnumWindows from inside the game process finds no top-most transparent layered window over it.

Compare to a full ESP with world-to-screen boxes: it either injects into the game (visible to anti-cheat load-image callbacks) or renders a layered top-most window over the game (visible to window enumeration). It reads the view matrix every frame (a hot, known offset that anti-cheat can trip-wire). It performs projection math whose output correlates suspiciously with on-screen enemy positions.

The gap in survival time between "radar only" and "full ESP with aimbot" builds against Apex, CS2, and Overwatch 2 in 2026 is real and measurable in weeks, sometimes months.

Where radars still get caught

Radars are not undetectable. The vectors that still work:

Behavioral pre-fire and pre-aim. Server-side, every modern anti-cheat records where a player is looking relative to enemies they cannot see. If a player consistently pre-aims doorways where an enemy is standing behind cover, the distribution of view angles over time diverges from human distributions. Riot Vanguard has publicly discussed shipping this class of detection since 2020; Ricochet's server-side behavioral analytics in Warzone since 2022 catches radar users specifically because they turn to face invisible enemies too consistently.

Grenade lineups on nothing. In CS2, throwing a smoke or a flash at the exact spot an enemy is about to walk into, repeatedly, across matches, is a distinctive signal. There is no legitimate way to know that.

Second-machine detection is not the anti-cheat's job. Vendors cannot easily see a second PC on a LAN. Their behavioral pipeline does not care. It sees the outcome (turning to face pre-nade, pre-peek) and does not need to know how.

HWID and hardware fingerprinting. Once behavioral analytics flags an account, the ban attaches to hardware. Every current mainstream anti-cheat (BattlEye, EAC after the Epic acquisition in 2018, Vanguard which added TPM 2.0 as a hard requirement for League of Legends in 2024, Ricochet, and Byfron for Roblox after the 2022 acquisition) does some form of hardware ID lock. That is the actual reason our HWID spoofer exists. For the higher-utility category comparison, read our ESP and wallhack explainer.

Radar vs full ESP: the tradeoff

The tradeoff is between utility per read and read volume. Here is how the two shake out on the metrics that matter:

The utility gap is real. A radar tells a player where enemies are and roughly what they are doing (rotating, holding an angle, pushing). It does not aim for them. Skilled players get more out of a radar than casual players do, which is the inverse of the aimbot dynamic.

A note on kernel access on 24H2

The whole architecture above assumes some form of kernel read primitive. Windows 11 24H2 broke a class of signed-third-party-driver builds that relied on MmMapIoSpace to alias write-back kernel pages as non-cached user memory. The MiShowBadMapper check inside the memory manager now refuses that alias on write-back pages, killing any driver that walked page tables from user space by mapping physical memory back through the manager. That change did not affect drivers using MmCopyVirtualMemory directly, which is why the radar architecture above still works in 2026 while several public cheat frameworks that relied on the older primitive silently died over 2025.

If a build ships with HVCI enabled by default (which is now the case on all new consumer 24H2 preinstalls), unsigned driver loading is off the table entirely, and the operator has to rely on either a leaked signed certificate or a vulnerability in an existing signed driver. VBS raises the bar further by moving certain security-critical structures out of reach of a compromised kernel. The economics of that pipeline are why the radar category has consolidated to a small number of well-capitalized operators, KyTech among them.

How KyTech handles this

KyTech launched in 2025 and is run by a two-person engineering team. Our stack is a signed kernel driver plus a game-specific user-mode layer, and we currently ship for Apex Legends, Counter-Strike 2, Overwatch 2, Call of Duty Black Ops 7, Forza Horizon 6, and Roblox.

We do not currently ship a radar-only SKU. Every KyTech product is a full-feature build that includes positional data because ESP needs it anyway, and we would rather ship one well-tested driver than fragment the surface area across a radar-only edition, a full-ESP edition, and an aim-assist edition. Users who want radar-only behavior can toggle everything else off in the menu, and several of our Apex users do exactly that during ranked play. The flagship KyTech Apex build is where this shows up in production; radar is one of several visualizations sitting on top of the same entity read pipeline described above.

The HWID spoofer is currently in beta and Apex Legends only. We have not extended it to CS2, Overwatch 2, BO7, FH6, or Roblox yet; the fingerprinting each anti-cheat performs differs enough that a general spoofer is not a copy-paste job across titles. If you want to see the full catalog and current status, visit our purchase page.

We do not build stream-hiding features. If a customer wants to cheat on camera and pretend otherwise, they can pick a different vendor. What KyTech will build is a driver that survives the ban wave a customer paid to survive, and a support channel that answers when a signature gets burned.