Radare2: A Command-Line Reversing Framework for People Who Live in a Shell

What radare2 is for, and who it is actually aimed at

Radare2, usually shortened to r2, describes itself as a complete rewrite of radare, and its README frames the whole thing as a "Libre Reversing Framework for Unix Geeks". That phrasing is a fair summary of the audience. The project started as a command-line hexadecimal editor with a forensics focus, and the current tool still opens a file, seeks around it, edits bytes and inspects structures without ever leaving the terminal. Around that core it grew architecture support for analysis, emulation, debugging and disassembly, plus a set of libraries and plugins.

The practical use cases named in the README are binary analysis, forensics and malware analysis, and the topics list on the repository adds disassembler and reverse engineering. Someone triaging a suspicious sample, someone pulling apart a firmware image, and someone who needs to script a repetitive analysis over a few thousand files are all plausible users. The common thread is that they want the file, not a project file. r2 has no persistent workspace concept in the base workflow; you open a path and you are in.

It is a poor fit for the opposite kind of user. If you want a window with a function tree, a decompiler pane and a rename dialog, the README points at iaito as the official Qt graphical interface, which is a separate project. The base tool is a console, and the README's own first-steps section is a list of commands rather than a description of a window layout.

The command grammar is the architecture

Radare2 does not present a menu. It presents a prompt where every keystroke sequence is a command, and the command names are short enough to be typed without looking. The README's usage block is the clearest statement of how the pieces fit together: aaa runs analysis, afl lists functions, px prints a hexdump, s seeks, pdf disassembles a function, agf draws the control-flow graph as ASCII art, and oo+ reopens the file in read-write mode so w can write to it.

Two mechanisms are worth understanding before you fight the interface. The first is flags. After analysis, discovered entities become named flags such as sym.main, and s sym.main seeks to one by name; f~foo filters the flag list using an internal grep. The second is the filter suffix. The tilde appears throughout the tool as an inline query language, and the README notes that ?*~... opens an interactive filter inside the help system itself. This is why r2 feels opaque at first and fast later: the same character does the same job in every context.

The libraries underneath are the other half of the design. The repository is organised around libr/ with per-area directories such as libr/anal, libr/asm, libr/bin, libr/flag, libr/cons and libr/magic, with data files in matching d/ subdirectories. Those are the components you are driving when you type a command, and they are also what r2pipe and the plugin ecosystem attach to. The plugin surface is broad: the README lists r2ghidra for native Ghidra decompilation through pdg, r2dec as a JavaScript decompiler behind pdd, r2frida for dynamic instrumentation, r2yara for Yara integration, and r2pipe for scripting from other languages.

Installing radare2 from source and opening your first binary

The README states that the recommended installation path is from the Git repository source, and gives a two-line sequence: clone, then run the install script. That script performs the default acr+make+symlink installation. The project also supports meson/ninja builds, and the README notes that muon/samu work as alternatives.

git clone https://github.com/radareorg/radare2
radare2/sys/install.sh

Released binaries are also offered on the releases page, and the README mentions r2env as a pip-based route to install r2. On Windows the documented route is a set of .bat scripts driving meson and msvc or mingw, and the README warns that Windows builds require meson plus one of those compilers. Uninstalling is handled by make uninstall for the current build, while sudo make purge removes all system installations of r2, which is a distinction worth reading twice before running either.

Once installed, the README's first-steps block is the intended tutorial. Start read-only, analyse, then look around.

r2 /bin/ls
aaa
afl
s sym.main
pdf
q

What you should see: aaa performs the analysis pass, afl prints the function list, s sym.main moves the seek position to the flag named sym.main, pdf prints the disassembly of the function at the current position, and q exits. Passing -A at startup runs analysis immediately, so r2 -A /bin/ls skips the separate aaa step. If you want to modify rather than inspect, oo+ reopens the file read-write and w hello writes a string at the current offset, which is the documented path from inspection to patching.

Plugins are managed separately through r2pm, the package manager the README links to.

r2pm -s <word>
r2pm -Uci <pkg>
r2pm -l <pkg>

r2pm -s searches packages matching a word, -Uci updates the database and clean-installs a package, and -l lists installed packages. The README also documents r2pm -u <pkg> for uninstalling.

Where radare2 gets in your way

The README does not document rollback for the install script, and it does not describe a supported downgrade path between releases. Given that the current master branch is versioned 6.2.3 with 6.2.4 as the next release, and that 6.2.2, 6.2.0 and 6.1.8 shipped in the months before, you should assume you are tracking a moving target unless you pin a release binary. Installing from git source means installing whatever master is that day.

The plugin licensing situation is the second constraint, and it is stated plainly rather than hidden. r2 itself is distributed under LGPLv3, but the README adds that each plugin can carry a different licence and directs you to r2 -Lj for the details. If you are assembling a distribution or shipping r2 inside a product, that command is the inventory, not the README. The repository's licence field is recorded as NOASSERTION, so the LGPLv3 claim in the README is the project's own statement rather than a machine-readable declaration.

The third limitation is simply the interface. A user coming from a graphical disassembler will find that nothing is discoverable by clicking. The help system is comprehensive, and the README points at the official book at book.rada.re, USAGE.md and INSTALL.md, but those are reading material, not affordances. There is also no decompiler in the base install: pdg comes from r2ghidra and pdd from r2dec, both plugins, so a workflow that depends on reading pseudocode needs an extra installation step before it is viable.

Radare2 versus Ghidra, Cutter and Rizin

The most common comparison is with Ghidra, and the difference is architectural rather than a matter of feature checklists. Ghidra is a GUI application that manages projects: you import a binary into a project, and the decompiler is part of the installation. Radare2 is a shell tool that operates on a path, and its decompiler arrives as the r2ghidra plugin, which the README describes as the standalone native Ghidra decompiler accessible with pdg. So the honest framing is not r2 against Ghidra but r2 plus r2ghidra against a Ghidra project, and the trade is a scriptable pipeline against a managed workspace.

Cutter is the name people reach for when they want r2 with a window. The README does not list Cutter among the popular plugins; it lists iaito as the official Qt graphical interface. That is a meaningful distinction for anyone choosing a GUI, since the project's own pointer goes to iaito.

Rizin is the other comparison worth naming, and the README is silent on it. What can be said from what the project publishes is structural: radare2 is a framework of libraries under libr/ with a plugin system and its own package manager, r2pm, and it exposes scripting through r2pipe from any programming language. Any evaluation against Rizin has to start from that library-and-plugin boundary, because that is what determines how much of the tool you can embed rather than merely invoke.

Maintenance, releases and the cost of staying current

The repository is not archived, and the last push was on 2026-09-20, so the project is being worked on continuously. Release cadence is visible in the tags: 6.1.8 on 2026-06-23, 6.2.0 on 2026-08-07, and 6.2.2 on 2026-09-06. Master is versioned 6.2.3 and the README states that the next release will be 6.2.4.

That cadence sets your upgrade cost. If you install from released binaries you get a stable point and upgrade on your own schedule. If you install from git source, as the README recommends, you are on a branch that is ahead of the last release, and the version string will not match any tag. For a team running r2 inside an analysis pipeline, the release binaries are the lower-variance choice, and pinning matters more than being current.

On licensing, the README states LGPLv3 for r2 while noting that plugins may differ, and the repository licence field is NOASSERTION. The practical consequence is that a plugin inventory is part of any distribution decision, and r2 -Lj is the command that produces it. This is not legal advice; it is the boundary the project itself draws.

Editorial conclusion

Adopt radare2 if your work already happens in a terminal and you want one tool that opens a file, analyses it, disassembles it, graphs it and can be scripted from Python or JavaScript through r2pipe. Do not adopt it as a first disassembler for a GUI-oriented team, or for a one-off look at a binary you will never touch again; the command grammar is the product, and learning it is the cost. Before committing, run sys/install.sh in a container rather than over an existing system install, check the plugin licences with r2 -Lj, and confirm whether you need r2ghidra for pdg output, because decompilation is not part of the base install.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. radareorg/radare2 on GitHub
4. README
5. Releases