cs2-dumper: reading Counter-Strike 2 offsets out of process memory with memflow

An external dumper, which is the whole architectural choice

The README describes the project in one line: an external offset and interface dumper for Counter-Strike 2, supporting both Windows and Linux, powered by memflow. That first word, external, carries most of the design. The tool is a separate process that reads the game's memory rather than a component injected into the game, and it does that through memflow, which is a memory introspection framework with pluggable connectors.

Because the tool is external, it needs the game to actually be running. The usage section is two steps: ensure Counter-Strike 2 is running, with being in the main menu enough, and run the `cs2-dumper` executable. There is no attach step, no injection and no config file.

The repository is small and shaped like a Rust binary crate should be. The tree is `src/`, `Cargo.toml`, `output/`, a `cs2-dumper.log` file, `LICENSE`, and `.github/`. The edition is 2024, the version field reads 0.1.3, and the MIT licence is declared in both the manifest and a LICENSE file. Building from source needs Rust 1.74.0 or newer, which is worth noting because the 2024 edition will not compile on anything older. There is a separate `linux` branch for a native Linux build, which the README marks as currently outdated, so the memflow route is the current answer on Linux.

Connectors decide how memory gets read, and they decide your privileges

The single most useful paragraph in the README is the one about connectors. If you run the executable without specifying a connector name, it uses memflow-native, the OS layer, to read the game process's memory. If you want something else you pass a name and optional arguments:

+cs2-dumper -c pcileech -a :device=FPGA -vv
+

The named connectors mentioned are pcileech and kvm, both installed and managed through the memflowup tool. The interesting consequence is the privilege requirement: the kvm connector on Linux and the pcileech and winio connectors on Windows need elevated privileges, so the tool has to run under sudo on Linux or as administrator on Windows. That is a consequence of reading another process's address space through hardware rather than an OS API, and it is the reason a connector choice is not just a performance knob.

There is also a separate project for the offline path, cs2-analyzer, which the README describes as work in progress, with a web demo included in that repository. The distinction matters: cs2-dumper walks a live process, cs2-analyzer works on something already captured. If your workflow is capture once and analyse repeatedly, that is the other repository.

Every argument is documented, including the ones people forget

The available arguments list is the best documented part of any reverse engineering tool README, and this one does not skimp. There is a connector name, connector arguments, file types, indent size, output directory, process name, verbosity, help and version.

The two with real consequences are the file type filter and the process name. The file types argument controls which languages get generated, defaulting to `cs`, `hpp`, `json`, `rs` and `zig`, so by default one run produces a C header, a C++ header, JSON for tooling, a Rust file and a Zig file. The process name defaults to `cs2.exe`, which is the Windows name, so on Linux you either pass `-p` or accept whatever the connector resolves. The output directory defaults to `output`, matching the directory in the tree.

Verbosity is a repeatable `-v`, and the example line in the README passes it twice, which is how you see what the analysis is doing when the offsets come out wrong. Indent size defaults to 4 spaces, which matters if you are feeding the output into a project with its own formatting conventions.

The dependency list is short enough to audit in one sitting

The Cargo manifest is small, which is a good sign for a tool that reads process memory. `anyhow` for errors, `clap` with the derive feature for the CLI, `chrono` with serde for timestamps, `heck` for case conversion, `log` with `simplelog` for logging, `memflow` at 0.2 for the introspection layer, `pelite` at 0.10 for PE parsing, `phf` with macros for perfect hash maps, and `serde` plus `serde_json` for output. Windows gets one extra dependency, memflow-native, pulled directly from git.

Two things in there are worth calling out. The `phf` crate with the macros feature suggests offsets and similar constant tables are compiled into hash maps, which is the right structure for the lookup heavy part of a dumper. And `pelite` being there means the tool parses PE headers rather than relying on an external tool, so a run produces its output without shelling out.

The profile section is also unusual and deliberate. Development builds use `opt-level = 1` at the top level but `opt-level = 3` for every dependency, so the dependencies are compiled optimised while your own code stays quick to rebuild. Release builds enable LTO and strip the binary. For a tool that walks megabytes of memory looking for patterns, that profile split is the difference between a usable iteration loop and a frustrating one.

Release history, and what 0.1.2 says about the design

There are three releases. 0.1.1 on 2024-05-24 has an empty body, 0.1.2 on 2024-07-29 lists real changes, and 0.1.3 on 2026-01-25 says only "Bug fixes" without elaborating.

The 0.1.2 notes are the informative ones and they describe a tool adapting to its dependency and to its users. It was updated for memflow 0.2.2. Generated file names had periods replaced with underscores, specifically so the output is easier to include in a build. Program execution now continues if analysis fails at any point, which is the single most important line in those notes for anyone using this against a game that updates without warning. The custom error type was dropped in favour of anyhow, logging to cs2-dumper.log was added, and it became compilable on Linux, which is why there is now a linux branch to point at.

Keeping going after a failed analysis step is the right call for this category of tool and it is worth reading as a design commitment rather than a bug tolerance. An offset dumper walking a game binary will hit something it does not recognise the day the game patches, and a tool that aborts on the first unknown pattern gives you nothing that run, while one that logs and continues gives you most of the offsets and a log entry telling you which one is missing.

The project is not archived, has 2,375 stars, 356 forks and 11 open issues, and the last push was 2026-09-26. There is a `cargo test -- --nocapture` command for the few basic tests, which is a modest but honest test story for a tool whose real testing happens against a live game.

Editorial conclusion

cs2-dumper is narrow on purpose and the narrowness is its main quality. It does one thing, it names its dependencies plainly, and the CLI surface is documented argument by argument so there is nothing to guess at. What it does not do is make the offsets stay valid: the dependency on the game being at the main menu, the connector privilege requirement and the branch split are all consequences of a game that changes under you. The 0.1.2 release notes are the best guide to its character, since a dumper that keeps going when analysis fails instead of aborting is built for a moving target. Start with the release binary rather than compiling, pass a connector name if memflow-native is not what you want, and read the cs2-analyzer repository if you would rather analyse a memory image offline than dump a live process.

Frequently asked questions

Official sources

1. a2x/cs2-dumper on GitHub
2. Issues
3. License: MIT
4. README
5. Releases