Reverse Engineering CS2: What Source 2 Broke and What Still Works

Counter-Strike 2 is not a CS:GO patch. Valve rebuilt the client on Source 2, replaced the netvar system with a runtime schema, moved the entity list from a flat array into a slotted resource manager, and rewrote the rendering pipeline around a new SceneSystem. Reversers who came into CS2 expecting a shortened version of their CS:GO offset spreadsheet spent the first month realizing every foundation had shifted. This post walks through what actually changed, how to work with the new schema system, and what the client.dll offsets look like on the build 10000+ series (the current stable post the early 2025 armor rework).

Source 2 in one paragraph

Source 2 is Valve's engine rewrite that shipped in stages across Dota 2, Half-Life: Alyx, and finally CS2. It carries forward some CS:GO concepts (entity system, client-server split, VPK asset packing) but the runtime is meaningfully different. C++ classes have real reflection metadata (schema), the network protocol is protobuf-heavy, the render graph is data-driven, and the entire client is more decomposed into DLLs than the CS:GO monolith. For reversers, the practical consequences are that netvar dumping is obsolete, entity offsets require schema resolution, and many CS:GO-era pattern signatures no longer apply.

The schema system

The single biggest change for reversers is the schema system. In CS:GO, netvars were a fixed structure the client and server agreed on, and reversers dumped them by walking the RecvTable chain rooted at each client class. Netvar dumps have been public since 2013 and any CS:GO cheat consumed them.

CS2 replaced netvars with a runtime type system called schema. Classes are described by schema metadata objects (name, base class, field list, field offsets, field types) that live in the client DLL and are queryable at runtime through the SchemaSystem2_v1 interface. Field offsets are no longer static per build in a public sense; they are stable within a build but reverse-engineered by querying schema.

The schema query surface at runtime looks roughly like this:

struct CSchemaClassInfo {
    // opaque
};

struct CSchemaSystemTypeScope {
    void* FindDeclaredClass(const char* name);
    // ...
};

class ISchemaSystem {
public:
    virtual CSchemaSystemTypeScope* GlobalTypeScope() = 0;
    virtual CSchemaSystemTypeScope* FindTypeScopeForModule(const char* module) = 0;
    // ...
};

A reverser or cheat resolves offsets by asking schema for the class, then for a named field, and receiving an offset. Schema field names include m_iHealth, m_iTeamNum, m_hActiveWeapon, and so on, matching the CS:GO name conventions but resolved dynamically.

The mechanical implication: cheats no longer hardcode m_iHealth = 0x100. They query schema at cheat init and use the returned offset for the rest of the session. That is more resilient to Valve's patch cadence, since Valve can shuffle fields without breaking anything that queries by name.

The entry point at runtime is the exported g_pSchemaSystem global living in schemasystem.dll. Getting a class layout is a three-call sequence: GlobalTypeScope() (or FindTypeScopeForModule("client.dll") to constrain by module), FindDeclaredClass("CCSPlayerPawn") for the class info pointer, then a walk of the field list on the returned descriptor. Each field carries name, offset, type, and a categorization flag such as SCHEMA_FIELD_TYPE_BUILTIN or SCHEMA_FIELD_TYPE_PTR. Because the entire graph is dumpable in one pass, patch-day diffing collapses from a day of hand-walking RecvTable chains on CS:GO to roughly 15 minutes of schema-graph diffing on CS2. That single property is why CS2 is easier to reverse than its predecessor, not harder.

The entity system

CS:GO's EntityList was a flat array with a fixed slot count and predictable pointer chase. CS2 replaced it with a resource-managed system where entities are handles into a slotted allocator. Reading an entity by index looks like:

// Approximate sketch, not runnable
struct CEntityIdentity {
    void* m_pEntity;        // pointer to CBaseEntity
    uint32_t m_nameStringableIndex;
    uint32_t m_designerName;
    // ...
    CEntityIdentity* m_pPrev;
    CEntityIdentity* m_pNext;
};

struct CGameEntitySystem {
    CEntityIdentity* m_pIdentityChunks[64];   // 64 x 8192 slots
    int m_iMaxEntities;
    // ...
};

void* EntityByIndex(CGameEntitySystem* sys, int idx) {
    if (idx < 0 || idx >= sys->m_iMaxEntities) return nullptr;
    int chunk = (idx & 0x7FFF) >> 9;         // 512 slots per chunk
    int slot  = idx & 0x1FF;
    if (!sys->m_pIdentityChunks[chunk]) return nullptr;
    return (&sys->m_pIdentityChunks[chunk][slot])->m_pEntity;
}

The CGameEntitySystem global lives in client.dll and is reachable through the exported GameEntitySystem() function. Once you have it, iteration is a two-loop pattern: outer over chunks, inner over slots.

The controller/pawn split is the second structural change. CCSPlayerController represents the player identity (name, team, score) and lives on the client for every player. CCSPlayerPawn represents the active character in the round and is created and destroyed per round. Reads for round state go to the pawn; reads for persistent identity go to the controller. Cheats that read m_iHealth from the controller get nothing useful. It lives on the pawn.

SceneSystem and rendering

Source 2's rendering runs through SceneSystem, which manages render worlds, view descriptors, and the actual draw command stream. The reverser-relevant global for ESP work is the current view setup, which contains the world-to-projection matrix. Locating it: string-cross-reference "SceneSystem" or "CViewRender" in client.dll or rendersystemdx11.dll, walk to the singleton, and the view matrix is inside its per-frame view context.

The matrix is column-major in Source 2 (Source 1 was row-major), which trips up reversers coming from CS:GO. Adjust the world-to-screen accordingly:

// Column-major variant for Source 2
bool WorldToScreenS2(const Vec3& w, const float m[16],
                     int sw, int sh, Vec2& out) {
    float cx = w.x*m[0] + w.y*m[4] + w.z*m[8]  + m[12];
    float cy = w.x*m[1] + w.y*m[5] + w.z*m[9]  + m[13];
    float cw = w.x*m[3] + w.y*m[7] + w.z*m[11] + m[15];
    if (cw < 0.001f) return false;
    out.x = sw*0.5f + (cx/cw)*sw*0.5f;
    out.y = sh*0.5f - (cy/cw)*sh*0.5f;
    return true;
}

The DLL split

CS2 spreads the client across many more DLLs than CS:GO. The ones that matter for reversing:

A reverser working on ESP touches client.dll, engine2.dll, and rendersystemdx11.dll. A reverser working on weapon logic stays mostly in client.dll.

Interface versioning across the CS:GO to CS2 jump

The engine interface layer looks unchanged on the surface. CreateInterface still lives at the top of each DLL and clients still request interfaces by name-plus-version string. Behind that surface, the CS2 migration reshuffled almost every interface. VClient018 and VEngineClient014 are gone. Source2Client002 and Source2EngineToClient001 replaced them. A small number of legacy Source 1 interfaces (VStdioTextConsole003, VFileSystem017) stayed at their pre-existing version numbers because Valve's own internal tooling still consumed them and rewriting was not on the CS2 critical path.

Any offset guide that hardcodes a phrase like "engine2 interface X is at version 3" is one Valve patch away from binding to the wrong vtable. The correct read is to enumerate at runtime: walk the s_pInterfaceRegs linked list rooted at each module's CreateInterface export, collect the (name, factory) pairs, and filter to what you actually need. KyTech CS2's interface resolver runs that enumeration on process attach and stores the name-to-vtable mapping in a lookup table that the rest of the cheat consumes, an indirection that has quietly absorbed two Valve interface renames since launch without any manual patch on our side.

Panorama and why cheat authors ignore it

Panorama is Valve's UI framework, shared with Dota 2, and it drives the CS2 main menu, buy menu, scoreboard, and HUD. It lives in panorama.dll and panoramauiclient.dll, rendering through JavaScript-authored .xml and .js files loaded from the game's panorama/ resource tree. Reversers occasionally poke at Panorama when they want draw calls that composite with the native HUD, but the common pattern is to bypass it and draw through the D3D11 device directly or via an ImGui overlay on the swap chain.

Panorama panels are not authoritative for anything the round cares about; they mirror data pushed from the C++ side and lag behind the source of truth. The same fields are readable upstream from client.dll at lower latency and without the JS event loop in the path, so draw cheats live outside Panorama and read directly from the entity system.

The build 10000+ armor rework

The early-2025 armor rework (starting around build 10000) restructured CCSPlayerPawn's armor and health handling. The m_ArmorValue field moved, m_bHasHelmet moved, and the accessor functions were inlined into a small number of call sites instead of the diffuse pattern that existed on the 9000-series builds. Any offset table that was not regenerated across the build 10000 boundary silently corrupted armor reads for weeks in the wild.

Schema queries survived the change transparently. Hardcoded offsets did not. This is the practical argument for schema-first workflows and it is why every 2026 CS2 cheat that has stayed alive is doing schema resolution at runtime.

The reverser workflow

For a fresh build:

1. Grab the new client.dll and companions. Hash and version-tag.
2. Auto-analyze in IDA. Load Valve's own PDB if you have it (rarely available; do not assume).
3. Locate SchemaSystem2_v1 interface via string cross-reference on "SchemaSystem2_v1".
4. Enumerate schema at runtime through the interface, dumping class names and field offsets.
5. Write the enumeration output to a per-build offset cache.
6. Verify a small set of known offsets (health, team, origin) against a live game session on a burner account.
7. Ship the offset cache to production.

Steps 1 through 5 take about 15 minutes. Step 6 is the one that catches structural changes.

For diffing across builds, the story is the same as any other Source-family title: BinDiff or Diaphora, with the specific note that schema-resolved offsets do not diff meaningfully because the schema itself is the source of truth. The interesting diff is on the functions that consume those offsets, since Valve occasionally adds new fields that shift downstream logic.

What CS2 broke that people miss

• Netvar dumps. Public CS:GO netvar dumps served the community for a decade. They are useless on CS2. Schema is the replacement.
• EntityList walks. The flat array is gone. Slotted allocator with chunks is the replacement.
• Row-major matrices. Column-major is the CS2 convention. Row-major reads produce garbage.
• Monolithic client.dll. Rendering moved out to rendersystemdx11.dll. Old signatures that assumed everything was in client.dll fail on CS2.
• Frame-static offsets for network state. Client/pawn split means round state and persistent state live in different objects.

What still works

• RTTI mining. Source 2 keeps RTTI on, same as Apex, same as most modern MSVC games. The techniques from our RTTI post apply directly.
• String cross-references. Source 2 kept its debug logging strings intact. "CClientState", "SceneSystem", "CCSPlayerPawn" all resolve to their originating functions.
• IDA and Ghidra as tools. Neither changed. The workflow is the same, the target is different.
• BinDiff and Diaphora for patch-day diffing. Both still produce clean function mappings across CS2 builds when the codegen options do not shift dramatically.

Further reading

• Valve's VAC overview covers the anti-cheat that ships alongside CS2 and gates every schema query a live cheat performs.
• Our VAC in 2026 post walks through how VAC actually operates against kernel-mode cheats in the post-CS2 era.
• Our Apex Legends reversing writeup is the sister case study for a different Source-family title where RTTI-first workflows still dominate.

How KyTech handles this

The KyTech CS2 product, detailed on the KyTech CS2 product page, runs on top of the schema-first workflow described in this post. Every offset we care about is resolved through schema at cheat init, with a fallback cache for the rare classes where schema does not expose what we need directly. Our internal per-build validation catches structural changes on the day of each Valve patch, and the shared kernel driver (the same one that services our Apex, Overwatch 2, BO7, Forza Horizon 6, and Roblox products) handles the memory read layer without touching the CS2 process itself.

CS2 offsets are inherently more stable than they look because schema absorbs most of Valve's patch drift. What is not stable is the render pipeline, since Valve iterates SceneSystem more aggressively than they iterate the entity system. KyTech's render-side integration re-validates on every patch, which is the reason CS2 ships without the sort of "boxes floating one frame behind the enemy" bug that dogged early public CS2 cheats. The current lineup and product status on the purchase page. The HWID spoofer beta is Apex-only for now, not because CS2 doesn't need one, but because per-title spoofer engineering is not copy-paste across anti-cheats.