Cutter puts a GUI on rizin, and the install path depends on your package manager

rizin is a submodule, not a vendored copy

Cutter is described as a free and open-source reverse engineering platform powered by rizin, and the repository layout shows what that means in practice. A `rizin` entry sits at the top level next to .gitmodules, so the binary analysis engine arrives as a pinned submodule rather than as code copied into this tree. Everything else in the root is C++ application code: src/, CMakeLists.txt, cmake/, scripts/ and dist/, plus _clang-format and .clang-tidy, which is how the C++ side is kept consistent.

The project says it aims at being an advanced and customizable platform while keeping the user experience in mind, and that it was created by reverse engineers for reverse engineers. That is a claim about the interface, and the README backs it with a plugin surface rather than a feature list.

Licensing is GPL-3.0, with the text in COPYING. A SECURITY.md also sits at the root, which the README never mentions. For a tool that opens files you do not trust, that file is worth reading before you point it at something.

Package names differ per distribution, so check three before you build

There is no single install line. Linux users are told to look for `cutter` in their package manager, or `cutter-re`, or `rz-cutter`, and if the distribution has none of those, the project keeps setup repositories in OBS for some common distributions with instructions on software.opensuse.org. When no package exists at all, the release page carries an AppImage:

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

Three candidate package names for one application is the first thing to verify, because a wrong guess gives you nothing rather than an error. AppImageLauncher is offered as an alternative to making the file executable yourself.

macOS takes a .dmg or a cask:

brew install --cask cutter

Windows takes a .zip archive, a Chocolatey package, or Scoop, and Scoop needs its bucket added first:

scoop bucket add extras
scoop install cutter

Chocolatey's line is `choco install cutter`. Every path lands on the same application, so the choice is about who maintains the update, not about what you get.

Releases come from tags, development happens on dev

The default branch is `dev`, and that is also the branch the AppVeyor badge in the README points at. Release binaries for Linux, macOS and Windows are published on GitHub Releases, so the binaries you download and the branch the CI watches are two different things.

The tag history explains the cadence. v2.4.1 was released on 2025-05-11, v2.5.0-rc1 on 2026-06-21, and v2.5.0 on 2026-06-30. Thirteen months separate 2.4.1 from the release candidate, then nine days separate the candidate from the final tag. The last push to `dev` was on 2026-11-02, and the repository is not archived, so work continues after the tag rather than stopping at it.

For a user, that shape means upgrade decisions are coarse. You pick a tag, and everything between tags is what you wait for. The README documents no nightly or unstable channel, so the only supported path it names is the release binary.

Two plugin languages, and no documented way to install one

Cutter supports both Python and native C++ plugins, and the README treats the ecosystem as the proof: it points at a community list of official and community plugins, and names two examples, the native integration of the Ghidra decompiler, rz-ghidra, and a plugin that visualises DynamoRIO code coverage.

Both examples are instructive in different ways. rz-ghidra is native, and the decompiler it wraps is a separate repository, so the quality of your decompilation depends on another project matching your build. The coverage plugin takes input from DynamoRIO, a dynamic tracing tool, which means the data arrives from outside Cutter rather than from the static analysis it does itself.

What the README does not give is the step that matters most: it does not say how a plugin is installed, how it is enabled once installed, or which version of the application a native C++ plugin has to be built against. There is a Plugins Development Guide at cutter.re/docs/plugins.html for the writing side. A native plugin is a C++ artefact, so a version mismatch is a rebuild rather than a settings change, and the guide is where you would look that up.

The Docker path is a directory and a second README

Cutter has a container story, and it is short. For deploying the application with a pre-built Dockerfile, the README points at the provided configuration in the `docker` directory and says the README.md in that directory contains instructions for getting started with minimal effort.

That is the whole text. No image name, no tag, no run command, no port, no volume for the files you intend to open. A `.dockerignore` at the repository root tells you the container build is taken seriously, but the useful facts are in the second README rather than in the first.

The consequence for a reader is narrow and worth stating: the container path is documented somewhere other than where you would look, so budget a few minutes in `docker/` before assuming the deployment is one command. This is also where the absence of a command line interface in the README stops being surprising. Every path the README describes is a download, a package manager, a documentation link or a directory, because Cutter is an application you look at.

Building from source is a documentation link, not a recipe

The README does not print a build command. It sends you to the Building Docs at cutter.re/docs/building.html, and that is the entire instruction for compiling Cutter yourself.

What the repository root does show is the shape of the build. CMakeLists.txt and the cmake/ directory mean CMake drives it, _clang-format is the formatting configuration, .clang-tidy the static analysis configuration, and .lgtm.yml sits beside them. `.appveyor.yml` covers Windows builds and .github/ holds the Cutter CI workflow that the badge at the top of the README points at, so the project builds on more than one platform's infrastructure.

The practical consequence is that a source build is a two step operation: read the building documentation, then work in a tree that has a submodule in it, since a shallow clone without submodule contents will not have rizin. Documentation is split three ways at cutter.re: a User Guide, Contribution Guidelines, and Developers Docs, and the build instructions are the kind of thing that lives in the last of those rather than in the README.

Four support channels, none of them a forum

Help comes through four channels and the README asks for them by name: Telegram at t.me/cutter_re, Mattermost at im.rizin.re, IRC `#cutter` on web.libera.chat, and the `@cutter_re` account on Twitter. Three of the four are chat, and the Mattermost host is on the rizin infrastructure rather than a general purpose forum.

That shape suits a tool used by people who already know the domain, and it means the answer to a question is likely to be a conversation rather than a searchable thread. If you need a written answer you can link to later, the documentation site is the place to look first, and the User Guide at cutter.re/docs/user-docs.html is the page the README puts above the contribution and developer guides.

The last push to `dev` landed on 2026-11-02 and nothing about the repository suggests it is parked, so the channels are attached to a project that is still changing. Version 2.5.0 is the tag to match against when you report something, and the gap back to 2.4.1 is the reason to say which one you are on.

Editorial conclusion

Adopt Cutter if you want rizin's analysis inside a desktop application and can wait for a tagged release instead of tracking a branch. Do not adopt it for a scripted pipeline: the README describes no command line flags and no headless mode, only downloads, a documentation link and a docker directory. Check two things before you commit. First, which rizin your build carries, since a `rizin` entry and .gitmodules at the repository root show the core is a separate project pulled in as a submodule. Second, whether a plugin you need is Python or native C++, because the project names a plugin list and a development guide but documents no installation step for either kind.

Frequently asked questions

Official sources

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