Cutter: the rizin-powered reverse engineering GUI that runs on Linux, macOS and Windows

What Cutter is for, and who ends up using it

Cutter is a reverse engineering platform, not a library. The README describes it as free and open source, powered by rizin, and aimed at being "an advanced and customizable reverse engineering platform while keeping the user experience in mind." The phrase "created by reverse engineers for reverse engineers" is the positioning: the intended user already knows what a disassembly view, a graph view and a debugger session are, and wants them in one window instead of across several terminal sessions. The practical audience is someone doing binary analysis on a desktop: malware triage, CTF work, auditing a stripped binary, or checking what a firmware blob does. Because the interface is a GUI, the tool assumes a workstation with a display, which is a real constraint rather than a detail. The repository topics list cutter, debugger, gui, reverse-engineering and security, which matches that reading. If your analysis runs inside a CI job with no display, the GUI is the wrong shape for the problem, and the rizin engine underneath is the part you would want to call directly.

The split between Cutter and rizin, and why it matters

Cutter does not implement disassembly itself. The engine is rizin, and the repository carries a rizin entry at the top level alongside src/, cmake/ and dist/, which is consistent with the engine being pulled in as a submodule rather than vendored by hand. That architecture has two consequences worth stating plainly. First, the quality of your analysis depends on the rizin build Cutter was compiled against, so a binary that rizin cannot parse will not become parseable because a GUI is wrapped around it. Second, upgrading Cutter can mean upgrading the engine at the same time, and the release notes are the place to check what changed. The build system is CMake, with CMakeLists.txt at the repository root and a cmake/ directory of modules, and the codebase is C++ with a .clang-format and .clang-tidy at the root, so the project enforces a formatting and linting standard on contributions. The GUI layer is what Cutter adds: views, a plugin host, and the Python and C++ plugin interfaces. When something looks wrong in a graph or a listing, the question to ask first is whether the fault is in the view or in the engine, and those are different repositories.

Installing Cutter from a release binary

The README routes most users to prebuilt binaries rather than a source build. Release binaries for Linux, macOS and Windows are published on GitHub Releases, and the newest release listed is v2.5.0 from 2026-06-30, preceded by v2.5.0-rc1 on 2026-06-21. On Linux, the README says to check your distribution for a cutter package, or cutter-re, or rz-cutter, and otherwise to use the OBS repositories or the .AppImage file. The AppImage path is the one with an explicit command in the README:

chmod +x Cutter*.AppImage; ./Cutter*.AppImage

After that command the application window should open; the README also mentions AppImageLauncher if you want the file integrated into your desktop. On macOS the README offers the .dmg file or Homebrew Cask:

brew install --cask cutter

On Windows it offers a .zip archive, Chocolatey, or Scoop:

choco install cutter

scoop bucket add extras
scoop install cutter

Note that the Scoop instructions are two commands in that order: the bucket is added first, then the package. For a container deployment, the README points at the docker directory in the repository and says its README.md contains instructions for getting started with the image. If none of these fit, the README sends you to the Building Docs at cutter.re/docs/building.html rather than reproducing build steps itself.

A first session and the plugin path

Once the binary is running, the workflow is the one the screenshot in the README implies: load a binary, let the engine analyse it, and move between the disassembly, the graph and the debugger views. The README does not walk through a first analysis, and that is a gap: a new user has to go to the User Guide at cutter.re/docs/user-docs.html to learn the interface, because the README stops at installation, documentation links and the plugin list. The extension model is where Cutter differentiates itself. Plugins can be written in Python or in native C++, and the README links an Official & Community Plugins list plus a Plugins Development Guide at cutter.re/docs/plugins.html. Two examples are named in the README: a native integration of the Ghidra decompiler, published as rz-ghidra, and a plugin that visualises DynamoRIO code coverage. The decompiler plugin is the one most users will care about, because it turns the disassembly view into something closer to source. The cost is that a plugin ecosystem means version matching: a plugin built against one Cutter release may not load in another, and the README does not document a compatibility policy for third-party plugins.

Where Cutter is the wrong choice

The clearest limitation is the one the project states through its own shape. Cutter is a desktop GUI. If your analysis has to run unattended on a server, or be scripted end to end, or produce machine-readable output for a pipeline, the graphical layer adds nothing and the engine is what you want to call. A second limitation is the license. Cutter is GPL-3.0, per the license identifier, and the repository carries a COPYING file at the root. That matters if you plan to redistribute a modified Cutter, or bundle it into a product, because GPL-3.0 carries obligations that a permissive license does not; this is a description of the license, not legal advice, and anyone shipping it commercially should read COPYING and take their own advice. A third limitation is documentation depth in the README itself: it does not document rollback, it does not document a plugin compatibility policy, and it does not give a first-analysis walkthrough. A fourth is platform coverage: the README names Linux, macOS and Windows, and nothing else, so anyone on another platform is in build-from-source territory with no promise that it works. Finally, the release history shows a gap: v2.4.1 landed on 2025-05-11 and the next release, v2.5.0-rc1, on 2026-06-21. That is roughly thirteen months between releases, which is worth knowing if you depend on upstream fixes arriving quickly. The last push to the repository was on 2026-09-11, so work is happening between releases, but the release artifacts themselves move slowly.

The realistic alternative, and how the approach differs

The alternative most people weigh against Cutter is not a different GUI but a different mode of work: driving the rizin engine directly from the command line and scripting it. That is the same analysis core, minus the Qt interface and minus the plugin host. The difference is not quality of disassembly, since the engine is shared, but where the state lives. In Cutter the state is a session in a window: you open a binary, navigate, annotate, and the interface holds the context. In a scripted engine workflow the state is in your script and its output, which is what you want when the analysis has to be repeated across hundreds of samples or checked into a repository. The trade-off runs the other way too. Interactive work on a single unfamiliar binary is faster with a graph view and a decompiler pane than with a terminal, and that is the case Cutter is built for. There is also the plugin question: the Ghidra decompiler integration named in the README is a Cutter plugin, so a pure engine workflow has to arrange its own decompilation path. Choosing between them is really choosing whether a human is sitting in front of the analysis or a script is.

Maintenance, upgrades and the license in practice

The repository is not archived, and the last push was on 2026-09-11, which is recent relative to the release history: the newest release, v2.5.0, is dated 2026-06-30. That combination tells you development continues on the dev branch, which is the default branch, while releases are tagged less often. For an adopter the practical question is what an upgrade costs. Cutter bundles an engine, so moving from v2.4.1 to v2.5.0 is not only a GUI change; the rizin submodule moves with it, and any plugin you rely on has to keep working against the new build. The README does not describe a supported upgrade path or a plugin compatibility guarantee, so the safe assumption is that you test a new release against your own plugin set before replacing a working install. On licensing, GPL-3.0 with COPYING at the root means the source is available and modifications you distribute carry the same license. For internal analysis this is a non-issue. For embedding Cutter in something you ship, it is the first thing to check, and the SECURITY.md file at the root is the place to look for how vulnerabilities are reported rather than a place to look for commercial terms.

Editorial conclusion

Adopt Cutter if you want a graphical disassembler and debugger on Linux, macOS or Windows and you are willing to track a project whose newest release is v2.5.0 from 2026-06-30 and whose last push was on 2026-09-11. Do not adopt it if you need a headless, script-only pipeline, or if you cannot accept GPL-3.0 terms for the way you redistribute the binary; the README points to the rizin repository as the engine underneath, and the docker directory for container use. Before committing, verify that your target architecture is handled by the bundled rizin version, and read the Building Docs at cutter.re/docs/building.html if you intend to compile from source rather than use a release binary.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. rizinorg/cutter on GitHub