Rizin is still pre-1.0, and its default branch is dev

The build is three meson commands and the uninstall is a fourth

The whole compile path is documented in four lines. Clone the repository, configure a build directory, compile it, install it:

$ git clone https://github.com/rizinorg/rizin

then

$ meson setup build
$ meson compile -C build
$ sudo meson install -C build

The one prerequisite with a version attached is meson itself, which needs to be at least 0.55.0, and the suggestion for systems that ship an older one is to get it from pip. Removing the installation afterwards is not a package manager operation; it is a fourth meson invocation, ninja against the same build directory with the uninstall target, which works because meson generated that target when it configured the tree. The build directory is a real artifact rather than a cache: deleting it removes the uninstall path as well, so keep it if you might want to reverse the install.

The version is 0.9.1 and the default branch is dev

Three releases are visible: v0.8.2 in February 2026, v0.9.0 in June 2026 and v0.9.1 two days after it. A framework at version nine tenths has not committed to a stable interface, and the repository makes that concrete rather than implicit: the default branch is dev, and every documentation link in the README points at the dev branch of the source file rather than at a tag. Anyone who clones without arguments therefore gets the moving target, not the last release. The gap between the two is visible in the dates too, with the last push on the branch arriving days after the most recent release tag. For a tool that exposes a command language, a plugin interface and bindings in six languages, that distinction decides whether a script written today keeps parsing next month.

Ten rz- tools exist so that a script never has to parse terminal output

The main binary is one of eleven programs, and the split is the design decision worth noticing. rz-bin reports on binary formats, rz-ar lists and extracts members from static archives, rz-asm assembles and disassembles, rz-diff compares two binaries as raw data or as analysed executables, rz-hash computes hashes and encrypts data, rz-gg generates shellcode-shaped eggs for exploitation work, rz-find is the binary analogue of find for patterns and bit masks, rz-sign creates and parses FLIRT signatures, rz-ax is a calculator and number format converter, and rz-run specifies the running environment and arguments for a file being debugged. Each of these is documented as useful on its own for shell scripting. The practical effect is that a pipeline can call a tool, read its output, and never open an interactive session, which is what makes Rizin usable from a script where a graphical interface would not be.

The Docker image drops every capability, and debugging needs one back

The container definition starts from debian:11 and states in its own header that the build needs 400MB of free disk. The run instruction strips capabilities rather than granting them:

$ docker run -ti --cap-drop=ALL rizin:latest

Debugging a program inside the container is the documented exception, and the flag is named explicitly: add SYS_PTRACE to the run line, then pass -d and a binary. The base flag set is otherwise empty, so a shell you get into that image cannot do much beyond reading what you copied in. The image is also parameterised in two ways. Build arguments enable the binutils-based assembler plugins for arm32, arm64 and ppc, each passed separately, and two version arguments pin the rz-pipe Python version and the rz-ghidra version, both defaulting to a branch rather than a release. Sharing an image between machines is done by exporting the stopped container, compressing it, and importing it on the far side.

The supported target list is long enough that the omissions are the interesting part

Operating systems run from Windows 7 upward through macOS, iOS and iPadOS, GNU/Linux, the BSD family, Android, QNX, Solaris, Illumos, Haiku, Darwin and Hurd. Architectures number around fifty and include the usual desktop and embedded set, the 8-bit microcontrollers, several digital signal processors, and console architectures such as GameBoy, SNES and SPC700. Bytecode formats are handled separately and include Dalvik, Java, Lua, Python, WebAssembly, EBC, Brainfuck and Malbolge. File formats are a third list of more than thirty entries, and it is the one with the most household objects in it: game consoles, Nintendo DS ROMs, Nintendo 3DS firmware images, a Commodore VICE emulator image, Plan 9 executables, Android boot images, ELF coredumps, Windows minidumps and pagedumps, and dynamic linker caches. Anyone whose target is missing from these lists is looking at a plugin rather than a build flag.

Bindings are a separate project, and six languages are wired to it

Scripting is not implemented in the framework's own tree. The README points at a separate repository, rz-pipe, as the mechanism for talking to Rizin from Python, Haskell, OCaml, Ruby, Rust and Go, and says other languages could be added easily. Two things follow from that split. The supported language list is a property of the binding project rather than of the C core, so it can change without a Rizin release, and the Docker image carries version arguments for exactly those two external pieces, one for the Python binding and one for the Ghidra plugin, both defaulting to the tip of their branch. The image therefore inherits the same moving-target property as a clone of the dev branch, one level removed, which matters for the same reason it matters for the core.

Repository layout separates the libraries, the binaries and the vendored patches

The top level divides into three source trees and a set of build files. librz holds the libraries, binrz holds the command-line programs, and sys holds the system-facing layer. Around them sit the files a contributor needs to read before changing anything: BUILDING.md for the build options, DEVELOPERS.md, CONTRIBUTING.md, CODEOWNERS, SECURITY.md and an AGENTS.md, alongside a CODE_OF_CONDUCT and a LICENSES directory that matches the LGPL's requirement that third-party licensing be recorded. The build definition is split between meson.build and meson_options.txt, so features are toggled through a separate options file rather than by editing the build script. Three directories describe work that is not Rizin's own code: patches holds changes carried between versions, subprojects holds dependencies fetched at build time, and cross-compile holds the machinery for the fifty-odd targets. Quality tooling is configured in files rather than in scripts, with clang-format, pylint, prettier ignore, codecov and a REUSE.toml, and CI runs on Woodpecker, Travis and AppVeyor configurations left in the tree.

Documentation is a book plus four repository files, and community is three platforms

There is no inline tutorial. Learning Rizin starts with a separately hosted book, and the README's own links are the four files that a contributor or a builder would need: BUILDING.md for compiling, CONTRIBUTING.md before sending a change, DEVELOPERS.md for the internals, and test/README.md for the test suite. The examples directory contains a single subproject, api, which means the example code is about calling the library rather than about driving the command line. Support runs through a Mattermost server that also covers development discussion, with partial bridges to a Telegram channel and to Libera Chat over TLS on port 6697, split into a community channel and a developer channel. The presence of 628 forks against nearly 3,900 stars, and an open issue count in the hundreds, is the shape of a project that is used heavily and discussed heavily, and the split between a small example set and a large issue queue is the part worth weighing before adopting it.

Editorial conclusion

Rizin suits an analyst who wants a scriptable command-line binary inspection tool that can be driven from Python or Go, who works across many file formats rather than one architecture, and who is prepared to read the book rather than expect a guided setup. It does not suit a team that wants a stable API contract, because the default branch is the development branch and the version is still below one. It does not suit someone who needs a container to debug a program without reading the capability flags, because the image drops all capabilities and debugging requires adding one back. Before adopting it, check the release you pin against the branch you build, read BUILDING.md for the options that meson exposes, and confirm that the format you need is in the list rather than in a plugin.

Frequently asked questions

Official sources

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