r2frida: Radare2 Commands for Frida Instrumentation

Why r2frida Joins radare2 to Frida

r2frida addresses a workflow gap between static inspection in radare2 and dynamic instrumentation with Frida. Reverse engineers often have a binary open in radare2, then need to inspect the running process, inject a script, trace a function, modify memory, or execute target-specific code. Without an integration layer, those steps require another command-line tool and a separate mental model.

The plugin puts those operations behind a `frida://` target inside radare2. Its intended users are analysts working with Android, iOS, Linux, Windows, or macOS processes, including remote targets reached through a Frida server. The README also identifies Dalvik, Java, Objective-C, Swift, and C as supported target interfaces. This is broad coverage, but the exact behavior still depends on the Frida agent, platform, architecture, permissions, and target process.

The central design choice is to ship Frida with the plugin. According to the README, r2frida does not require Frida or `frida-tools` on the host. That reduces installation friction and keeps scripts and instrumentation commands inside the existing radare2 session. It does not eliminate platform setup. USB and TCP/IP connections still require a compatible Frida server and a reachable target, while attaching to or manipulating a process still depends on operating-system permissions.

The frida:// Target and Command Data Flow

The documented target syntax has four parts:

frida://[action]/[link]/[device]/[target]

Here, `action` can be `list`, `apps`, `attach`, `spawn`, or `launch`. The `link` can be `local`, `usb`, or a `remote host:port`. An optional `host:port` or device identifier selects a device, while the final field accepts a PID, app name, process name, program path, or absolute path. This structure lets radare2 open different targets through one URI-like interface without losing radare2 as the command environment.

A local session can be opened without selecting a real application process. The README uses PID 0 for a local Frida helper session:

$ r2 frida://0

The plugin then exposes commands through radare2's `:` command namespace. Examples include `:i` for target information, `.:i*` for importing those details into the local radare2 session, `:dm` for memory maps, and `:iE` for exports. Scripting uses `:.`, while `:dt` sets a function trace such as `:dt fread`.

Beyond inspection, the agent can read and write process memory, call functions or syscalls, execute raw code, install native breakpoints, patch code or data, change page permissions, load libraries or frameworks, manipulate file descriptors and environment variables, and run radare2 commands or APIs inside the remote target. Agent-side plugins register through `r2frida.pluginRegister`, while `r2pipe` supports host-side automation. This is a bidirectional control model, not merely a wrapper that forwards one command at a time.

Installing r2frida and Starting a Local Session

The recommended installation command uses `r2pm` and asks it to install and clean information for the package:

$ r2pm -ci r2frida

The README notes that binary builds are not yet supported through `r2pm` and `r2env`, although downloadable builds are available from the repository's Releases page. Source compilation is the documented alternative. On GNU/Debian systems, the listed prerequisites include build tools, Node.js, npm, curl, pkg-config, and git:

$ sudo apt install -y make gcc libzip-dev nodejs npm curl pkg-config git

The source build then follows this sequence:

$ git clone https://github.com/nowsecure/r2frida.git
$ cd r2frida
$ make
$ make user-install

For a first real use, connect to the local Frida helper session:

$ r2 frida://0

The README says this is equivalent in spirit to `frida -p 0` for local testing. Inside radare2, run `:?` to list the available r2frida commands. A useful next check is `:i`, which reports target information such as PID, name, home directory, architecture, and word size. For a live process, the target can instead be a PID or process name:

$ r2 frida://1234
$ r2 frida://rax2

An absolute executable path spawns the program:

$ r2 frida:///bin/ls

That session can continue the target with `:dc`. These examples establish a real session before an analyst begins loading scripts or tracing functions.

Remote USB and TCP Instrumentation Constraints

r2frida is useful when the process is not on the analyst's workstation, but its URL syntax exposes operational constraints. A remote attachment includes the action, `remote`, a host and port, and then the target:

frida://attach/remote/10.0.0.3:9999/558

That command attaches to PID 558 through a TCP remote Frida server. The README does not document authentication settings, reconnect behavior, retry policy, or what happens when the server becomes unavailable, so those details should not be assumed.

For USB debugging, the action can be `spawn`, `launch`, or `attach`. The process can be identified by app name, bundle ID, or PID. The documented sequence begins by enumerating devices and apps:

$ r2 frida://spawn/usb/
$ r2 frida://spawn/usb//

The selected target is then supplied in the final URI segment:

$ r2 frida://spawn/usb//Weather

The empty middle segment in these examples represents the first resolved USB device. This syntax is compact, but it is also easy to misread. The action is not merely a label: `spawn` starts a process, `launch` spawns and resumes it, and `attach` connects to an existing process. Those distinctions matter when a target immediately executes code or when restarting it would discard state.

The README also documents environment controls such as `R2FRIDA_SAFE_IO`, `R2FRIDA_DEBUG`, `R2FRIDA_COMPILER_DISABLE`, and `R2FRIDA_AGENT_SCRIPT`. `R2FRIDA_SAFE_IO` is described as a workaround for a Frida bug on Android/Thumb, while `R2FRIDA_COMPILER_DISABLE` disables the TypeScript compiler for scripts entered through `:.`.

Where r2frida Is the Wrong Tool

The clearest limitation is dependency weight. r2frida combines radare2, an embedded Frida component, an agent, build tooling, and often Node.js or npm. A source build requires `make`, `gcc`, `curl` or `wget`, and the documented Debian command also installs Node.js and npm. A team that only needs a small Frida script may find this larger setup inappropriate.

The plugin is also not a drop-in replacement for every Frida workflow. The README emphasizes commands accessible from radare2 and the special `:.` execution path. It does not claim that every Frida CLI script or Frida API has a direct one-to-one command. Existing automation tied to a different host interface would need to be checked against the documented command and plugin mechanisms.

Build compatibility needs particular attention. The repository contains `configure.bat` and `make.bat` for Windows, but the documented Windows sequence requires meson, Visual Studio, and a radare2 archive renamed to `radare2` inside the project root. The `package.json` file declares Node.js `>=20.0` and `frida-compile` `19.0.6`, while the README says the Node.js requirement will soon be removed. That wording describes a changing build boundary, so source builders should not assume the historical prerequisites are permanent.

The repository is not archived, and its last push was on 2026-10-16. Releases 6.2.4, 6.2.2, and 6.2.0 were published in October, September, and August 2026 respectively. This indicates recent project changes, but the README does not promise long-term release compatibility or a stable upgrade policy.

License, Build Components, and Upgrade Cost

The repository identifies its top-level license as MIT. However, `package.json` describes the internal `r2frida-agent` package as `LGPL-3.0`. Those are separate declarations attached to different parts of the repository, so a team that needs one consistent licensing policy should inspect `LICENSE`, package metadata, and any bundled Frida components before redistribution. This is not legal advice; it is a concrete reason not to treat the repository badge alone as the complete licensing answer.

Upgrade cost is likely to involve more than replacing one binary. Radare2 compatibility is surfaced through the repository's documentation and build configuration, while the agent is compiled with Frida tooling and supports multiple operating systems and CPU architectures. The `Makefile` contains platform detection, architecture normalization, download logic, precompiled-agent selection, and target-specific flags. Source users can expect to revisit those assumptions when host OS, CPU, Node.js, radare2, or Frida tooling changes.

Binary release users face a different constraint. The README says binary builds that do not require compilation will be supported through `r2pm` and `r2env`, but that support is described as forthcoming. Until that path exists, users choosing a release artifact should verify architecture and platform compatibility from the release files themselves. The README does not document an upgrade command or rollback procedure for r2frida.

Editorial conclusion

Adopt r2frida if your analysis workflow already centers on radare2 and you need dynamic instrumentation across local, USB, or remote processes without installing frida-tools on the host. Do not choose it as a standalone replacement for Frida if you require an undocumented workflow outside the plugin command model. Before adoption, verify the build and install path against the host platform, confirm that the bundled Frida component works with the target architecture and runtime, and inspect the MIT repository license separately from the LGPL-3.0 license declared by its internal agent package.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nowsecure/r2frida on GitHub
4. README
5. Releases