Squalr

Squalr Official Website

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.

Usage

Squalr can be used as a desktop app, a terminal tool, an Android app, or as Rust crates for custom scanning workflows.

Standalone App

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.

Plugins and Extensions

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.

Squalr as a Library

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.

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.

Development Philosophy

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: - Plaintext hacking. Just tell the agent what you want to hack over a normal conversation, and have it dispatch low-level commands to do the heavy lifting. This can be very effective in domains like video game reverse-engineering. - Automated data symbol discovery. By analyzing how values change over snapshots in time, analyzing screenshots, etc., we believe that agents can help you build a full map of all data and functions in a process. - Low-latency local models. We want developers to be able to make bots that can take in screen data, memory data, and run this in a rapid enough loop to do everything from play games, to navigate desktop software, without exessive delays.

Features

Builds

• [X] Desktop GUI build.
• [X] Android GUI build.
• [X] CLI build.
• [X] TUI build.

Developer-Facing Features

• [ ] Command/event hooks
• [ ] Plugin system: Data Types
• [X] Plugin system: Middleware (Filters for emu support, filter down virtual memory through custom logic)
• [X] Plugin system: Virtual Modules (custom defined static bases -- could be threadstack, special emulator memory regions, etc)
• [X] Plugin system: Project item types
• [ ] Scripting system (exact language TBD)

User-Facing Features

• [X] Primitive scans
• [X] Array scans, including arrays of primitives (ie u8[], i32[], string_utf8[])
• [X] String scans
• [X] Struct viewer
• [X] Dockable window system
• [ ] Struct scans
• [X] Pointer scans
• [X] Project system

Linux Build

Linux builds are validated with these entrypoints: - cargo build -p squalr-cli --locked - cargo build -p squalr-tui --locked - cargo build -p squalr --locked

Install native dependencies before building: - pkg-config - libasound2-dev - libudev-dev - libxkbcommon-dev - libwayland-dev - libx11-dev - libxcursor-dev - libxi-dev - libxrandr-dev - libxinerama-dev

Android Build

Android builds are currently validated on target aarch64-linux-android with API level 30.

Quickstart: APK on Device (Privileged GUI Path)

Goal: install the GUI APK, push the privileged worker, and run the GUI in rooted IPC mode.

Prerequisites: - Android SDK + NDK installed. - ANDROID_HOME set. - ANDROID_NDK_ROOT set. - Rust Android target installed: rustup target add aarch64-linux-android. - Cargo helpers installed: - cargo install cargo-ndk - Rooted device connected over adb.

Then run one of these from the workspace root: - python ./scripts/build_and_deploy.py (full smoke validation: preflight + build + install + launch + IPC worker check) - python ./scripts/build_and_deploy.py --compile-check (automated compile-only path: preflight + Android Rust builds + GameActivity APK packaging, no device required) - To launch an already-installed APK without rebuilding: python ./scripts/run_apk.py - To manually run the privileged worker shell for debugging: python ./scripts/debug_run_privileged_shell.py

Notes: - The deploy script runs host preflight checks (ANDROID_HOME, ANDROID_NDK_ROOT, target installation, and aarch64-linux-android-clang visibility), then runs: - cargo ndk --target aarch64-linux-android build -p squalr-cli - cargo ndk --target aarch64-linux-android build -p squalr - The GUI APK is packaged as a generated Gradle project under target/android-gameactivity-gradle, using androidx.games:games-activity so Android soft-input state is handled by GameActivity instead of NativeActivity. - The GUI uses a workspace patch for winit 0.30.13 under third_party/winit-0.30.13. The patch keeps upstream Android key-event handling, forwards GameActivity text commits into egui's normal key-text path, suppresses duplicate printable key events while the IME is active, and clears the hidden GameActivity text buffer after each commit. - The deploy script uses a pinned local Gradle distribution under target/android-gradle for GameActivity packaging. To override this, set SQUALR_ANDROID_GRADLE to a compatible Gradle executable. - In full smoke mode, the script installs the APK, pushes /data/local/tmp/squalr-cli, runs su -c chmod +x, launches the app, and validates privileged worker startup. - Running without flags prompts: Build in release mode? (y/n [default]). - Non-interactive environments should pass --release or --debug to avoid the prompt. - --release prefers release artifacts; if release signing is not configured ([package.metadata.android.signing.release]), APK build automatically falls back to debug. - If adb install fails on a previous install, uninstall first: - adb uninstall com.squalr.android

Common preflight failure example:

> rustup target list --installed
aarch64-linux-android
wasm32-unknown-unknown
x86_64-pc-windows-msvc
ANDROID_NDK_ROOT is not set.

If this appears, set ANDROID_NDK_ROOT to your Android NDK path and rerun the script.

macOS Build

macOS builds are validated with these entrypoints: - cargo build -p squalr-cli --locked - cargo build -p squalr-tui --locked - cargo build -p squalr --locked

Run targets: - CLI: cargo run -p squalr-cli -- process list -w -l 20 - TUI: cargo run -p squalr-tui - GUI: cargo run -p squalr

macOS Security Whitelist / Disable Guide

Squalr uses Mach APIs on macOS (task_for_pid, mach_vm_read_overwrite, mach_vm_write) to open and inspect target processes. If these calls are blocked, process open/read/write operations will fail.

To enable these, system sandboxing security features must be disabled. Just note that this effects your entire system, and makes your system more vulnerable to bad software! Not advised unless you know what you are doing.

• Boot your Mac in recovery mode (power down Mac, and boot while holding the power button down).
• Launch Terminal from the Utilities menu.
• Type csrutil disable
• Reboot when prompted
• When running Squalr, run it from the command line with elevated permissions (sudo ./squalr or sudo ./squalr-cli or sudo ./squalr-tui).

This process can be reversed at any time to undo the security changes with csrutil enable instead.

Architectural Overview

Command Response System

Squalr has two components, a privileged interface, and an unprivileged core. This naturally gives rise to a command/response architecture, which makes for clear separation of concerns. Shared command models live in squalr-engine-api; command-line parsing is an API adapter under squalr-engine-api::commands::command_line that lowers CLI/REPL-style input into those shared commands.

This allows us to create several different modes, such as a unified GUI/CLI/TUI build, and a potential remote host to control a remote shell.

Architecture Glossary

• A snapshot is a full query of all virtual memory regions in an internal process. This is created in two passes, once to determine the virtual page addresses and sizes, and another pass to collect the values.
• An snapshot region represents a continuous range of virtual memory regions. For example, virtual memory pages of 0x1000-0x2000, 0x2000-0x3000, merge t