radare2: a scriptable terminal for reverse engineering, and the places it writes back

Every task is a verb: aaa, afl, px and the flag namespace

Every task in radare2 is a verb. Opening a binary read-only is `r2 /bin/ls`; analysis is `aaa`; the function list comes from `afl`; a hexdump is `px 32`; and `s sym.main` moves to a symbol by flag name instead of by raw address. Flags are the naming layer that makes that work, and `f~foo` filters them with an internal grep.

The same table is the API. Automation needs no window and no mouse. An embedded Javascript interpreter runs scripts inside r2, r2pipe lets any external language drive the same commands, and r2papi offers a high level API on top of r2pipe when structured results beat pasted strings.

No graphical interface ships in the core. iaito, the Qt front end, is installed through the package manager like the rest of the plugins, so the default experience is a terminal and a prompt.

sys/install.sh builds, installs and symlinks, and purge reaches further than you expect

Released binaries can be downloaded from the project's releases page, but the recommended way is a source checkout, and one script does the whole chain:

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

That default is described as acr+make+symlink: configure with acr, build with make, leave symlinks pointing at the result. meson and ninja are supported too, with muon or samu as substitutes, and a plain make build is documented as well.

Removal splits into two operations, and the difference bites. `make uninstall` takes out the current build. `sudo make purge` removes all the system installations of r2.

Upgrades move faster than the docs assume. Tags landed at 6.2.0 on 2026-08-07, 6.2.2 on 2026-09-06 and 6.2.4 on 2026-10-05, the last push was on 2026-11-02, and master already reads 6.2.5 with 6.2.6 queued behind it. Pin what you run. For reproducible work, Nix packaging under `dist/nix` and pip installation through r2env are both documented routes.

Windows takes a different road: meson, msvc or mingw, and four .bat lines

Windows does not use the shell script. The compiler requirement is stated up front: meson, paired with msvc or mingw. Four batch lines drive the build instead.

preconfigure.bat       REM setup python, meson, ninja
configure.bat          REM run meson b + vs project
make.bat               REM run ninja -C b
prefix\bin\radare2.exe

Read that last line as a destination, not a command. On Windows you get a file at `prefix\bin\radare2.exe` rather than the symlinked tree sys/install.sh leaves on Unix, so PATH becomes your problem to solve. Plugin configuration is separate again, handled by the configure-plugins script at the repository root.

Anyone comparing the two platforms should keep one difference in mind. On Unix the install is one command, and on Windows it is a toolchain you assemble first, with python, meson and ninja fetched by preconfigure.bat before anything is compiled.

Your first run on /bin/ls, ending with the one command that writes to your file

A first session looks like this, opening /bin/ls read-only and walking away from the raw addresses:

$ r2 /bin/ls   # open file in read-only
> aaa          # analyse the program (r2 -A)
> afl          # list all functions (try aflt, aflm)
> px 32        # print 32 byte hexdump current block
> s sym.main   # seek to main (using flag name)
> f~foo        # filter flags matching 'foo' (internal |grep)
> iS;is        # list sections and symbols (rabin2 -Ss)
> pdf; agf     # disassembly and ascii-art function graph
> oo+;w hello  # reopen in read-write and write a string
> ?*~...       # interactive filter in all command help
> q            # quit

Everything in that block is harmless except the ninth line. `oo+` reopens the file in read-write mode, and `w hello` puts bytes at the current offset in the file itself, with no confirmation step. Work on a copy the first time you run it.

The help filter is worth learning early, because it changes how the table is learned. `?*~...` is a built-in grep over every command's help, so you can find the verb instead of memorising it.

r2pm installs what the core omits, and plugin licences drift away from LGPLv3

Many plugins ship inside the core. The rest arrive through r2pm, which has its own short verb set:

r2pm -s <word>  # search packages matching a word
r2pm -Uci <pkg> # update database and clean install a package
r2pm -u <pkg>   # uninstall the given package
r2pm -l <pkg>   # list installed packages

`r2pm -Uci` does two things at once, and the second one hurts reproducibility. It updates the database and then performs a clean install, so the version you get is whatever the remote index holds that day. `r2pm -l <pkg>` reports what you actually ended up with, which makes it the command worth scripting into your setup notes.

Licensing is the other loose edge. The framework is distributed under LGPLv3, yet each plugin can carry a different licence, and `r2 -Lj` prints the details for the build sitting in front of you. A plugin pulled by r2pm should not be assumed to share the core's terms, so per-component auditing means reading that output instead of generalising from the LGPLv3 line.

`aaa` carries no documented timing and no output contract

`aaa` is the command you will wait on longest, and it is the one explained least. Its whole description in the usage example is the comment `# analyse the program (r2 -A)`. The README's usage example does not state which passes it makes, how long it takes on a stripped binary, or whether the listing it produces has a stable shape across versions.

The consequence lands on anyone scripting this. `afl`, `aflt` and `aflm` hand you a list and two ways to reshape it, but the README documents no output contract to parse against, so a script written against today's defaults breaks against the next one. Timing is the other half of the same gap: you cannot quote an analysis window to a colleague from documentation, only from measurements you took yourself on your own binaries.

Keep the binary you measured with. Master already sits at 6.2.5 while the newest tag is 6.2.4, so an unpinned r2 is a moving target under any pipeline.

Remote debugging and kernel memory both need a server you supply

r2 debugs programs locally or over remote gdb and windbg servers, and it can view kernel memory. Both claims lean on something outside this project. A remote session is only as good as the server you point it at, and its transport and access control are yours to arrange: the README names no default port, no startup command and no configuration key for either server.

Kernel memory has the same shape. r2 offers the view, while the platform's memory interface, its permissions, and whether that kernel was built to permit inspection all sit upstream of this repository.

Neither claim is a reason to skip the tool for local work on a machine you control. Both are reasons to budget engineering time for the transport rather than for the analyser.

Decompilation arrives as a plugin: pdg from Ghidra, pdd from r2dec

Disassembly is built in. Decompilation is not. The r2ghidra plugin is the standalone native Ghidra decompiler, reached with `pdg`, and r2dec is a decompiler written in JavaScript, reached with `pdd`. Both live in separate repositories, both install through r2pm, and both are separate decisions with separate licences. Other language-specific readers follow the same pattern, including r2hermes for React Native Hermes bytecode and r2flutter for Dart and Flutter AOT snapshots.

That is the structural difference from Ghidra, which ships its decompiler and its interface inside one product. In radare2 the analysis engine stays in the terminal, the decompiler is interchangeable, and the graphical front end is iaito, an optional Qt interface. r4ghidra runs the arrangement the other way by bringing radare2 into Ghidra. Decide which side of that split your workflow sits on before installing anything, because the answer determines whether you need a plugin stack at all.

Editorial conclusion

radare2 suits analysts who want a scriptable prompt, remote debugging through an existing gdb or windbg server, and a decompiler they can swap. It suits them less if the interface has to be graphical from the first minute, or if source-like output has to work without a second install. Before adopting it, run r2 -Lj on your own build, because the core is LGPLv3 while each plugin can carry different terms, and record r2pm -l output rather than trusting that a clean install gave you the version you meant.

Frequently asked questions

Official sources

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