
A generic game/software hacking tool written from the ground up in Rust.
Join us on our Discord Channel
Squalr is a highly performant dynamic analysis reverse-engineering tool written in Rust.
First and foremost, Squalr is a lightning fast memory scanner, allowing the user to search for and modify running process memory. Fast scans are achieved through multi-threading combined with SIMD, allowing it to rip through multiple GBs of data in seconds. While all CPUs are supported, for maximum performance your CPU needs support for SSE, AVX, or AVX-512.
Dynamic analysis is a first-class citizen in Squalr, unlike most reverse-engineering tools. This allows for workflows that simply are not possible otherwise by analyzing how a program behaves over time.
Squalr is a spiritual successor to Squalr-Sharp. Looking for the old C# repo? See Squalr-Sharp. Note that Squalr-Sharp is no longer maintained, as Squalr has become the focus.
This project is unaffiliated with any employers of our team members, past, present, or future.

Squalr can be used as a desktop app, a terminal tool, an Android app, or as Rust crates for custom scanning workflows.
Use this when you want the full interactive workflow: process selection, element scans, array/string scans, pointer scans, the memory viewer, project files, symbol layouts, and plugin-backed tooling.
| Platform | GUI | CLI | TUI | Remote (Host) | Remote (Shell) |
|---|---|---|---|---|---|
| Windows | ✅ | ✅ | ✅ | ✅ | ✅ |
| Linux | ✅ | ✅ | ✅ | ✅ | ✅ |
| Mac | ✅ | ✅ | ✅ | ✅ | ✅ |
| Android (Rooted) | ✅ | ✅ | ✅ | ❌ | ✅ |
| iPhone (Not Available Yet) | ✅ | ✅ | ✅ | ❌ | ✅ |
Plugins are the path for extending Squalr's behavior. Existing plugin crates cover built-in plugins, 24-bit data types, instruction providers, binary symbols, and Dolphin memory-view routing. The medium-term goal is for plugins to extend data types, project item types, virtual modules, middleware, and tools without requiring changes to the core app.
Scripting is planned, but there is not yet a stable public scripting surface.
Use the crates directly when you want to embed pieces of Squalr instead of running a Squalr frontend. Pick the layer based on how much of the workflow you want Squalr to own.
| Consumer | You bring | Squalr provides | Crates |
|---|---|---|---|
| Byte scanner | Your own bytes, snapshots, files, emulator dumps, or captured memory buffers. | Scan plans, data types, snapshot structures, scan execution, and result filters. | squalr-engine-api, squalr-engine-scanning |
| Custom target integrator | Your own target implementation, such as an emulator, debugger, remote agent, trace recorder, or sandbox. | Stable target traits for memory maps, reads, writes, modules, and target handles. | squalr-engine-api, squalr-engine-targets, squalr-engine-scanning |
| Native process scanner | A local process you want Squalr to enumerate, open, read, write, and scan. | Native Windows/macOS/Linux/Android target access plus the scanner crates. | squalr-engine-api, squalr-engine-targets, squalr-engine-targets-native, squalr-engine-scanning |
| Squalr frontend or automation shell | A GUI, CLI, TUI, bot, or command runner that wants the normal Squalr workflow. | Session state, command dispatch, app-level orchestration, target I/O coordination, scans, projects, and responses. | squalr-engine-session, squalr-engine |
| Command-line adapter | A CLI, REPL, remote shell, or script bridge that wants user-entered command lines lowered into engine commands. | Command grammar, aliases, help/version handling, and conversion into shared command models. | squalr-engine-api |
| Project and symbol tooling | Tools that need to read, write, inspect, or transform Squalr projects. | Project files, symbol catalogs, layouts, locators, and shared data models. | squalr-engine-api, squalr-engine-projects |
squalr-engine-api is the shared model crate. It contains the public data types that the other layers speak: scan plans, values, snapshots, results, commands, symbols, and project-facing structures.
If you already own the bytes, stay in the byte scanner layer: construct SnapshotRegion values, wrap them in a Snapshot, and call ElementScanner::scan_snapshot. This path does not need a process handle or native target backend.
If you want to scan a real process, keep target I/O and scanning as separate phases. Use squalr-engine-targets for the abstraction, squalr-engine-targets-native when you want Squalr's native backend, and feed the collected memory into squalr-engine-scanning.
If you want the full Squalr app workflow, use the session/command crates instead of assembling the lower layers yourself. That path is for consumers who want Squalr to coordinate target access, scans, projects, and responses.
Systems level work demands a systems level language. Rust was chosen because it eliminates entire classes of bugs and is perfectly suited to the job.
After evaluating several front-end frameworks, we settled on egui. Egui gives us small binary sizes, native speeds, cross-platform, and ease of accessing application data for display.
Medium term, Squalr aims to be extensible with a modern plugin system. No more unzipping plugins to esoteric locations and manually upgrading them each release. This means an actual marketplace, including plenty of free and easy to install plugins. While not there yet, Squalr is being developed knowing that developers will want to be able to extend the type system, project system, register custom tools, and register middleware to support scanning emulator memory or other niche use cases.
Additionally, we will soon want to support scripting. We have not yet decided on a language. While most people instantly jump to Lua or Python, these languages lack robust data types, which results in awkward work-arounds. Consequentially, it is unclear what we intend to use instead, or if there are viable alternatives at all.
Eventually Squalr will eventually compete on the static front, but not initially. For now, Squalr is deliberately not building out an ASM to C++ decompiler, a code graph, nor a debugger.
Long term, we do wish to integrate into the AI landscape, in a manner that actually delivers value to users. These are a few ideas that we intend to try: