This book is an updated version (started by maijin) of the original radare1 book (written by pancake). Which is actively maintained and updated by many contributors over the Internet.

Check the Github site to add new contents or fix typos:

   • Github: https://github.com/radareorg/radare2book

   • Online: https://book.rada.re/

In 2006, Sergi Àlvarez (aka pancake) was working as a forensic analyst. Since he wasn't allowed to use the company software for his personal needs, he decided to write a small tool-a hexadecimal editor-with very basic characteristics:

   • be extremely portable (unix friendly, command line, c, small)

   • open disk devices, this is using 64bit offsets

   • search for a string or hexpair

   • review and dump the results to disk

The editor was originally designed to recover a deleted file from an HFS+ partition.

After that, pancake decided to extend the tool to have a pluggable io to be able to attach to processes and implemented the debugger functionalities, support for multiple architectures, and code analysis.

Since then, the project has evolved to provide a complete framework for analyzing binaries, while making use of basic UNIX concepts. Those concepts include the famous "everything is a file", "small programs that interact using stdin/stdout", and "keep it simple" paradigms.

The need for scripting showed the fragility of the initial design: a monolithic tool made the API hard to use, and so a deep refactoring was needed. In 2009 radare2 (r2) was born as a fork of radare1. The refactor added flexibility and dynamic features. This enabled much better integration, paving the way to use r2 from different programming languages. Later on, the r2pipe API allowed access to radare2 via pipes from any language.

What started as a one-man project, with some eventual contributions, gradually evolved into a big community-based project around 2014. The number of users was growing fast, and the author-and main developer-had to switch roles from coder to manager in order to integrate the work of the different developers that were joining the project.

Instructing users to report their issues allows the project to define new directions to evolve in. Everything is managed in radare2's GitHub and discussed in the Telegram channel.

The project remains active at the time of writing this book, and there are several side projects that provide, among other things, a graphical user interface (Cutter), a decompiler (r2dec, radeco), Frida integration (r2frida), Yara, Unicorn, Keystone, and many other projects indexed in the r2pm (the radare2 package manager).

Since 2016, the community gathers once a year in r2con, a congress around radare2 that takes place in Barcelona.

./configure --prefix=/old/r2/prefix/installation

make purge

Radare2 has seen many different user interfaces being developed over the years.

Maintaining a GUI is far from the scope of developing the core machinery of a reverse engineering toolkit: it is preferred to have a separate project and community, allowing both projects to collaborate and to improve together - rather than forcing cli developers to think in gui problems and having to jump back and forth between the graphic aspect and the low level logic of the implementations.

In the past, there have been at least 5 different native user interfaces (ragui, r2gui, gradare, r2net, bokken) but none of them got enough maintenance power to take off and they all died.

In addition, r2 has an embedded webserver and ships some basic user interfaces written in html/js. You can start them like this:

$ r2 -c=H /bin/ls

After 3 years of private development, Hugo Teso; the author of Bokken (python-gtk gui of r2) released to the public another frontend of r2, this time written in c++ and qt, which has been very welcomed by the community.

This GUI was named Iaito, but as long as he prefered not to keep maintaining it, Xarkes decided to fork it under the name of Cutter (name voted by the community), and lead the project. This is how it looks:

   • https://github.com/radareorg/cutter.

The learning curve is usually somewhat steep at the beginning. Although after an hour of using it you should easily understand how most things work, and how to combine the various tools radare offers. You are encouraged to read the rest of this book to understand how some non-trivial things work, and to ultimately improve your skills.

Navigation, inspection and modification of a loaded binary file is performed using three simple actions: seek (to position), print (buffer), and alternate (write, append).

The 'seek' command is abbreviated as s and accepts an expression as its argument. The expression can be something like 10, +0x25, or [0x100+ptr_table]. If you are working with block-based files, you may prefer to set the block size to a required value with b command, and seek forward or backwards with positions aligned to it. Use s++ and s-- commands to navigate this way.

If radare2 opens an executable file, by default it will open the file in Virtual Addressing (VA) mode and the sections will be mapped to their virtual addresses. In VA mode, seeking is based on the virtual address and the starting position is set to the entry point of the executable. Using -n option you can suppress this default behavior and ask radare2 to open the file in non-VA mode for you. In non-VA mode, seeking is based on the offset from the beginning of the file.

The 'print' command is abbreviated as p and has a number of submodes — the second letter specifying a desired print mode. Frequent variants include px to print in hexadecimal, and pd for disassembling.

To be allowed to write files, specify the -w option to radare2 when opening a file. The w command can be used to write strings, hexpairs (x subcommand), or even assembly opcodes (a subcommand). Examples:

> w hello world ; string

> wx 90 90 90 90 ; hexpairs

> wa jmp 0x8048140 ; assemble

> wf inline.bin ; write contents of file

Appending a ? to a command will show its help message, for example, p?. Appending ?* will show commands starting with the given string, e.g. p?*.

To enter visual mode, press V<enter>. Use q to quit visual mode and return to the prompt.

In visual mode you can use HJKL keys to navigate (left, down, up, and right, respectively). You can use these keys in cursor mode toggled by c key. To select a byte range in cursor mode, hold down SHIFT key, and press navigation keys HJKL to mark your selection.

While in visual mode, you can also overwrite bytes by pressing i. You can press TAB to switch between the hex (middle) and string (right) columns. Pressing q inside the hex panel returns you to visual mode. By pressing p or P you can scroll different visual mode representations. There is a second most important visual mode - curses-like panels interface, accessible with V! command.

A general format for radare2 commands is as follows:

[.][times][cmd][~grep][@[@iter]addr!size][|>pipe] ;

People who use Vim daily and are familiar with its commands will find themselves at home. You will see this format used throughout the book. Commands are identified by a single case-sensitive character [a-zA-Z].

To repeatedly execute a command, prefix the command with a number:

px # run px

3px # run px 3 times

The ! prefix is used to execute a command in shell context. If you want to use the cmd callback from the I/O plugin you must prefix with =!.

Note that a single exclamation mark will run the command and print the output through the RCons API. This means that the execution will be blocking and not interactive. Use double exclamation marks -- !! -- to run a standard system call.

All the socket, filesystem and execution APIs can be restricted with the cfg.sandbox configuration variable.

A few examples:

ds ; call the debugger's 'step' command

px 200 @ esp ; show 200 hex bytes at esp

pc > file.c ; dump buffer as a C byte array to file.c

wx 90 @@ sym.* ; write a nop on every symbol

pd 2000 | grep eax ; grep opcodes that use the 'eax' register

px 20 ; pd 3 ; px 40 ; multiple commands in a single line

The standard UNIX pipe | is also available in the radare2 shell. You can use it to filter the output of an r2 command with any shell program that reads from stdin, such as grep, less, wc. If you do not want to spawn anything, or you can't, or the target system does not have the basic UNIX tools you need (Windows or embedded users), you can also use the built-in grep (~).

See ~? for help.

The ~ character enables internal grep-like function used to filter output of any command:

pd 20~call ; disassemble 20 instructions and grep output for 'call'

Additionally, you can grep either for columns or for rows:

pd 20~call:0 ; get first row

pd 20~call:1 ; get second row

pd 20~call[0] ; get first column

pd 20~call[1] ; get second column

Or even combine them:

pd 20~call:0[0] ; grep the first column of the first row matching 'call'

This internal grep function is a key feature for scripting radare2, because it can be used to iterate over a list of offsets or data generated by disassembler, ranges, or any other command. Refer to the loops section (iterators) for more information.

The @ character is used to specify a temporary offset at which the command to its left will be executed. The original seek position in a file is then restored.

For example, pd 5 @ 0x100000fce to disassemble 5 instructions at address 0x100000fce.

Most of the commands offer autocompletion support using <TAB> key, for example seek or flags commands. It offers autocompletion using all possible values, taking flag names in this case. Note that it is possible to see the history of the commands using the !~... command - it offers a visual mode to scroll through the radare2 command history.

To extend the autocompletion support to handle more commands or enable autocompletion to your own commands defined in core, I/O plugins you must use the !!! command.

Expressions are mathematical representations of 64-bit numerical values. They can be displayed in different formats, be compared or used with all commands accepting numeric arguments. Expressions can use traditional arithmetic operations, as well as binary and boolean ones. To evaluate mathematical expressions prepend them with command ?:

[0xb7f9d810]> ?vi 0x8048000

134512640

[0xv7f9d810]> ?vi 0x8048000+34

134512674

[0xb7f9d810]> ?vi 0x8048000+0x34

134512692

[0xb7f9d810]> ? 1+2+3-4*3

hex 0xfffffffffffffffa

octal 01777777777777777777772

unit 17179869184.0G

segment fffff000:0ffa

int64 -6

string "\xfa\xff\xff\xff\xff\xff\xff\xff"

binary 0b1111111111111111111111111111111111111111111111111111111111111010

fvalue: -6.0

float: nanf

double: nan

trits 0t11112220022122120101211020120210210211201

Supported arithmetic operations are:

   • + : addition

   • - : subtraction

   • * : multiplication

   • / : division

   • % : modulus

   • > : shift right

   • < : shift left

[0x00000000]> ?vi 1+2+3

6

To use of logical OR should quote the whole command to avoid executing the | pipe:

[0x00000000]> "? 1 | 2"

hex 0x3

octal 03

unit 3

segment 0000:0003

int32 3

string "\x03"

binary 0b00000011

fvalue: 2.0

float: 0.000000f

double: 0.000000

trits 0t10

Numbers can be displayed in several formats:

0x033 : hexadecimal can be displayed

3334 : decimal

sym.fo : resolve flag offset

10K : KBytes 10*1024

10M : MBytes 10*1024*1024

You can also use variables and seek positions to build complex expressions.

Use the ?$? command to list all the available commands or read the refcard chapter of this book.

$$ here (the current virtual seek)

$l opcode length

$s file size

$j jump address (e.g. jmp 0x10, jz 0x10 => 0x10)

$f jump fail address (e.g. jz 0x10 => next instruction)

$m opcode memory reference (e.g. mov eax,[0x10] => 0x10)

$b block size

Some more examples:

[0x4A13B8C0]> ? $m + $l

140293837812900 0x7f98b45df4a4 03771426427372244 130658.0G 8b45d000:04a4 140293837812900 10100100 140293837812900.0 -0.000000

[0x4A13B8C0]> pd 1 @ +$l

0x4A13B8C2 call 0x4a13c000

To debug a program, start radare with the -d option. Note that you can attach to a running process by specifying its PID, or you can start a new program by specifying its name and parameters:

$ pidof mc

32220

$ r2 -d 32220

$ r2 -d /bin/ls

$ r2 -a arm -b 16 -d gdb://192.168.1.43:9090

...

In the second case, the debugger will fork and load the debugee ls program in memory.

It will pause its execution early in ld.so dynamic linker. As a result, you will not yet see the entrypoint or any shared libraries at this point.

You can override this behavior by setting another name for an entry breakpoint. To do this, add a radare command e dbg.bep=entry or e dbg.bep=main to your startup script, usually it is ~/.config/radare2/radare2rc.

Another way to continue until a specific address is by using the dcu command. Which means: "debug continue until" taking the address of the place to stop at. For example:

dcu main

Be warned that certain malware or other tricky programs can actually execute code before main() and thus you'll be unable to control them. (Like the program constructor or the tls initializers)

Below is a list of most common commands used with debugger:

> d? ; get help on debugger commands

> ds 3 ; step 3 times

> db 0x8048920 ; setup a breakpoint

> db -0x8048920 ; remove a breakpoint

> dc ; continue process execution

> dcs ; continue until syscall

> dd ; manipulate file descriptors

> dm ; show process maps

> dmp A S rwx ; change permissions of page at A and size S

> dr eax=33 ; set register value. eax = 33

There is another option for debugging in radare, which may be easier: using visual mode.

That way you will neither need to remember many commands nor to keep program state in your mind.

To enter visual debugger mode use Vpp:

[0xb7f0c8c0]> Vpp

The initial view after entering visual mode is a hexdump view of the current target program counter (e.g., EIP for x86). Pressing p will allow you to cycle through the rest of visual mode views. You can press p and P to rotate through the most commonly used print modes. Use F7 or s to step into and F8 or S to step over current instruction. With the c key you can toggle the cursor mode to mark a byte range selection (for example, to later overwrite them with nop). You can set breakpoints with F2 key.

In visual mode you can enter regular radare commands by prepending them with :. For example, to dump a one block of memory contents at ESI:

<Press ':'>

x @ esi

To get help on visual mode, press ?. To scroll the help screen, use arrows. To exit the help view, press q.

A frequently used command is dr, which is used to read or write values of the target's general purpose registers. For a more compact register value representation you might use dr= command. You can also manipulate the hardware and the extended/floating point registers.

The core reads ~/.config/radare2/radare2rc while starting. You can add e commands to this file to tune the radare2 configuration to your taste.

To prevent radare2 from parsing this file at startup, pass it the -N option.

All the configuration of radare2 is done with the eval commands. A typical startup configuration file looks like this:

$ cat ~/.radare2rc

e scr.color = 1

e dbg.bep = loader

The configuration can also be changed with -e <config=value> command-line option. This way you can adjust configuration from the command line, keeping the .radare2rc file intact. For example, to start with empty configuration and then adjust scr.color and asm.syntax the following line may be used:

$ radare2 -N -e scr.color=1 -e asm.syntax=intel -d /bin/ls

Internally, the configuration is stored in a hash table. The variables are grouped in namespaces: cfg., file., dbg., scr. and so on.

To get a list of all configuration variables just type e in the command line prompt. To limit the output to a selected namespace, pass it with an ending dot to e. For example, e file. will display all variables defined inside the "file" namespace.

To get help about e command type e?:

Usage: e [var[=value]] Evaluable vars

| e?asm.bytes show description

| e?? list config vars with description

| e a get value of var 'a'

| e a=b set var 'a' the 'b' value

| e var=? print all valid values of var

| e var=?? print all valid values of var with description

| e.a=b same as 'e a=b' but without using a space

| e,k=v,k=v,k=v comma separated k[=v]

| e- reset config vars

| e* dump config vars in r commands

| e!a invert the boolean value of 'a' var

| ec [k] [color] set color for given key (prompt, offset, ...)

| eevar open editor to change the value of var

| ed open editor to change the ~/.radare2rc

| ej list config vars in JSON

| env [k[=v]] get/set environment variable

| er [key] set config key as readonly. no way back

| es [space] list all eval spaces [or keys]

| et [key] show type of given config variable

| ev [key] list config vars in verbose format

| evj [key] list config vars in verbose format in JSON

A simpler alternative to the e command is accessible from the visual mode. Type Ve to enter it, use arrows (up, down, left, right) to navigate the configuration, and q to exit it. The start screen for the visual configuration edit looks like this:

[EvalSpace]

Console access is wrapped in API that permits to show the output of any command as ANSI, W32 Console or HTML formats. This allows radare's core to run inside environments with limited displaying capabilities, like kernels or embedded devices. It is still possible to receive data from it in your favorite format.

To enable colors support by default, add a corresponding configuration option to the .radare2 configuration file:

$ echo 'e scr.color=1' >> ~/.radare2rc

Note that enabling colors is not a boolean option. Instead, it is a number because there are different color depth levels. This is:

   • 0: black and white

   • 1: 16 basic ANSI colors

   • 2: 256 scale colors

   • 3: 24bit true color

The reason for having such user-defined options is because there's no standard or portable way for the terminal programs to query the console to determine the best configuration, same goes for charset encodings, so r2 allows you to choose that by hand.

Usually, serial consoles may work with 0 or 1, while xterms may support up to 3. RCons will try to find the closest color scheme for your theme when you choose a different them with the eco command.

It is possible to configure the color of almost any element of disassembly output. For *NIX terminals, r2 accepts color specification in RGB format. To change the console color palette use ec command.

Type ec to get a list of all currently used colors. Type ecs to show a color palette to pick colors from:

You can create your own color theme, but radare2 have its own predefined ones. Use the eco command to list or select them.

After selecting one, you can compare between the color scheme of the shell and the current theme by pressing Ctrl-Shift and then right arrow key for the toggle.

In visual mode use the R key to randomize colors or choose the next theme in the list.

Use r2 -H to list all the environment variables that matter to know where it will be looking for files. Those paths depend on the way (and operating system) you have built r2 for.

R2_PREFIX=/usr

MAGICPATH=/usr/share/radare2/2.8.0-git/magic

PREFIX=/usr

INCDIR=/usr/include/libr

LIBDIR=/usr/lib64

LIBEXT=so

RCONFIGHOME=/home/user/.config/radare2

RDATAHOME=/home/user/.local/share/radare2

RCACHEHOME=/home/user/.cache/radare2

LIBR_PLUGINS=/usr/lib/radare2/2.8.0-git

USER_PLUGINS=/home/user/.local/share/radare2/plugins

USER_ZIGNS=/home/user/.local/share/radare2/zigns

Most command names in radare are derived from action names. They should be easy to remember, as they are short. Actually, all commands are single letters. Subcommands or related commands are specified using the second character of the command name. For example, / foo is a command to search plain string, while /x 90 90 is used to look for hexadecimal pairs.

The general format for a valid command (as explained in the Command Format chapter) looks like this:

[.][times][cmd][~grep][@[@iter]addr!size][|>pipe] ; ...

For example,

> 3s +1024 ; seeks three times 1024 from the current seek

If a command starts with =!, the rest of the string is passed to the currently loaded IO plugin (a debugger, for example). Most plugins provide help messages with =!? or =!help.

$ r2 -d /bin/ls

> =!help ; handled by the IO plugin

If a command starts with !, posix_system() is called to pass the command to your shell. Check !? for more options and usage examples.

> !ls ; run `ls` in the shell

The meaning of the arguments (iter, addr, size) depends on the specific command. As a rule of thumb, most commands take a number as an argument to specify the number of bytes to work with, instead of the currently defined block size. Some commands accept math expressions or strings.

> px 0x17 ; show 0x17 bytes in hexs at current seek

> s base+0x33 ; seeks to flag 'base' plus 0x33

> / lib ; search for 'lib' string.

The @ sign is used to specify a temporary offset location or a seek position at which the command is executed, instead of current seek position. This is quite useful as you don't have to seek around all the time.

> p8 10 @ 0x4010 ; show 10 bytes at offset 0x4010

> f patata @ 0x10 ; set 'patata' flag at offset 0x10

Using @@ you can execute a single command on a list of flags matching the glob. You can think of this as a foreach operation:

> s 0

> / lib ; search 'lib' string

> p8 20 @@ hit0_* ; show 20 hexpairs at each search hit

The > operation is used to redirect the output of a command into a file (overwriting it if it already exists).

> pr > dump.bin ; dump 'raw' bytes of current block to file named 'dump.bin'

> f > flags.txt ; dump flag list to 'flags.txt'

The | operation (pipe) is similar to what you are used to expect from it in a *NIX shell: an output of one command as input to another.

[0x4A13B8C0]> f | grep section | grep text

0x0805f3b0 512 section._text

0x080d24b0 512 section._text_end

You can pass several commands in a single line by separating them with a semicolon ;:

> px ; dr

Using _, you can print the result that was obtained by the last command.

[0x00001060]> axt 0x00002004

main 0x1181 [DATA] lea rdi, str.argv__2d_:__s

[0x00001060]> _

main 0x1181 [DATA] lea rdi, str.argv__2d_:__s

To move around the file we are inspecting we will need to change the offset at which we are using the s command.

The argument is a math expression that can contain flag names, parenthesis, addition, substraction, multiplication of immediates of contents of memory using brackets.

Some example commands:

[0x00000000]> s 0x10

[0x00000010]> s+4

[0x00000014]> s-

[0x00000010]> s+

[0x00000014]>

Observe how the prompt offset changes. The first line moves the current offset to the address 0x10.

The second does a relative seek 4 bytes forward.

And finally, the last 2 commands are undoing, and redoing the last seek operations.

Instead of using just numbers, we can use complex expressions, or basic arithmetic operations to represent the address to seek.

To do this, check the ?$? Help message which describes the internal variables that can be used in the expressions. For example, this is the same as doing s+4 .

[0x00000000]> s $$+4

From the debugger (or when emulating) we can also use the register names as references. They are loaded as flags with the .dr* command, which happens under the hood.

[0x00000000]> s rsp+0x40

Here's the full help of the s command. We will explain in more detail below.

[0x00000000]> s?

Usage: s # Help for the seek commands. See ?$? to see all variables

| s Print current address

| s.hexoff Seek honoring a base from core->offset

| s:pad Print current address with N padded zeros (defaults to 8)

| s addr Seek to address

| s- Undo seek

| s-* Reset undo seek history

| s- n Seek n bytes backward

| s--[n] Seek blocksize bytes backward (/=n)

| s+ Redo seek

| s+ n Seek n bytes forward

| s++[n] Seek blocksize bytes forward (/=n)

| s[j*=!] List undo seek history (JSON, =list, *r2, !=names, s==)

| s/ DATA Search for next occurrence of 'DATA'

| s/x 9091 Search for next occurrence of \x90\x91

| sa [[+-]a] [asz] Seek asz (or bsize) aligned to addr

| sb Seek aligned to bb start

| sC[?] string Seek to comment matching given string

| sf Seek to next function (f->addr+f->size)

| sf function Seek to address of specified function

| sf. Seek to the beginning of current function

| sg/sG Seek begin (sg) or end (sG) of section or file

| sl[?] [+-]line Seek to line

| sn/sp ([nkey]) Seek to next/prev location, as specified by scr.nkey

| so [N] Seek to N next opcode(s)

| sr pc Seek to register

| ss Seek silently (without adding an entry to the seek history)

As a test file, let's use a simple hello_world.c compiled in Linux ELF format. After we compile it let's open it with radare2:

$ r2 hello_world

Now we have the command prompt:

[0x00400410]>

And it is time to go deeper.

All seeking commands that take an address as a command parameter can use any numeral base such as hex, octal, binary or decimal.

Seek to an address 0x0. An alternative command is simply 0x0

[0x00400410]> s 0x0

[0x00000000]>

Print current address:

[0x00000000]> s

0x0

[0x00000000]>

There is an alternate way to print current position: ?v $$.

Seek N positions forward, space is optional:

[0x00000000]> s+ 128

[0x00000080]>

Undo last two seeks to return to the initial address:

[0x00000080]> s-

[0x00000000]> s-

[0x00400410]>

We are back at 0x00400410.

There's also a command to show the seek history:

[0x00400410]> s*

f undo_3 @ 0x400410

f undo_2 @ 0x40041a

f undo_1 @ 0x400410

f undo_0 @ 0x400411

# Current undo/redo position.

f redo_0 @ 0x4005b4

The block size determines how many bytes radare2 commands will process when not given an explicit size argument. You can temporarily change the block size by specifying a numeric argument to the print commands. For example px 20.

[0x00000000]> b?

Usage: b[f] [arg] # Get/Set block size

| b 33 set block size to 33

| b eip+4 numeric argument can be an expression

| b display current block size

| b+3 increase blocksize by 3

| b-16 decrease blocksize by 16

| b* display current block size in r2 command

| bf foo set block size to flag size

| bj display block size information in JSON

| bm 1M set max block size

The b command is used to change the block size:

[0x00000000]> b 0x100 # block size = 0x100

[0x00000000]> b+16 # ... = 0x110

[0x00000000]> b-32 # ... = 0xf0

The bf command is used to change the block size to value specified by a flag. For example, in symbols, the block size of the flag represents the size of the function. To make that work, you have to either run function analysis af (which is included in aa) or manually seek and define some functions e.g. via Vd.

[0x00000000]> bf sym.main # block size = sizeof(sym.main)

[0x00000000]> pD @ sym.main # disassemble sym.main

You can combine two operations in a single pdf command. Except that pdf neither uses nor affects global block size.

[0x00000000]> pdf @ sym.main # disassemble sym.main

Another way around is to use special variables $FB and $FS which denote Function's Beginning and Size at the current seek. Read more about Usable variables.

[0x00000000]> s sym.main + 0x04

[0x00001ec9]> pD @ $FB !$FS # disassemble current function

╭ 211: int main (int argc, char **argv, char **envp);

│ 0x00001ec5 55 push rbp

│ 0x00001ec6 4889e5 mov rbp, rsp

│ 0x00001ec9 4881ecc0000000 sub rsp, 0xc0

...

╰ 0x00001f97 c3 ret

Note: don't put space after ! size designator. See also Command Format.

The concept of sections is tied to the information extracted from the binary. We can display this information by using the i command.

Displaying information about sections:

[0x00005310]> iS

[Sections]

00 0x00000000 0 0x00000000 0 ----

01 0x00000238 28 0x00000238 28 -r-- .interp

02 0x00000254 32 0x00000254 32 -r-- .note.ABI_tag

03 0x00000278 176 0x00000278 176 -r-- .gnu.hash

04 0x00000328 3000 0x00000328 3000 -r-- .dynsym

05 0x00000ee0 1412 0x00000ee0 1412 -r-- .dynstr

06 0x00001464 250 0x00001464 250 -r-- .gnu.version

07 0x00001560 112 0x00001560 112 -r-- .gnu.version_r

08 0x000015d0 4944 0x000015d0 4944 -r-- .rela.dyn

09 0x00002920 2448 0x00002920 2448 -r-- .rela.plt

10 0x000032b0 23 0x000032b0 23 -r-x .init

...

As you may know, binaries have sections and maps. The sections define the contents of a portion of the file that can be mapped in memory (or not). What is mapped is defined by the segments.

Before the IO refactoring done by condret, the S command was used to manage what we now call maps. Currently the S command is deprecated because iS and om should be enough.

Firmware images, bootloaders and binary files usually place various sections of a binary at different addresses in memory. To represent this behavior, radare offers the iS. Use iS? to get the help message. To list all created sections use iS (or iSj to get the json format). The iS= will show the region bars in ascii-art.

You can create a new mapping using the om subcommand as follows:

om fd vaddr [size] [paddr] [rwx] [name]

For Example:

[0x0040100]> om 4 0x00000100 0x00400000 0x0001ae08 rwx test

You can also use om command to view information about mapped sections:

[0x00401000]> om

6 fd: 4 +0x0001ae08 0x00000100 - 0x004000ff rwx test

5 fd: 3 +0x00000000 0x00000000 - 0x0000055f r-- fmap.LOAD0

4 fd: 3 +0x00001000 0x00001000 - 0x000011e4 r-x fmap.LOAD1

3 fd: 3 +0x00002000 0x00002000 - 0x0000211f r-- fmap.LOAD2

2 fd: 3 +0x00002de8 0x00003de8 - 0x0000402f r-- fmap.LOAD3

1 fd: 4 +0x00000000 0x00004030 - 0x00004037 rw- mmap.LOAD3

Use om? to get all the possible subcommands. To list all the defined maps use om (or omj to get the json format or om* to get the r2 commands format). To get the ascii art view use om=.

It is also possible to delete the mapped section using the om-mapid command.

For Example:

[0x00401000]> om-6

Radare's I/O subsystem allows you to map the contents of files into the same I/O space used to contain a loaded binary. New contents can be placed at random offsets.

The o command permits the user to open a file, this is mapped at offset 0 unless it has a known binary header and then the maps are created in virtual addresses.

Sometimes, we want to rebase a binary, or maybe we want to load or map the file in a different address.

When launching r2, the base address can be changed with the -B flag. But you must notice the difference when opening files with unknown headers, like bootloaders, so we need to map them using the -m flag (or specifying it as argument to the o command).

radare2 is able to open files and map portions of them at random places in memory specifying attributes like permissions and name. It is the perfect basic tooling to reproduce an environment like a core file, a debug session, by also loading and mapping all the libraries the binary depends on.

Opening files (and mapping them) is done using the o (open) command. Let's read the help:

[0x00000000]> o?

|Usage: o [com- ] [file] ([offset])

| o list opened files

| o-1 close file descriptor 1

| o-!* close all opened files

| o-- close all files, analysis, binfiles, flags, same as !r2 --

| o [file] open [file] file in read-only

| o+ [file] open file in read-write mode

| o [file] 0x4000 rwx map file at 0x4000

| oa[-] [A] [B] [filename] Specify arch and bits for given file

| oq list all open files

| o* list opened files in r2 commands

| o. [len] open a malloc://[len] copying the bytes from current offset

| o= list opened files (ascii-art bars)

| ob[?] [lbdos] [...] list opened binary files backed by fd

| oc [file] open core file, like relaunching r2

| of [file] open file and map it at addr 0 as read-only

| oi[-|idx] alias for o, but using index instead of fd

| oj[?] list opened files in JSON format

| oL list all IO plugins registered

| om[?] create, list, remove IO maps

| on [file] 0x4000 map raw file at 0x4000 (no r_bin involved)

| oo[?] reopen current file (kill+fork in debugger)

| oo+ reopen current file in read-write

| ood[r] [args] reopen in debugger mode (with args)

| oo[bnm] [...] see oo? for help

| op [fd] prioritize given fd (see also ob)

| ox fd fdx exchange the descs of fd and fdx and keep the mapping

Prepare a simple layout:

$ rabin2 -l /bin/ls

[Linked libraries]

libselinux.so.1

librt.so.1

libacl.so.1

libc.so.6

One of the key features of radare2 is displaying information in many formats. The goal is to offer a selection of display choices to interpret binary data in the best possible way.

Binary data can be represented as integers, shorts, longs, floats, timestamps, hexpair strings, or more complex formats like C structures, disassembly listings, decompilation listing, be a result of an external processing...

Below is a list of available print modes listed by p?:

[0x00005310]> p?

|Usage: p[=68abcdDfiImrstuxz] [arg|len] [@addr]

| p[b|B|xb] [len] ([S]) bindump N bits skipping S bytes

| p[iI][df] [len] print N ops/bytes (f=func) (see pi? and pdi)

| p[kK] [len] print key in randomart (K is for mosaic)

| p-[?][jh] [mode] bar|json|histogram blocks (mode: e?search.in)

| p2 [len] 8x8 2bpp-tiles

| p3 [file] print stereogram (3D)

| p6[de] [len] base64 decode/encode

| p8[?][j] [len] 8bit hexpair list of bytes

| p=[?][bep] [N] [L] [b] show entropy/printable chars/chars bars

| pa[edD] [arg] pa:assemble pa[dD]:disasm or pae: esil from hex

| pA[n_ops] show n_ops address and type

| pb[?] [n] bitstream of N bits

| pB[?] [n] bitstream of N bytes

| pc[?][p] [len] output C (or python) format

| pC[aAcdDxw] [rows] print disassembly in columns (see hex.cols and pdi)

| pd[?] [sz] [a] [b] disassemble N opcodes (pd) or N bytes (pD)

| pf[?][.nam] [fmt] print formatted data (pf.name, pf.name $<expr>)

| pF[?][apx] print asn1, pkcs7 or x509

| pg[?][x y w h] [cmd] create new visual gadget or print it (see pg? for details)

| ph[?][=|hash] ([len]) calculate hash for a block

| pj[?] [len] print as indented JSON

| pm[?] [magic] print libmagic data (see pm? and /m?)

| po[?] hex print operation applied to block (see po?)

| pp[?][sz] [len] print patterns, see pp? for more help

| pq[?][is] [len] print QR code with the first Nbytes

| pr[?][glx] [len] print N raw bytes (in lines or hexblocks, 'g'unzip)

| ps[?][pwz] [len] print pascal/wide/zero-terminated strings

| pt[?][dn] [len] print different timestamps

| pu[?][w] [len] print N url encoded bytes (w=wide)

| pv[?][jh] [mode] show variable/pointer/value in memory

| pwd display current working directory

| px[?][owq] [len] hexdump of N bytes (o=octal, w=32bit, q=64bit)

| pz[?] [len] print zoom view (see pz? for help)

[0x00005310]>

Tip: when using json output, you can append the ~{} to the command to get a pretty-printed version of the output:

[0x00000000]> oj

[{"raised":false,"fd":563280,"uri":"malloc://512","from":0,"writable":true,"size":512,"overlaps":false}]

[0x00000000]> oj~{}

[

{

"raised": false,

"fd": 563280,

"uri": "malloc://512",

"from": 0,

"writable": true,

"size": 512,

"overlaps": false

}

]

For more on the magical powers of ~ see the help in ?@?, and the Command Format chapter earlier in the book.

This book is an updated version (started by maijin) of the original radare1 book (written by pancake). Which is actively maintained and updated by many contributors over the Internet.

Check the Github site to add new contents or fix typos:

   • Github: https://github.com/radareorg/radare2book

   • Online: https://book.rada.re/

In 2006, Sergi Àlvarez (aka pancake) was working as a forensic analyst. Since he wasn't allowed to use the company software for his personal needs, he decided to write a small tool-a hexadecimal editor-with very basic characteristics:

   • be extremely portable (unix friendly, command line, c, small)

   • open disk devices, this is using 64bit offsets

   • search for a string or hexpair

   • review and dump the results to disk

The editor was originally designed to recover a deleted file from an HFS+ partition.

After that, pancake decided to extend the tool to have a pluggable io to be able to attach to processes and implemented the debugger functionalities, support for multiple architectures, and code analysis.

Since then, the project has evolved to provide a complete framework for analyzing binaries, while making use of basic UNIX concepts. Those concepts include the famous "everything is a file", "small programs that interact using stdin/stdout", and "keep it simple" paradigms.

The need for scripting showed the fragility of the initial design: a monolithic tool made the API hard to use, and so a deep refactoring was needed. In 2009 radare2 (r2) was born as a fork of radare1. The refactor added flexibility and dynamic features. This enabled much better integration, paving the way to use r2 from different programming languages. Later on, the r2pipe API allowed access to radare2 via pipes from any language.

What started as a one-man project, with some eventual contributions, gradually evolved into a big community-based project around 2014. The number of users was growing fast, and the author-and main developer-had to switch roles from coder to manager in order to integrate the work of the different developers that were joining the project.

Instructing users to report their issues allows the project to define new directions to evolve in. Everything is managed in radare2's GitHub and discussed in the Telegram channel.

The project remains active at the time of writing this book, and there are several side projects that provide, among other things, a graphical user interface (Cutter), a decompiler (r2dec, radeco), Frida integration (r2frida), Yara, Unicorn, Keystone, and many other projects indexed in the r2pm (the radare2 package manager).

Since 2016, the community gathers once a year in r2con, a congress around radare2 that takes place in Barcelona.

./configure --prefix=/old/r2/prefix/installation

make purge

Radare2 has seen many different user interfaces being developed over the years.

Maintaining a GUI is far from the scope of developing the core machinery of a reverse engineering toolkit: it is preferred to have a separate project and community, allowing both projects to collaborate and to improve together - rather than forcing cli developers to think in gui problems and having to jump back and forth between the graphic aspect and the low level logic of the implementations.

In the past, there have been at least 5 different native user interfaces (ragui, r2gui, gradare, r2net, bokken) but none of them got enough maintenance power to take off and they all died.

In addition, r2 has an embedded webserver and ships some basic user interfaces written in html/js. You can start them like this:

$ r2 -c=H /bin/ls

After 3 years of private development, Hugo Teso; the author of Bokken (python-gtk gui of r2) released to the public another frontend of r2, this time written in c++ and qt, which has been very welcomed by the community.

This GUI was named Iaito, but as long as he prefered not to keep maintaining it, Xarkes decided to fork it under the name of Cutter (name voted by the community), and lead the project. This is how it looks:

   • https://github.com/radareorg/cutter.

The learning curve is usually somewhat steep at the beginning. Although after an hour of using it you should easily understand how most things work, and how to combine the various tools radare offers. You are encouraged to read the rest of this book to understand how some non-trivial things work, and to ultimately improve your skills.

Navigation, inspection and modification of a loaded binary file is performed using three simple actions: seek (to position), print (buffer), and alternate (write, append).

The 'seek' command is abbreviated as s and accepts an expression as its argument. The expression can be something like 10, +0x25, or [0x100+ptr_table]. If you are working with block-based files, you may prefer to set the block size to a required value with b command, and seek forward or backwards with positions aligned to it. Use s++ and s-- commands to navigate this way.

If radare2 opens an executable file, by default it will open the file in Virtual Addressing (VA) mode and the sections will be mapped to their virtual addresses. In VA mode, seeking is based on the virtual address and the starting position is set to the entry point of the executable. Using -n option you can suppress this default behavior and ask radare2 to open the file in non-VA mode for you. In non-VA mode, seeking is based on the offset from the beginning of the file.

The 'print' command is abbreviated as p and has a number of submodes — the second letter specifying a desired print mode. Frequent variants include px to print in hexadecimal, and pd for disassembling.

To be allowed to write files, specify the -w option to radare2 when opening a file. The w command can be used to write strings, hexpairs (x subcommand), or even assembly opcodes (a subcommand). Examples:

> w hello world ; string

> wx 90 90 90 90 ; hexpairs

> wa jmp 0x8048140 ; assemble

> wf inline.bin ; write contents of file

Appending a ? to a command will show its help message, for example, p?. Appending ?* will show commands starting with the given string, e.g. p?*.

To enter visual mode, press V<enter>. Use q to quit visual mode and return to the prompt.

In visual mode you can use HJKL keys to navigate (left, down, up, and right, respectively). You can use these keys in cursor mode toggled by c key. To select a byte range in cursor mode, hold down SHIFT key, and press navigation keys HJKL to mark your selection.

While in visual mode, you can also overwrite bytes by pressing i. You can press TAB to switch between the hex (middle) and string (right) columns. Pressing q inside the hex panel returns you to visual mode. By pressing p or P you can scroll different visual mode representations. There is a second most important visual mode - curses-like panels interface, accessible with V! command.

A general format for radare2 commands is as follows:

[.][times][cmd][~grep][@[@iter]addr!size][|>pipe] ;

People who use Vim daily and are familiar with its commands will find themselves at home. You will see this format used throughout the book. Commands are identified by a single case-sensitive character [a-zA-Z].

To repeatedly execute a command, prefix the command with a number:

px # run px

3px # run px 3 times

The ! prefix is used to execute a command in shell context. If you want to use the cmd callback from the I/O plugin you must prefix with =!.

Note that a single exclamation mark will run the command and print the output through the RCons API. This means that the execution will be blocking and not interactive. Use double exclamation marks -- !! -- to run a standard system call.

All the socket, filesystem and execution APIs can be restricted with the cfg.sandbox configuration variable.

A few examples:

ds ; call the debugger's 'step' command

px 200 @ esp ; show 200 hex bytes at esp

pc > file.c ; dump buffer as a C byte array to file.c

wx 90 @@ sym.* ; write a nop on every symbol

pd 2000 | grep eax ; grep opcodes that use the 'eax' register

px 20 ; pd 3 ; px 40 ; multiple commands in a single line

The standard UNIX pipe | is also available in the radare2 shell. You can use it to filter the output of an r2 command with any shell program that reads from stdin, such as grep, less, wc. If you do not want to spawn anything, or you can't, or the target system does not have the basic UNIX tools you need (Windows or embedded users), you can also use the built-in grep (~).

See ~? for help.

The ~ character enables internal grep-like function used to filter output of any command:

pd 20~call ; disassemble 20 instructions and grep output for 'call'

Additionally, you can grep either for columns or for rows:

pd 20~call:0 ; get first row

pd 20~call:1 ; get second row

pd 20~call[0] ; get first column

pd 20~call[1] ; get second column

Or even combine them:

pd 20~call:0[0] ; grep the first column of the first row matching 'call'

This internal grep function is a key feature for scripting radare2, because it can be used to iterate over a list of offsets or data generated by disassembler, ranges, or any other command. Refer to the loops section (iterators) for more information.

The @ character is used to specify a temporary offset at which the command to its left will be executed. The original seek position in a file is then restored.

For example, pd 5 @ 0x100000fce to disassemble 5 instructions at address 0x100000fce.

Most of the commands offer autocompletion support using <TAB> key, for example seek or flags commands. It offers autocompletion using all possible values, taking flag names in this case. Note that it is possible to see the history of the commands using the !~... command - it offers a visual mode to scroll through the radare2 command history.

To extend the autocompletion support to handle more commands or enable autocompletion to your own commands defined in core, I/O plugins you must use the !!! command.

Expressions are mathematical representations of 64-bit numerical values. They can be displayed in different formats, be compared or used with all commands accepting numeric arguments. Expressions can use traditional arithmetic operations, as well as binary and boolean ones. To evaluate mathematical expressions prepend them with command ?:

[0xb7f9d810]> ?vi 0x8048000

134512640

[0xv7f9d810]> ?vi 0x8048000+34

134512674

[0xb7f9d810]> ?vi 0x8048000+0x34

134512692

[0xb7f9d810]> ? 1+2+3-4*3

hex 0xfffffffffffffffa

octal 01777777777777777777772

unit 17179869184.0G

segment fffff000:0ffa

int64 -6

string "\xfa\xff\xff\xff\xff\xff\xff\xff"

binary 0b1111111111111111111111111111111111111111111111111111111111111010

fvalue: -6.0

float: nanf

double: nan

trits 0t11112220022122120101211020120210210211201

Supported arithmetic operations are:

   • + : addition

   • - : subtraction

   • * : multiplication

   • / : division

   • % : modulus

   • > : shift right

   • < : shift left

[0x00000000]> ?vi 1+2+3

6

To use of logical OR should quote the whole command to avoid executing the | pipe:

[0x00000000]> "? 1 | 2"

hex 0x3

octal 03

unit 3

segment 0000:0003

int32 3

string "\x03"

binary 0b00000011

fvalue: 2.0

float: 0.000000f

double: 0.000000

trits 0t10

Numbers can be displayed in several formats:

0x033 : hexadecimal can be displayed

3334 : decimal

sym.fo : resolve flag offset

10K : KBytes 10*1024

10M : MBytes 10*1024*1024

You can also use variables and seek positions to build complex expressions.

Use the ?$? command to list all the available commands or read the refcard chapter of this book.

$$ here (the current virtual seek)

$l opcode length

$s file size

$j jump address (e.g. jmp 0x10, jz 0x10 => 0x10)

$f jump fail address (e.g. jz 0x10 => next instruction)

$m opcode memory reference (e.g. mov eax,[0x10] => 0x10)

$b block size

Some more examples:

[0x4A13B8C0]> ? $m + $l

140293837812900 0x7f98b45df4a4 03771426427372244 130658.0G 8b45d000:04a4 140293837812900 10100100 140293837812900.0 -0.000000

[0x4A13B8C0]> pd 1 @ +$l

0x4A13B8C2 call 0x4a13c000

To debug a program, start radare with the -d option. Note that you can attach to a running process by specifying its PID, or you can start a new program by specifying its name and parameters:

$ pidof mc

32220

$ r2 -d 32220

$ r2 -d /bin/ls

$ r2 -a arm -b 16 -d gdb://192.168.1.43:9090

...

In the second case, the debugger will fork and load the debugee ls program in memory.

It will pause its execution early in ld.so dynamic linker. As a result, you will not yet see the entrypoint or any shared libraries at this point.

You can override this behavior by setting another name for an entry breakpoint. To do this, add a radare command e dbg.bep=entry or e dbg.bep=main to your startup script, usually it is ~/.config/radare2/radare2rc.

Another way to continue until a specific address is by using the dcu command. Which means: "debug continue until" taking the address of the place to stop at. For example:

dcu main

Be warned that certain malware or other tricky programs can actually execute code before main() and thus you'll be unable to control them. (Like the program constructor or the tls initializers)

Below is a list of most common commands used with debugger:

> d? ; get help on debugger commands

> ds 3 ; step 3 times

> db 0x8048920 ; setup a breakpoint

> db -0x8048920 ; remove a breakpoint

> dc ; continue process execution

> dcs ; continue until syscall

> dd ; manipulate file descriptors

> dm ; show process maps

> dmp A S rwx ; change permissions of page at A and size S

> dr eax=33 ; set register value. eax = 33

There is another option for debugging in radare, which may be easier: using visual mode.

That way you will neither need to remember many commands nor to keep program state in your mind.

To enter visual debugger mode use Vpp:

[0xb7f0c8c0]> Vpp

The initial view after entering visual mode is a hexdump view of the current target program counter (e.g., EIP for x86). Pressing p will allow you to cycle through the rest of visual mode views. You can press p and P to rotate through the most commonly used print modes. Use F7 or s to step into and F8 or S to step over current instruction. With the c key you can toggle the cursor mode to mark a byte range selection (for example, to later overwrite them with nop). You can set breakpoints with F2 key.

In visual mode you can enter regular radare commands by prepending them with :. For example, to dump a one block of memory contents at ESI:

<Press ':'>

x @ esi

To get help on visual mode, press ?. To scroll the help screen, use arrows. To exit the help view, press q.

A frequently used command is dr, which is used to read or write values of the target's general purpose registers. For a more compact register value representation you might use dr= command. You can also manipulate the hardware and the extended/floating point registers.

The core reads ~/.config/radare2/radare2rc while starting. You can add e commands to this file to tune the radare2 configuration to your taste.

To prevent radare2 from parsing this file at startup, pass it the -N option.

All the configuration of radare2 is done with the eval commands. A typical startup configuration file looks like this:

$ cat ~/.radare2rc

e scr.color = 1

e dbg.bep = loader

The configuration can also be changed with -e <config=value> command-line option. This way you can adjust configuration from the command line, keeping the .radare2rc file intact. For example, to start with empty configuration and then adjust scr.color and asm.syntax the following line may be used:

$ radare2 -N -e scr.color=1 -e asm.syntax=intel -d /bin/ls

Internally, the configuration is stored in a hash table. The variables are grouped in namespaces: cfg., file., dbg., scr. and so on.

To get a list of all configuration variables just type e in the command line prompt. To limit the output to a selected namespace, pass it with an ending dot to e. For example, e file. will display all variables defined inside the "file" namespace.

To get help about e command type e?:

Usage: e [var[=value]] Evaluable vars

| e?asm.bytes show description

| e?? list config vars with description

| e a get value of var 'a'

| e a=b set var 'a' the 'b' value

| e var=? print all valid values of var

| e var=?? print all valid values of var with description

| e.a=b same as 'e a=b' but without using a space

| e,k=v,k=v,k=v comma separated k[=v]

| e- reset config vars

| e* dump config vars in r commands

| e!a invert the boolean value of 'a' var

| ec [k] [color] set color for given key (prompt, offset, ...)

| eevar open editor to change the value of var

| ed open editor to change the ~/.radare2rc

| ej list config vars in JSON

| env [k[=v]] get/set environment variable

| er [key] set config key as readonly. no way back

| es [space] list all eval spaces [or keys]

| et [key] show type of given config variable

| ev [key] list config vars in verbose format

| evj [key] list config vars in verbose format in JSON

A simpler alternative to the e command is accessible from the visual mode. Type Ve to enter it, use arrows (up, down, left, right) to navigate the configuration, and q to exit it. The start screen for the visual configuration edit looks like this:

[EvalSpace]

Console access is wrapped in API that permits to show the output of any command as ANSI, W32 Console or HTML formats. This allows radare's core to run inside environments with limited displaying capabilities, like kernels or embedded devices. It is still possible to receive data from it in your favorite format.

To enable colors support by default, add a corresponding configuration option to the .radare2 configuration file:

$ echo 'e scr.color=1' >> ~/.radare2rc

Note that enabling colors is not a boolean option. Instead, it is a number because there are different color depth levels. This is:

   • 0: black and white

   • 1: 16 basic ANSI colors

   • 2: 256 scale colors

   • 3: 24bit true color

The reason for having such user-defined options is because there's no standard or portable way for the terminal programs to query the console to determine the best configuration, same goes for charset encodings, so r2 allows you to choose that by hand.

Usually, serial consoles may work with 0 or 1, while xterms may support up to 3. RCons will try to find the closest color scheme for your theme when you choose a different them with the eco command.

It is possible to configure the color of almost any element of disassembly output. For *NIX terminals, r2 accepts color specification in RGB format. To change the console color palette use ec command.

Type ec to get a list of all currently used colors. Type ecs to show a color palette to pick colors from:

You can create your own color theme, but radare2 have its own predefined ones. Use the eco command to list or select them.

After selecting one, you can compare between the color scheme of the shell and the current theme by pressing Ctrl-Shift and then right arrow key for the toggle.

In visual mode use the R key to randomize colors or choose the next theme in the list.

Use r2 -H to list all the environment variables that matter to know where it will be looking for files. Those paths depend on the way (and operating system) you have built r2 for.

R2_PREFIX=/usr

MAGICPATH=/usr/share/radare2/2.8.0-git/magic

PREFIX=/usr

INCDIR=/usr/include/libr

LIBDIR=/usr/lib64

LIBEXT=so

RCONFIGHOME=/home/user/.config/radare2

RDATAHOME=/home/user/.local/share/radare2

RCACHEHOME=/home/user/.cache/radare2

LIBR_PLUGINS=/usr/lib/radare2/2.8.0-git

USER_PLUGINS=/home/user/.local/share/radare2/plugins

USER_ZIGNS=/home/user/.local/share/radare2/zigns

Most command names in radare are derived from action names. They should be easy to remember, as they are short. Actually, all commands are single letters. Subcommands or related commands are specified using the second character of the command name. For example, / foo is a command to search plain string, while /x 90 90 is used to look for hexadecimal pairs.

The general format for a valid command (as explained in the Command Format chapter) looks like this:

[.][times][cmd][~grep][@[@iter]addr!size][|>pipe] ; ...

For example,

> 3s +1024 ; seeks three times 1024 from the current seek

If a command starts with =!, the rest of the string is passed to the currently loaded IO plugin (a debugger, for example). Most plugins provide help messages with =!? or =!help.

$ r2 -d /bin/ls

> =!help ; handled by the IO plugin

If a command starts with !, posix_system() is called to pass the command to your shell. Check !? for more options and usage examples.

> !ls ; run `ls` in the shell

The meaning of the arguments (iter, addr, size) depends on the specific command. As a rule of thumb, most commands take a number as an argument to specify the number of bytes to work with, instead of the currently defined block size. Some commands accept math expressions or strings.

> px 0x17 ; show 0x17 bytes in hexs at current seek

> s base+0x33 ; seeks to flag 'base' plus 0x33

> / lib ; search for 'lib' string.

The @ sign is used to specify a temporary offset location or a seek position at which the command is executed, instead of current seek position. This is quite useful as you don't have to seek around all the time.

> p8 10 @ 0x4010 ; show 10 bytes at offset 0x4010

> f patata @ 0x10 ; set 'patata' flag at offset 0x10

Using @@ you can execute a single command on a list of flags matching the glob. You can think of this as a foreach operation:

> s 0

> / lib ; search 'lib' string

> p8 20 @@ hit0_* ; show 20 hexpairs at each search hit

The > operation is used to redirect the output of a command into a file (overwriting it if it already exists).

> pr > dump.bin ; dump 'raw' bytes of current block to file named 'dump.bin'

> f > flags.txt ; dump flag list to 'flags.txt'

The | operation (pipe) is similar to what you are used to expect from it in a *NIX shell: an output of one command as input to another.

[0x4A13B8C0]> f | grep section | grep text

0x0805f3b0 512 section._text

0x080d24b0 512 section._text_end

You can pass several commands in a single line by separating them with a semicolon ;:

> px ; dr

Using _, you can print the result that was obtained by the last command.

[0x00001060]> axt 0x00002004

main 0x1181 [DATA] lea rdi, str.argv__2d_:__s

[0x00001060]> _

main 0x1181 [DATA] lea rdi, str.argv__2d_:__s

To move around the file we are inspecting we will need to change the offset at which we are using the s command.

The argument is a math expression that can contain flag names, parenthesis, addition, substraction, multiplication of immediates of contents of memory using brackets.

Some example commands:

[0x00000000]> s 0x10

[0x00000010]> s+4

[0x00000014]> s-

[0x00000010]> s+

[0x00000014]>

Observe how the prompt offset changes. The first line moves the current offset to the address 0x10.

The second does a relative seek 4 bytes forward.

And finally, the last 2 commands are undoing, and redoing the last seek operations.

Instead of using just numbers, we can use complex expressions, or basic arithmetic operations to represent the address to seek.

To do this, check the ?$? Help message which describes the internal variables that can be used in the expressions. For example, this is the same as doing s+4 .

[0x00000000]> s $$+4

From the debugger (or when emulating) we can also use the register names as references. They are loaded as flags with the .dr* command, which happens under the hood.

[0x00000000]> s rsp+0x40

Here's the full help of the s command. We will explain in more detail below.

[0x00000000]> s?

Usage: s # Help for the seek commands. See ?$? to see all variables

| s Print current address

| s.hexoff Seek honoring a base from core->offset

| s:pad Print current address with N padded zeros (defaults to 8)

| s addr Seek to address

| s- Undo seek

| s-* Reset undo seek history

| s- n Seek n bytes backward

| s--[n] Seek blocksize bytes backward (/=n)

| s+ Redo seek

| s+ n Seek n bytes forward

| s++[n] Seek blocksize bytes forward (/=n)

| s[j*=!] List undo seek history (JSON, =list, *r2, !=names, s==)

| s/ DATA Search for next occurrence of 'DATA'

| s/x 9091 Search for next occurrence of \x90\x91

| sa [[+-]a] [asz] Seek asz (or bsize) aligned to addr

| sb Seek aligned to bb start

| sC[?] string Seek to comment matching given string

| sf Seek to next function (f->addr+f->size)

| sf function Seek to address of specified function

| sf. Seek to the beginning of current function

| sg/sG Seek begin (sg) or end (sG) of section or file

| sl[?] [+-]line Seek to line

| sn/sp ([nkey]) Seek to next/prev location, as specified by scr.nkey

| so [N] Seek to N next opcode(s)

| sr pc Seek to register

| ss Seek silently (without adding an entry to the seek history)

As a test file, let's use a simple hello_world.c compiled in Linux ELF format. After we compile it let's open it with radare2:

$ r2 hello_world

Now we have the command prompt:

[0x00400410]>

And it is time to go deeper.

All seeking commands that take an address as a command parameter can use any numeral base such as hex, octal, binary or decimal.

Seek to an address 0x0. An alternative command is simply 0x0

[0x00400410]> s 0x0

[0x00000000]>

Print current address:

[0x00000000]> s

0x0

[0x00000000]>

There is an alternate way to print current position: ?v $$.

Seek N positions forward, space is optional:

[0x00000000]> s+ 128

[0x00000080]>

Undo last two seeks to return to the initial address:

[0x00000080]> s-

[0x00000000]> s-

[0x00400410]>

We are back at 0x00400410.

There's also a command to show the seek history:

[0x00400410]> s*

f undo_3 @ 0x400410

f undo_2 @ 0x40041a

f undo_1 @ 0x400410

f undo_0 @ 0x400411

# Current undo/redo position.

f redo_0 @ 0x4005b4

The block size determines how many bytes radare2 commands will process when not given an explicit size argument. You can temporarily change the block size by specifying a numeric argument to the print commands. For example px 20.

[0x00000000]> b?

Usage: b[f] [arg] # Get/Set block size

| b 33 set block size to 33

| b eip+4 numeric argument can be an expression

| b display current block size

| b+3 increase blocksize by 3

| b-16 decrease blocksize by 16

| b* display current block size in r2 command

| bf foo set block size to flag size

| bj display block size information in JSON

| bm 1M set max block size

The b command is used to change the block size:

[0x00000000]> b 0x100 # block size = 0x100

[0x00000000]> b+16 # ... = 0x110

[0x00000000]> b-32 # ... = 0xf0

The bf command is used to change the block size to value specified by a flag. For example, in symbols, the block size of the flag represents the size of the function. To make that work, you have to either run function analysis af (which is included in aa) or manually seek and define some functions e.g. via Vd.

[0x00000000]> bf sym.main # block size = sizeof(sym.main)

[0x00000000]> pD @ sym.main # disassemble sym.main

You can combine two operations in a single pdf command. Except that pdf neither uses nor affects global block size.

[0x00000000]> pdf @ sym.main # disassemble sym.main

Another way around is to use special variables $FB and $FS which denote Function's Beginning and Size at the current seek. Read more about Usable variables.

[0x00000000]> s sym.main + 0x04

[0x00001ec9]> pD @ $FB !$FS # disassemble current function

╭ 211: int main (int argc, char **argv, char **envp);

│ 0x00001ec5 55 push rbp

│ 0x00001ec6 4889e5 mov rbp, rsp

│ 0x00001ec9 4881ecc0000000 sub rsp, 0xc0

...

╰ 0x00001f97 c3 ret

Note: don't put space after ! size designator. See also Command Format.

The concept of sections is tied to the information extracted from the binary. We can display this information by using the i command.

Displaying information about sections:

[0x00005310]> iS

[Sections]

00 0x00000000 0 0x00000000 0 ----

01 0x00000238 28 0x00000238 28 -r-- .interp

02 0x00000254 32 0x00000254 32 -r-- .note.ABI_tag

03 0x00000278 176 0x00000278 176 -r-- .gnu.hash

04 0x00000328 3000 0x00000328 3000 -r-- .dynsym

05 0x00000ee0 1412 0x00000ee0 1412 -r-- .dynstr

06 0x00001464 250 0x00001464 250 -r-- .gnu.version

07 0x00001560 112 0x00001560 112 -r-- .gnu.version_r

08 0x000015d0 4944 0x000015d0 4944 -r-- .rela.dyn

09 0x00002920 2448 0x00002920 2448 -r-- .rela.plt

10 0x000032b0 23 0x000032b0 23 -r-x .init

...

As you may know, binaries have sections and maps. The sections define the contents of a portion of the file that can be mapped in memory (or not). What is mapped is defined by the segments.

Before the IO refactoring done by condret, the S command was used to manage what we now call maps. Currently the S command is deprecated because iS and om should be enough.

Firmware images, bootloaders and binary files usually place various sections of a binary at different addresses in memory. To represent this behavior, radare offers the iS. Use iS? to get the help message. To list all created sections use iS (or iSj to get the json format). The iS= will show the region bars in ascii-art.

You can create a new mapping using the om subcommand as follows:

om fd vaddr [size] [paddr] [rwx] [name]

For Example:

[0x0040100]> om 4 0x00000100 0x00400000 0x0001ae08 rwx test

You can also use om command to view information about mapped sections:

[0x00401000]> om

6 fd: 4 +0x0001ae08 0x00000100 - 0x004000ff rwx test

5 fd: 3 +0x00000000 0x00000000 - 0x0000055f r-- fmap.LOAD0

4 fd: 3 +0x00001000 0x00001000 - 0x000011e4 r-x fmap.LOAD1

3 fd: 3 +0x00002000 0x00002000 - 0x0000211f r-- fmap.LOAD2

2 fd: 3 +0x00002de8 0x00003de8 - 0x0000402f r-- fmap.LOAD3

1 fd: 4 +0x00000000 0x00004030 - 0x00004037 rw- mmap.LOAD3

Use om? to get all the possible subcommands. To list all the defined maps use om (or omj to get the json format or om* to get the r2 commands format). To get the ascii art view use om=.

It is also possible to delete the mapped section using the om-mapid command.

For Example:

[0x00401000]> om-6

Radare's I/O subsystem allows you to map the contents of files into the same I/O space used to contain a loaded binary. New contents can be placed at random offsets.

The o command permits the user to open a file, this is mapped at offset 0 unless it has a known binary header and then the maps are created in virtual addresses.

Sometimes, we want to rebase a binary, or maybe we want to load or map the file in a different address.

When launching r2, the base address can be changed with the -B flag. But you must notice the difference when opening files with unknown headers, like bootloaders, so we need to map them using the -m flag (or specifying it as argument to the o command).

radare2 is able to open files and map portions of them at random places in memory specifying attributes like permissions and name. It is the perfect basic tooling to reproduce an environment like a core file, a debug session, by also loading and mapping all the libraries the binary depends on.

Opening files (and mapping them) is done using the o (open) command. Let's read the help:

[0x00000000]> o?

|Usage: o [com- ] [file] ([offset])

| o list opened files

| o-1 close file descriptor 1

| o-!* close all opened files

| o-- close all files, analysis, binfiles, flags, same as !r2 --

| o [file] open [file] file in read-only

| o+ [file] open file in read-write mode

| o [file] 0x4000 rwx map file at 0x4000

| oa[-] [A] [B] [filename] Specify arch and bits for given file

| oq list all open files

| o* list opened files in r2 commands

| o. [len] open a malloc://[len] copying the bytes from current offset

| o= list opened files (ascii-art bars)

| ob[?] [lbdos] [...] list opened binary files backed by fd

| oc [file] open core file, like relaunching r2

| of [file] open file and map it at addr 0 as read-only

| oi[-|idx] alias for o, but using index instead of fd

| oj[?] list opened files in JSON format

| oL list all IO plugins registered

| om[?] create, list, remove IO maps

| on [file] 0x4000 map raw file at 0x4000 (no r_bin involved)

| oo[?] reopen current file (kill+fork in debugger)

| oo+ reopen current file in read-write

| ood[r] [args] reopen in debugger mode (with args)

| oo[bnm] [...] see oo? for help

| op [fd] prioritize given fd (see also ob)

| ox fd fdx exchange the descs of fd and fdx and keep the mapping

Prepare a simple layout:

$ rabin2 -l /bin/ls

[Linked libraries]

libselinux.so.1

librt.so.1

libacl.so.1

libc.so.6

One of the key features of radare2 is displaying information in many formats. The goal is to offer a selection of display choices to interpret binary data in the best possible way.

Binary data can be represented as integers, shorts, longs, floats, timestamps, hexpair strings, or more complex formats like C structures, disassembly listings, decompilation listing, be a result of an external processing...

Below is a list of available print modes listed by p?:

[0x00005310]> p?

|Usage: p[=68abcdDfiImrstuxz] [arg|len] [@addr]

| p[b|B|xb] [len] ([S]) bindump N bits skipping S bytes

| p[iI][df] [len] print N ops/bytes (f=func) (see pi? and pdi)

| p[kK] [len] print key in randomart (K is for mosaic)

| p-[?][jh] [mode] bar|json|histogram blocks (mode: e?search.in)

| p2 [len] 8x8 2bpp-tiles

| p3 [file] print stereogram (3D)

| p6[de] [len] base64 decode/encode

| p8[?][j] [len] 8bit hexpair list of bytes

| p=[?][bep] [N] [L] [b] show entropy/printable chars/chars bars

| pa[edD] [arg] pa:assemble pa[dD]:disasm or pae: esil from hex

| pA[n_ops] show n_ops address and type

| pb[?] [n] bitstream of N bits

| pB[?] [n] bitstream of N bytes

| pc[?][p] [len] output C (or python) format

| pC[aAcdDxw] [rows] print disassembly in columns (see hex.cols and pdi)

| pd[?] [sz] [a] [b] disassemble N opcodes (pd) or N bytes (pD)

| pf[?][.nam] [fmt] print formatted data (pf.name, pf.name $<expr>)

| pF[?][apx] print asn1, pkcs7 or x509

| pg[?][x y w h] [cmd] create new visual gadget or print it (see pg? for details)

| ph[?][=|hash] ([len]) calculate hash for a block

| pj[?] [len] print as indented JSON

| pm[?] [magic] print libmagic data (see pm? and /m?)

| po[?] hex print operation applied to block (see po?)

| pp[?][sz] [len] print patterns, see pp? for more help

| pq[?][is] [len] print QR code with the first Nbytes

| pr[?][glx] [len] print N raw bytes (in lines or hexblocks, 'g'unzip)

| ps[?][pwz] [len] print pascal/wide/zero-terminated strings

| pt[?][dn] [len] print different timestamps

| pu[?][w] [len] print N url encoded bytes (w=wide)

| pv[?][jh] [mode] show variable/pointer/value in memory

| pwd display current working directory

| px[?][owq] [len] hexdump of N bytes (o=octal, w=32bit, q=64bit)

| pz[?] [len] print zoom view (see pz? for help)

[0x00005310]>

Tip: when using json output, you can append the ~{} to the command to get a pretty-printed version of the output:

[0x00000000]> oj

[{"raised":false,"fd":563280,"uri":"malloc://512","from":0,"writable":true,"size":512,"overlaps":false}]

[0x00000000]> oj~{}

[

{

"raised": false,

"fd": 563280,

"uri": "malloc://512",

"from": 0,

"writable": true,

"size": 512,

"overlaps": false

}

]

For more on the magical powers of ~ see the help in ?@?, and the Command Format chapter earlier in the book.

The zoom is a print mode that allows you to get a global view of the whole file or a memory map on a single screen. In this mode, each byte represents file_size/block_size bytes of the file. Use the pz command, or just use Z in the visual mode to toggle the zoom mode.

The cursor can be used to scroll faster through the zoom out view. Pressing z again will zoom-in at the cursor position.

[0x004048c5]> pz?

|Usage: pz [len] print zoomed blocks (filesize/N)

| e zoom.maxsz max size of block

| e zoom.from start address

| e zoom.to end address

| e zoom.byte specify how to calculate each byte

| pzp number of printable chars

| pzf count of flags in block

| pzs strings in range

| pz0 number of bytes with value '0'

| pzF number of bytes with value 0xFF

| pze calculate entropy and expand to 0-255 range

| pzh head (first byte value); This is the default mode

Let's see some examples:

[0x08049790]> e zoom.byte=h

[0x08049790]> pz // or default pzh

0x00000000 7f00 0000 e200 0000 146e 6f74 0300 0000

0x00000010 0000 0000 0068 2102 00ff 2024 e8f0 007a

0x00000020 8c00 18c2 ffff 0080 4421 41c4 1500 5dff

0x00000030 ff10 0018 0fc8 031a 000c 8484 e970 8648

0x00000040 d68b 3148 348b 03a0 8b0f c200 5d25 7074

0x00000050 7500 00e1 ffe8 58fe 4dc4 00e0 dbc8 b885

[0x08049790]> e zoom.byte=p

[0x08049790]> pz // or pzp

0x00000000 2f47 0609 070a 0917 1e9e a4bd 2a1b 2c27

0x00000010 322d 5671 8788 8182 5679 7568 82a2 7d89

0x00000020 8173 7f7b 727a 9588 a07b 5c7d 8daf 836d

0x00000030 b167 6192 a67d 8aa2 6246 856e 8c9b 999f

0x00000040 a774 96c3 b1a4 6c8e a07c 6a8f 8983 6a62

0x00000050 7d66 625f 7ea4 7ea6 b4b6 8b57 a19f 71a2

[0x08049790]> eval zoom.byte = flags

[0x08049790]> pz // or pzf

0x00406e65 48d0 80f9 360f 8745 ffff ffeb ae66 0f1f

0x00406e75 4400 0083 f801 0f85 3fff ffff 410f b600

0x00406e85 3c78 0f87 6301 0000 0fb6 c8ff 24cd 0026

0x00406e95 4100 660f 1f84 0000 0000 0084 c074 043c

0x00406ea5 3a75 18b8 0500 0000 83f8 060f 95c0 e9cd

0x00406eb5 feff ff0f 1f84 0000 0000 0041 8801 4983

0x00406ec5 c001 4983 c201 4983 c101 e9ec feff ff0f

[0x08049790]> e zoom.byte=F

[0x08049790]> pO // or pzF

0x00000000 0000 0000 0000 0000 0000 0000 0000 0000

0x00000010 0000 2b5c 5757 3a14 331f 1b23 0315 1d18

0x00000020 222a 2330 2b31 2e2a 1714 200d 1512 383d

0x00000030 1e1a 181b 0a10 1a21 2a36 281e 1d1c 0e11

0x00000040 1b2a 2f22 2229 181e 231e 181c 1913 262b

0x00000050 2b30 4741 422f 382a 1e22 0f17 0f10 3913

You can limit zooming to a range of bytes instead of the whole bytespace. Change zoom.from and zoom.to eval variables:

[0x00003a04]> e? zoom.

zoom.byte: Zoom callback to calculate each byte (See pz? for help)

zoom.from: Zoom start address

zoom.in: Specify boundaries for zoom

zoom.maxsz: Zoom max size of block

zoom.to: Zoom end address

[0x00003a04]> e zoom.

zoom.byte = h

zoom.from = 0

zoom.in = io.map

zoom.maxsz = 512

zoom.to = 0

Radare2 has an internal clipboard to save and write portions of memory loaded from the current io layer.

This clipboard can be manipulated with the y command.

The two basic operations are

   • copy (yank)

   • paste

The yank operation will read N bytes (specified by the argument) into the clipboard. We can later use the yy command to paste what we read before into a file.

You can yank/paste bytes in visual mode selecting them with the cursor mode (Vc) and then using the y and Y key bindings which are aliases for y and yy commands of the command-line interface.

[0x00000000]> y?

Usage: y[ptxy] [len] [[@]addr] # See wd? for memcpy, same as 'yf'.

| y! open cfg.editor to edit the clipboard

| y 16 0x200 copy 16 bytes into clipboard from 0x200

| y 16 @ 0x200 copy 16 bytes into clipboard from 0x200

| y 16 copy 16 bytes into clipboard

| y show yank buffer information (srcoff len bytes)

| y* print in r2 commands what's been yanked

| yf 64 0x200 copy file 64 bytes from 0x200 from file

| yfa file copy copy all bytes from file (opens w/ io)

| yfx 10203040 yank from hexpairs (same as ywx)

| yj print in JSON commands what's been yanked

| yp print contents of clipboard

| yq print contents of clipboard in hexpairs

| ys print contents of clipboard as string

| yt 64 0x200 copy 64 bytes from current seek to 0x200

| ytf file dump the clipboard to given file

| yw hello world yank from string

| ywx 10203040 yank from hexpairs (same as yfx)

| yx print contents of clipboard in hexadecimal

| yy 0x3344 paste clipboard

| yz [len] copy nul-terminated string (up to blocksize) into clipboard

Sample session:

[0x00000000]> s 0x100 ; seek at 0x100

[0x00000100]> y 100 ; yanks 100 bytes from here

[0x00000200]> s 0x200 ; seek 0x200

[0x00000200]> yy ; pastes 100 bytes

You can perform a yank and paste in a single line by just using the yt command (yank-to). The syntax is as follows:

[0x4A13B8C0]> x

offset 0 1 2 3 4 5 6 7 8 9 A B 0123456789AB

0x4A13B8C0, 89e0 e839 0700 0089 c7e8 e2ff ...9........

0x4A13B8CC, ffff 81c3 eea6 0100 8b83 08ff ............

0x4A13B8D8, ffff 5a8d 2484 29c2 ..Z.$.).

For most generic reverse engineering tasks like finding the differences between two binary files, which bytes has changed, find differences in the graphs of the code analysis results, and other diffing operations you can just use radiff2:

$ radiff2 -h

Inside r2, the functionalities exposed by radiff2 are available with the c command.

c (short for "compare") allows you to compare arrays of bytes from different sources. The command accepts input in a number of formats and then compares it against values found at current seek position.

[0x00404888]> c?

Usage: c[?dfx] [argument] # Compare

| c [string] Compare a plain with escaped chars string

| c* [string] Same as above, but printing r2 commands instead

| c1 [addr] Compare 8 bits from current offset

| c2 [value] Compare a word from a math expression

| c4 [value] Compare a doubleword from a math expression

| c8 [value] Compare a quadword from a math expression

| cat [file] Show contents of file (see pwd, ls)

| cc [at] Compares in two hexdump columns of block size

| ccc [at] Same as above, but only showing different lines

| ccd [at] Compares in two disasm columns of block size

| ccdd [at] Compares decompiler output (e cmd.pdc=pdg|pdd)

| cf [file] Compare contents of file at current seek

| cg[?] [o] [file] Graphdiff current file and [file]

| cu[?] [addr] @at Compare memory hexdumps of $$ and dst in unified diff

| cud [addr] @at Unified diff disasm from $$ and given address

| cv[1248] [hexpairs] @at Compare 1,2,4,8-byte (silent return in $?)

| cV[1248] [addr] @at Compare 1,2,4,8-byte address contents (silent, return in $?)

| cw[?] [us?] [...] Compare memory watchers

| cx [hexpair] Compare hexpair string (use '.' as nibble wildcard)

| cx* [hexpair] Compare hexpair string (output r2 commands)

| cX [addr] Like 'cc' but using hexdiff output

| cd [dir] chdir

| cl|cls|clear Clear screen, (clear0 to goto 0, 0 only)

To compare memory contents at current seek position against a given string of values, use cx:

[0x08048000]> p8 4

7f 45 4c 46

SDB stands for String DataBase. It's a simple key-value database that only operates with strings created by pancake. It is used in many parts of r2 to have a disk and in-memory database which is small and fast to manage using it as a hashtable on steroids.

SDB is a simple string key/value database based on djb’s cdb disk storage and supports JSON and arrays introspection.

There’s also the sdbtypes: a vala library that implements several data structures on top of an sdb or a memcache instance.

SDB supports:

   • namespaces (multiple sdb paths)

   • atomic database sync (never corrupted)

   • bindings for vala, luvit, newlisp and nodejs

   • commandline frontend for sdb databases

   • memcache client and server with sdb backend

   • arrays support (syntax sugar)

   • json parser/getter

Let's create a database!

$ sdb d hello=world

$ sdb d hello

world

Using arrays:

$ sdb - '[]list=1,2' '[0]list' '[0]list=foo' '[]list' '[+1]list=bar'

1

foo

2

foo

bar

2

Let's play with json:

$ sdb d g='{"foo":1,"bar":{"cow":3}}'

$ sdb d g?bar.cow

3

$ sdb - user='{"id":123}' user?id=99 user?id

99

Using the command line without any disk database:

$ sdb - foo=bar foo a=3 +a -a

bar

4

3

So, you can now do this inside your radare2 sessions!

Let's take a simple binary, and check what is already sdbized.

$ cat test.c

int main(){

puts("Hello world\n");

}

$ gcc test.c -o test

$ r2 -A ./test

[0x08048320]> k **

bin

anal

syscall

debug

[0x08048320]> k bin/**

fd.6

[0x08048320]> k bin/fd.6/*

archs=0:0:x86:32

The file corresponding to the sixth file descriptor is a x86_32 binary.

[0x08048320]> k anal/meta/*

meta.s.0x80484d0=12,SGVsbG8gd29ybGQ=

[...]

[0x08048320]> ?b64- SGVsbG8gd29ybGQ=

Hello world

Strings are stored encoded in base64.

List namespaces

k **

List sub-namespaces

k anal/**

List keys

k *

k anal/*

Set a key

k foo=bar

Get the value of a key

k foo

List all syscalls

k syscall/*~^0x

List all comments

k anal/meta/*~.C.

Show a comment at given offset:

k %anal/meta/[1]meta.C.0x100005000

By default dietline mode is compatible with readline Emacs-like mode key bindings. Thus active are:

   • Ctrl-a - move to the beginning of the line

   • Ctrl-e - move to the end of the line

   • Ctrl-b - move one character backward

   • Ctrl-f - move one character forward

   • Ctrl-w - delete the previous word

   • Ctrl-u - delete the whole line

   • Ctrl-h - delete a character to the left

   • Ctrl-d - delete a character to the right

   • Alt-d - cuts the character after the cursor

   • Ctrl-k - kill the text from point to the end of the line.

   • Ctrl-x - kill backward from the cursor to the beginning of the current line.

   • Ctrl-t - kill from point to the end of the current word, or if between words, to the end of the next word. Word boundaries are the same as forward-word.

   • Ctrl-w - kill the word behind point, using white space as a word boundary. The killed text is saved on the kill-ring.

   • Ctrl-y - yank the top of the kill ring into the buffer at point.

   • Ctrl-] - rotate the kill-ring, and yank the new top. You can only do this if the prior command is yank or yank-pop.

   • Ctrl-r - the reverse search in the command history

Radare2 also comes with in vi mode that can be enabled by toggling scr.prompt.vi. The various keybindings available in this mode are:

   • ESC - enter into the control mode

   • i - enter into the insert mode

   • j - acts like up arrow key

   • k - acts like down arrow key

   • a - move cursor forward and enter into insert mode

   • I - move to the beginning of the line and enter into insert mode

   • A - move to the end of the line and enter into insert mode

   • ^ - move to the beginning of the line

   • 0 - move to the beginning of the line

   • $ - move to the end of the line

   • h - move one character backward

   • l - move one character forward

   • x - cuts the character

   • dw - delete the current word

   • diw - deletes the current word.

   • db - delete the previous word

   • D - delete the whole line

   • dh - delete a character to the left

   • dl - delete a character to the right

   • d$ - kill the text from point to the end of the line.

   • d^ - kill backward from the cursor to the beginning of the current line.

   • de - kill from point to the end of the current word, or if between words, to the end of the next word. Word boundaries are the same as forward-word.

   • p - yank the top of the kill ring into the buffer at point.

   • c - acts similar to d based commands, but goes into insert mode in the end by prefixing the commands with numbers, the command is performed multiple times.

If you are finding it hard to keep track of which mode you are in, just set scr.prompt.mode=true to update the color of the prompt based on the vi-mode.

The visual mode is a more user-friendly interface alternative to radare2's command-line prompt. It allows easy navigation, has a cursor mode for selecting bytes, and offers numerous key bindings to simplify debugger use. To enter visual mode, use V command. To exit from it back to command line, press q.

Navigation can be done using HJKL or arrow keys and PgUp/PgDown keys. It also understands usual Home/End keys. Like in Vim the movements can be repeated by preceding the navigation key with the number, for example 5j will move down for 5 lines, or 2l will move 2 characters right.

The Visual mode uses "print modes" which are basically different panel that you can rotate. By default those are:

↻ Hexdump panel -> Disassembly panel → Debugger panel → Hexadecimal words dump panel → Hex-less hexdump panel → Op analysis color map panel → Annotated hexdump panel ↺.

Notice that the top of the panel contains the command which is used, for example for the disassembly panel:

[0x00404890 16% 120 /bin/ls]> pd $r @ entry0

To see help on all key bindings defined for visual mode, press ?:

Visual mode help:

? show this help

?? show the user-friendly hud

% in cursor mode finds matching pair, or toggle autoblocksz

@ redraw screen every 1s (multi-user view)

^ seek to the begining of the function

! enter into the visual panels mode

_ enter the flag/comment/functions/.. hud (same as VF_)

= set cmd.vprompt (top row)

| set cmd.cprompt (right column)

. seek to program counter

\ toggle visual split mode

" toggle the column mode (uses pC..)

/ in cursor mode search in current block

:cmd run radare command

;[-]cmt add/remove comment

0 seek to beginning of current function

[1-9] follow jmp/call identified by shortcut (like ;[1])

,file add a link to the text file

/*+-[] change block size, [] = resize hex.cols

</> seek aligned to block size (seek cursor in cursor mode)

a/A (a)ssemble code, visual (A)ssembler

b browse symbols, flags, configurations, classes, ...

B toggle breakpoint

c/C toggle (c)ursor and (C)olors

d[f?] define function, data, code, ..

D enter visual diff mode (set diff.from/to

e edit eval configuration variables

f/F set/unset or browse flags. f- to unset, F to browse, ..

gG go seek to begin and end of file (0-$s)

hjkl move around (or HJKL) (left-down-up-right)

i insert hex or string (in hexdump) use tab to toggle

mK/'K mark/go to Key (any key)

M walk the mounted filesystems

n/N seek next/prev function/flag/hit (scr.nkey)

g go/seek to given offset

O toggle asm.pseudo and asm.esil

p/P rotate print modes (hex, disasm, debug, words, buf)

q back to radare shell

r refresh screen / in cursor mode browse comments

R randomize color palette (ecr)

sS step / step over

t browse types

T enter textlog chat console (TT)

uU undo/redo seek

v visual function/vars code analysis menu

V (V)iew graph using cmd.graph (agv?)

wW seek cursor to next/prev word

xX show xrefs/refs of current function from/to data/code

yY copy and paste selection

z fold/unfold comments in disassembly

Z toggle zoom mode

Enter follow address of jump/call

Function Keys: (See 'e key.'), defaults to:

F2 toggle breakpoint

F4 run to cursor

F7 single step

F8 step over

F9 continue

Move within the Disassembly using arrow keys or hjkl. Use g to seek directly to a flag or an offset, type it when requested by the prompt: [offset]>. Follow a jump or a call using the number of your keyboard [0-9] and the number on the right in disassembly to follow a call or a jump. In this example typing 1 on the keyboard would follow the call to sym.imp.__libc_start_main and therefore, seek at the offset of this symbol.

0x00404894 e857dcffff call sym.imp.__libc_start_main ;[1]

Seek back to the previous location using u, U will allow you to redo the seek.

When radare2 has discovered a XREF during the analysis, it will show you the information in the Visual Disassembly using XREF tag:

; DATA XREF from 0x00402e0e (unk)

str.David_MacKenzie:

To see where this string is called, press x, if you want to jump to the location where the data is used then press the corresponding number [0-9] on your keyboard. (This functionality is similar to axt)

X corresponds to the reverse operation aka axf.

To enable this view use this config var e dbg.funcarg = true

To add a comment press ;.

Quickly type commands using :.

/: allows highlighting of strings in the current display. :cmd allows you to use one of the "/?" commands that perform more specialized searches.

The disassembly's look-and-feel is controlled using the "asm.* configuration keys, which can be changed using the e command. All configuration keys can also be edited through the Visual Configuration Editor.

This HUD can be accessed using the e key in visual mode. The editor allows you to easily examine and change radare2's configuration. For example, if you want to change something about the disassembly display, select asm from the list, navigate to the item you wish to modify it, then select it by hitting Enter. If the item is a boolean variable, it will toggle, otherwise you will be prompted to provide a new value.

Example switch to pseudo disassembly:

Following are some example of eval variable related to disassembly.

Visual Panels is characterized by the following core functionalities:

   1. Split Screen

   2. Display multiple screens such as Symbols, Registers, Stack, as well as custom panels

   3. Menu will cover all those commonly used commands for you so that you don't have to memorize any of them

CUI met some useful GUI as the menu, that is Visual Panels.

Panels can be accessed by using v or by using ! from the visual mode.

|Visual Ascii Art Panels:

| | split the current panel vertically

| - split the current panel horizontally

| : run r2 command in prompt

| ; add/remove comment

| _ start the hud input mode

| \ show the user-friendly hud

| ? show this help

| ! run r2048 game

| . seek to PC or entrypoint

| * show decompiler in the current panel

| " create a panel from the list and replace the current one

| / highlight the keyword

| ( toggle snow

| & toggle cache

| [1-9] follow jmp/call identified by shortcut (like ;[1])

| ' ' (space) toggle graph / panels

| tab go to the next panel

| Enter start Zoom mode

| a toggle auto update for decompiler

| b browse symbols, flags, configurations, classes, ...

| c toggle cursor

| C toggle color

| d define in the current address. Same as Vd

| D show disassembly in the current panel

| e change title and command of current panel

| f set/add filter keywords

| F remove all the filters

| g go/seek to given offset

| G go/seek to highlight

| i insert hex

| hjkl move around (left-down-up-right)

| HJKL move around (left-down-up-right) by page

| m select the menu panel

| M open new custom frame

| n/N seek next/prev function/flag/hit (scr.nkey)

| p/P rotate panel layout

| q quit, or close a tab

| Q close all the tabs and quit

| r toggle callhints/jmphints/leahints

| R randomize color palette (ecr)

| s/S step in / step over

| t/T tab prompt / close a tab

| u/U undo / redo seek

| w start Window mode

| V go to the graph mode

| xX show xrefs/refs of current function from/to data/code

| z swap current panel with the first one

Use tab to move around the panels until you get to the targeted panel. Then, use hjkl, just like in vim, to scroll the panel you are currently on. Use S and s to step over/in, and all the panels should be updated dynamically while you are debugging. Either in the Registers or Stack panels, you can edit the values by inserting hex. This will be explained later. While hitting tab can help you moving between panels, it is highly recommended to use m to open the menu. As usual, you can use hjkl to move around the menu and will find tons of useful stuff there. You can also press " to quickly browse through the different options View offers and change the contents of the selected panel.

| is for the vertical and - is for the horizontal split. You can delete any panel by pressing X.

Split panels can be resized from Window Mode, which is accessed with w.

|Panels Window mode help:

| ? show this help

| ?? show the user-friendly hud

| Enter start Zoom mode

| c toggle cursor

| hjkl move around (left-down-up-right)

| JK resize panels vertically

| HL resize panels horizontally

| q quit Window mode

Either in the Register or Stack panel, you can edit the values. Use c to activate cursor mode and you can move the cursor by pressing hjkl, as usual. Then, hit i, just like the insert mode of vim, to insert a value.

Visual Panels also offer tabs to quickly access multiple forms of information easily. Press t to enter Tab Mode. All the tabs numbers will be visible in the top right corner.

By default you will have one tab and you can press t to create a new tab with the same panels and T to create a new panel from scratch.

For traversing through the tabs, you can type in the tab number while in Tab Mode.

And pressing - deletes the tab you are in.

You can save your custom layout of your visual panels either by picking the option 'Save Layout' from the File menu of the menu bar or by running:

v= test

Where test is the name with which you'd like to save it.

You can open a saved layout by passing the name as the parameter to v:

v test

More about that can be found under v?.

The radare2 search engine is based on work done by esteve, plus multiple features implemented on top of it. It supports multiple keyword searches, binary masks, and hexadecimal values. It automatically creates flags for search hit locations ease future referencing.

Search is initiated by / command.

[0x00000000]> /?

|Usage: /[!bf] [arg]Search stuff (see 'e??search' for options)

|Use io.va for searching in non virtual addressing spaces

| / foo\x00 search for string 'foo\0'

| /j foo\x00 search for string 'foo\0' (json output)

| /! ff search for first occurrence not matching, command modifier

| /!x 00 inverse hexa search (find first byte != 0x00)

| /+ /bin/sh construct the string with chunks

| // repeat last search

| /a jmp eax assemble opcode and search its bytes

| /A jmp find analyzed instructions of this type (/A? for help)

| /b search backwards, command modifier, followed by other command

| /B search recognized RBin headers

| /c jmp [esp] search for asm code matching the given string

| /ce rsp,rbp search for esil expressions matching

| /C[ar] search for crypto materials

| /d 101112 search for a deltified sequence of bytes

| /e /E.F/i match regular expression

| /E esil-expr offset matching given esil expressions %%= here

| /f search forwards, command modifier, followed by other command

| /F file [off] [sz] search contents of file with offset and size

| /g[g] [from] find all graph paths A to B (/gg follow jumps, see search.count and

anal.depth)

| /h[t] [hash] [len] find block matching this hash. See ph

| /i foo search for string 'foo' ignoring case

| /m magicfile search for matching magic file (use blocksize)

| /M search for known filesystems and mount them automatically

| /o [n] show offset of n instructions backward

| /O [n] same as /o, but with a different fallback if anal cannot be used

| /p patternsize search for pattern of given size

| /P patternsize search similar blocks

| /r[erwx][?] sym.printf analyze opcode reference an offset (/re for esil)

| /R [grepopcode] search for matching ROP gadgets, semicolon-separated

| /s search for all syscalls in a region (EXPERIMENTAL)

| /v[1248] value look for an `cfg.bigendian` 32bit value

| /V[1248] min max look for an `cfg.bigendian` 32bit value in range

| /w foo search for wide string 'f\0o\0o\0'

| /wi foo search for wide string ignoring case 'f\0o\0o\0'

| /x ff..33 search for hex string ignoring some nibbles

| /x ff0033 search for hex string

| /x ff43:ffd0 search for hexpair with mask

| /z min max search for strings of given size

Because everything is treated as a file in radare2, it does not matter whether you search in a socket, a remote device, in process memory, or a file.

note that '/' starts multiline comment. It's not for searching. type '/' to end comment.

A basic search for a plain text string in a file would be something like:

$ r2 -q -c "/ lib" /bin/ls

Searching 3 bytes from 0x00400000 to 0x0041ae08: 6c 69 62

hits: 9

0x00400239 hit0_0 "lib64/ld-linux-x86-64.so.2"

0x00400f19 hit0_1 "libselinux.so.1"

0x00400fae hit0_2 "librt.so.1"

0x00400fc7 hit0_3 "libacl.so.1"

0x00401004 hit0_4 "libc.so.6"

0x004013ce hit0_5 "libc_start_main"

0x00416542 hit0_6 "libs/"

0x00417160 hit0_7 "lib/xstrtol.c"

0x00417578 hit0_8 "lib"

As can be seen from the output above, radare2 generates a "hit" flag for every entry found. You can then use the ps command to see the strings stored at the offsets marked by the flags in this group, and they will have names of the form hit0_<index>:

[0x00404888]> / ls

...

[0x00404888]> ps @ hit0_0

lseek

You can search for wide-char strings (e.g., unicode letters) using the /w command:

[0x00000000]> /w Hello

0 results found.

To perform a case-insensitive search for strings use /i:

[0x0040488f]> /i Stallman

Searching 8 bytes from 0x00400238 to 0x0040488f: 53 74 61 6c 6c 6d 61 6e

[# ]hits: 004138 < 0x0040488f hits = 0

It is possible to specify hexadecimal escape sequences in the search string by prepending them with "\x":

[0x00000000]> / \x7FELF

if, instead, you are searching for a string of hexadecimal values, you're probably better of using the /x command:

[0x00000000]> /x 7F454C46

Once the search is done, the results are stored in the searches flag space.

[0x00000000]> fs

0 0 . strings

1 0 . symbols

2 6 . searches

The radare2 search engine can be configured through several configuration variables, modifiable with the e command.

e cmd.hit = x ; radare2 command to execute on every search hit

e search.distance = 0 ; search string distance

e search.in = [foo] ; pecify search boundarie. Supported values are listed under e search.in=??

e search.align = 4 ; only show search results aligned by specified boundary.

e search.from = 0 ; start address

e search.to = 0 ; end address

e search.asmstr = 0 ; search for string instead of assembly

e search.flags = true ; if enabled, create flags on hits

The search.align variable is used to limit valid search hits to certain alignment. For example, with e search.align=4 you will see only hits found at 4-bytes aligned offsets.

The search.flags boolean variable instructs the search engine to flag hits so that they can be referenced later. If a currently running search is interrupted with Ctrl-C keyboard sequence, current search position is flagged with search_stop.

The /p command allows you to apply repeated pattern searches on IO backend storage. It is possible to identify repeated byte sequences without explicitly specifying them. The only command's parameter sets minimum detectable pattern length. Here is an example:

[0x00000000]> /p 10

This command output will show different patterns found and how many times each of them is encountered.

The cmd.hit configuration variable is used to define a radare2 command to be executed when a matching entry is found by the search engine. If you want to run several commands, separate them with ;. Alternatively, you can arrange them in a separate script, and then invoke it as a whole with . script-file-name command. For example:

[0x00404888]> e cmd.hit = p8 8

[0x00404888]> / lib

Searching 3 bytes from 0x00400000 to 0x0041ae08: 6c 69 62

hits: 9

0x00400239 hit4_0 "lib64/ld-linux-x86-64.so.2"

31ed4989d15e4889

0x00400f19 hit4_1 "libselinux.so.1"

31ed4989d15e4889

0x00400fae hit4_2 "librt.so.1"

31ed4989d15e4889

0x00400fc7 hit4_3 "libacl.so.1"

31ed4989d15e4889

0x00401004 hit4_4 "libc.so.6"

31ed4989d15e4889

0x004013ce hit4_5 "libc_start_main"

31ed4989d15e4889

0x00416542 hit4_6 "libs/"

31ed4989d15e4889

0x00417160 hit4_7 "lib/xstrtol.c"

31ed4989d15e4889

0x00417578 hit4_8 "lib"

31ed4989d15e4889

Sometimes you want to find a keyword backwards. This is, before the current offset, to do this you can seek back and search forward by adding some search.from/to restrictions, or use the /b command.

[0x100001200]> / nop

0x100004b15 hit0_0 .STUWabcdefghiklmnopqrstuvwxbin/ls.

0x100004f50 hit0_1 .STUWabcdefghiklmnopqrstuwx1] [file .

[0x100001200]> /b nop

[0x100001200]> s 0x100004f50p

[0x100004f50]> /b nop

0x100004b15 hit2_0 .STUWabcdefghiklmnopqrstuvwxbin/ls.

[0x100004f50]>

Note that /b is doing the same as /, but backward, so what if we want to use /x backward? We can use /bx, and the same goes for other search subcommands:

[0x100001200]> /x 90

0x100001a23 hit1_0 90

0x10000248f hit1_1 90

0x1000027b2 hit1_2 90

0x100002b2e hit1_3 90

0x1000032b8 hit1_4 90

0x100003454 hit1_5 90

0x100003468 hit1_6 90

0x10000355b hit1_7 90

0x100003647 hit1_8 90

0x1000037ac hit1_9 90

0x10000389c hit1_10 90

0x100003c5c hit1_11 90

If you want to search for a certain assembler opcodes, you can use /a commands.

The command /ad/ jmp [esp] searches for the specified category of assembly mnemonic:

[0x00404888]> /ad/ jmp qword [rdx]

f hit_0 @ 0x0040e50d # 2: jmp qword [rdx]

f hit_1 @ 0x00418dbb # 2: jmp qword [rdx]

f hit_2 @ 0x00418fcb # 3: jmp qword [rdx]

f hit_3 @ 0x004196ab # 6: jmp qword [rdx]

f hit_4 @ 0x00419bf3 # 3: jmp qword [rdx]

f hit_5 @ 0x00419c1b # 3: jmp qword [rdx]

f hit_6 @ 0x00419c43 # 3: jmp qword [rdx]

The command /a jmp eax assembles a string to machine code, and then searches for the resulting bytes:

[0x00404888]> /a jmp eax

hits: 1

0x004048e7 hit3_0 ffe00f1f8000000000b8

Thanks to Victor Muñoz, radare2 now has support of the algorithm he developed, capable of finding expanded AES keys with /Ca command. It searches from current seek position up to the search.distance limit, or until end of file is reached. You can interrupt current search by pressing Ctrl-C. For example, to look for AES keys in physical memory of your system:

$ sudo r2 /dev/mem

[0x00000000]> /ca

0 AES keys found

If you are simply looking for plaintext AES keys in your binary, /Ca will not find them, but you might want to search with is~AES instead if the programmer left those hints for you:

[0x00000000]> /Ca

Searching 0 byte in [0x100000-0x1f0000]

hits: 0

Searching 0 byte in [0x196e4-0x1b91c]

hits: 0

Searching 0 byte in [0x194b4-0x196e4]

hits: 0

Searching 0 byte in [0x8000-0x114b4]

hits: 0

[0x00000000]> is~AES

010 0x000096d4 0x000196d4 GLOBAL OBJ 16 AES_KEY

Other than that, AES keys might show up in different ways in the binary: encrypted, hidden by another encrypting routine, so there's no absolute way other than understanding the binary being analized. For instance, p=e might give some hints if high(er) entropy sections are found trying to cover up a hardcoded secret. As an example on entropy searching, since radare 3.2.0, there's the possibility to delimit entropy sections for later use like so:

[0x00000000]> b

0x100

[0x00000000]> b 4096

[0x00000000]> /s

0x00100000 - 0x00101000 ~ 5.556094

0x014e2c88 - 0x014e3c88 ~ 0.000000

0x01434374 - 0x01435374 ~ 6.332087

0x01435374 - 0x0144c374 ~ 3.664636

0x0144c374 - 0x0144d374 ~ 1.664368

0x0144d374 - 0x0144f374 ~ 4.229199

0x0144f374 - 0x01451374 ~ 2.000000

(...)

[0x00000000]> /s*

f entropy_section_0 0x00001000 0x00100000

f entropy_section_1 0x00001000 0x014e2c88

f entropy_section_2 0x00001000 0x01434374

f entropy_section_3 0x00017000 0x01435374

f entropy_section_4 0x00001000 0x0144c374

f entropy_section_5 0x00002000 0x0144d374

f entropy_section_6 0x00002000 0x0144f374

The blocksize is increased to 4096 bytes from the default 100 bytes so that the entropy search /s can work on reasonably sized chunks for entropy analysis. The sections flags can be applied with the dot operator, ./s* and then looped through px 32 @@ entropy*.

Moreover AES keys might be referenced from strings or pointed from the imports, for instance, so the / and other search-related commands can come in handy in this regard.

Disassembling in radare is just a way to represent an array of bytes. It is handled as a special print mode within p command.

In the old times, when the radare core was smaller, the disassembler was handled by an external rsc file. That is, radare first dumped current block into a file, and then simply called objdump configured to disassemble for Intel, ARM or other supported architectures.

It was a working and unix friendly solution, but it was inefficient as it repeated the same expensive actions over and over, because there were no caches. As a result, scrolling was terribly slow.

So there was a need to create a generic disassembler library to support multiple plugins for different architectures. We can list the current loaded plugins with

$ rasm2 -L

Or from inside radare2:

> e asm.arch=??

This was many years before capstone appeared. So r2 was using udis86 and olly disassemblers, many gnu (from binutils).

Nowadays, the disassembler support is one of the basic features of radare. It now has many options, endianness, including target architecture flavor and disassembler variants, among other things.

To see the disassembly, use the pd command. It accepts a numeric argument to specify how many opcodes of current block you want to see. Most of the commands in radare consider the current block size as the default limit for data input. If you want to disassemble more bytes, set a new block size using the b command.

[0x00000000]> b 100 ; set block size to 100

[0x00000000]> pd ; disassemble 100 bytes

[0x00000000]> pd 3 ; disassemble 3 opcodes

[0x00000000]> pD 30 ; disassemble 30 bytes

The pD command works like pd but accepts the number of input bytes as its argument, instead of the number of opcodes.

The "pseudo" syntax may be somewhat easier for a human to understand than the default assembler notations. But it can become annoying if you read lots of code. To play with it:

[0x00405e1c]> e asm.pseudo = true

[0x00405e1c]> pd 3

; JMP XREF from 0x00405dfa (fcn.00404531)

0x00405e1c 488b9424a80. rdx = [rsp+0x2a8]

0x00405e24 64483314252. rdx ^= [fs:0x28]

0x00405e2d 4889d8 rax = rbx

The typical work involved in reversing binary files makes powerful annotation capabilities essential. Radare offers multiple ways to store and retrieve such metadata.

By following common basic UNIX principles, it is easy to write a small utility in a scripting language which uses objdump, otool or any other existing utility to obtain information from a binary and to import it into radare. For example, take a look at idc2r.py shipped with radare2ida. To use it, invoke it as idc2r.py file.idc > file.r2. It reads an IDC file exported from an IDA Pro database and produces an r2 script containing the same comments, names of functions and other data. You can import the resulting 'file.r2' by using the dot . command of radare:

[0x00000000]> . file.r2

The . command is used to interpret Radare commands from external sources, including files and program output. For example, to omit generation of an intermediate file and import the script directly you can use this combination:

[0x00000000]> .!idc2r.py < file.idc

Please keep in mind that importing IDA Pro metadata from IDC dump is deprecated mechanism and might not work in the future. The recommended way to do it - use python-idb-based ida2r2.py which opens IDB files directly without IDA Pro installed.

The C command is used to manage comments and data conversions. You can define a range of program's bytes to be interpreted as either code, binary data or string. It is also possible to execute external code at every specified flag location in order to fetch some metadata, such as a comment, from an external file or database.

There are many different metadata manipulation commands, here is the glimpse of all of them:

[0x00404cc0]> C?

| Usage: C[-LCvsdfm*?][*?] [...] # Metadata management

| C list meta info in human friendly form

| C* list meta info in r2 commands

| C*. list meta info of current offset in r2 commands

| C- [len] [[@]addr] delete metadata at given address range

| C. list meta info of current offset in human friendly form

| CC! [@addr] edit comment with $EDITOR

| CC[?] [-] [comment-text] [@addr] add/remove comment

| CC.[addr] show comment in current address

| CCa[-at]|[at] [text] [@addr] add/remove comment at given address

| CCu [comment-text] [@addr] add unique comment

| CF[sz] [fcn-sign..] [@addr] function signature

| CL[-][*] [file:line] [addr] show or add 'code line' information (bininfo)

| CS[-][space] manage meta-spaces to filter comments, etc..

| C[Cthsdmf] list comments/types/hidden/strings/data/magic/formatted in human friendly form

| C[Cthsdmf]* list comments/types/hidden/strings/data/magic/formatted in r2 commands

| Cd[-] [size] [repeat] [@addr] hexdump data array (Cd 4 10 == dword [10])

| Cd. [@addr] show size of data at current address

| Cf[?][-] [sz] [0|cnt][fmt] [a0 a1...] [@addr] format memory (see pf?)

| Ch[-] [size] [@addr] hide data

| Cm[-] [sz] [fmt..] [@addr] magic parse (see pm?)

| Cs[?] [-] [size] [@addr] add string

| Ct[?] [-] [comment-text] [@addr] add/remove type analysis comment

| Ct.[@addr] show comment at current or specified address

| Cv[bsr][?] add comments to args

| Cz[@addr] add string (see Cs?)

Simply to add the comment to a particular line/address you can use Ca command:

[0x00000000]> CCa 0x0000002 this guy seems legit

[0x00000000]> pd 2

0x00000000 0000 add [rax], al

; this guy seems legit

0x00000002 0000 add [rax], al

The C? family of commands lets you mark a range as one of several kinds of types. Three basic types are: code (disassembly is done using asm.arch), data (an array of data elements) or string. Use the Cs comand to define a string, use the Cd command for defining an array of data elements, and use the Cf command to define more complex data structures like structs.

Annotating data types is most easily done in visual mode, using the "d" key, short for "data type change". First, use the cursor to select a range of bytes (press c key to toggle cursor mode and use HJKL keys to expand selection), then press 'd' to get a menu of possible actions/types. For example, to mark the range as a string, use the 's' option from the menu. You can achieve the same result from the shell using the Cs command:

[0x00000000]> f string_foo @ 0x800

[0x00000000]> Cs 10 @ string_foo

The Cf command is used to define a memory format string (the same syntax used by the pf command). Here's an example:

[0x7fd9f13ae630]> Cf 16 2xi foo bar

[0x7fd9f13ae630]> pd

;-- rip:

0x7fd9f13ae630 format 2xi foo bar {

0x7fd9f13ae630 [0] {

foo : 0x7fd9f13ae630 = 0xe8e78948

bar : 0x7fd9f13ae634 = 14696

}

0x7fd9f13ae638 [1] {

foo : 0x7fd9f13ae638 = 0x8bc48949

bar : 0x7fd9f13ae63c = 571928325

}

} 16

0x7fd9f13ae633 e868390000 call 0x7fd9f13b1fa0

0x7fd9f13ae638 4989c4 mov r12, rax

The [sz] argument to Cf is used to define how many bytes the struct should take up in the disassembly, and is completely independent from the size of the data structure defined by the format string. This may seem confusing, but has several uses. For example, you may want to see the formatted structure displayed in the disassembly, but still have those locations be visible as offsets and with raw bytes. Sometimes, you find large structures, but only identified a few fields, or only interested in specific fields. Then, you can tell r2 to display only those fields, using the format string and using 'skip' fields, and also have the disassembly continue after the entire structure, by giving it full size using the sz argument.

Using Cf, it's easy to define complex structures with simple oneliners. See pf? for more information. Remember that all these C commands can also be accessed from the visual mode by pressing the d (data conversion) key. Note that unlike t commands Cf doesn't change analysis results. It is only a visual boon.

Sometimes just adding a single line of comments is not enough, in this case radare2 allows you to create a link for a particular text file. You can use it with CC, command or by pressing , key in the visual mode. This will open an $EDITOR to create a new file, or if filename does exist, just will create a link. It will be shown in the disassembly comments:

[0x00003af7 11% 290 /bin/ls]> pd $r @ main+55 # 0x3af7

│0x00003af7 call sym.imp.setlocale ;[1] ; ,(locale-help.txt) ; char *setlocale(int category, const char *locale)

│0x00003afc lea rsi, str.usr_share_locale ; 0x179cc ; "/usr/share/locale"

│0x00003b03 lea rdi, [0x000179b2] ; "coreutils"

│0x00003b0a call sym.imp.bindtextdomain ;[2] ; char *bindtextdomain(char *domainname, char *dirname)

Note ,(locale-help.txt) appeared in the comments, if we press , again in the visual mode, it will open the file. Using this mechanism we can create a long descriptions of some particular places in disassembly, link datasheets or related articles.

ESIL stands for 'Evaluable Strings Intermediate Language'. It aims to describe a Forth-like representation for every target CPU opcode semantics. ESIL representations can be evaluated (interpreted) in order to emulate individual instructions. Each command of an ESIL expression is separated by a comma. Its virtual machine can be described as this:

while ((word=haveCommand())) {

if (word.isOperator()) {

esilOperators[word](esil);

} else {

esil.push (word);

}

nextCommand();

}

As we can see ESIL uses a stack-based interpreter similar to what is commonly used for calculators. You have two categories of inputs: values and operators. A value simply gets pushed on the stack, an operator then pops values (its arguments if you will) off the stack, performs its operation and pushes its results (if any) back on. We can think of ESIL as a post-fix notation of the operations we want to do.

So let's see an example:

4,esp,-=,ebp,esp,=[4]

Can you guess what this is? If we take this post-fix notation and transform it back to in-fix we get

esp -= 4

4bytes(dword) [esp] = ebp

We can see that this corresponds to the x86 instruction push ebp! Isn't that cool? The aim is to be able to express most of the common operations performed by CPUs, like binary arithmetic operations, memory loads and stores, processing syscalls. This way if we can transform the instructions to ESIL we can see what a program does while it is running even for the most cryptic architectures you definitely don't have a device to debug on for.

r2's visual mode is great to inspect the ESIL evaluations.

There are 3 environment variables that are important for watching what a program does:

[0x00000000]> e emu.str = true

asm.emu tells r2 if you want ESIL information to be displayed. If it is set to true, you will see comments appear to the right of your disassembly that tell you how the contents of registers and memory addresses are changed by the current instruction. For example, if you have an instruction that subtracts a value from a register it tells you what the value was before and what it becomes after. This is super useful so you don't have to sit there yourself and track which value goes where.

One problem with this is that it is a lot of information to take in at once and sometimes you simply don't need it. r2 has a nice compromise for this. That is what the emu.str variable is for (asm.emustr on <= 2.2). Instead of this super verbose output with every register value, this only adds really useful information to the output, e.g., strings that are found at addresses a program uses or whether a jump is likely to be taken or not.

The third important variable is asm.esil. This switches your disassembly to no longer show you the actual disassembled instructions, but instead now shows you corresponding ESIL expressions that describe what the instruction does. So if you want to take a look at how instructions are expressed in ESIL simply set "asm.esil" to true.

[0x00000000]> e asm.esil = true

In visual mode you can also toggle this by simply typing O.

A target opcode is translated into a comma separated list of ESIL expressions.

xor eax, eax -> 0,eax,=,1,zf,=

Memory access is defined by brackets operation:

mov eax, [0x80480] -> 0x80480,[],eax,=

Default operand size is determined by size of operation destination.

movb $0, 0x80480 -> 0,0x80480,=[1]

The ? operator uses the value of its argument to decide whether to evaluate the expression in curly braces.

   1. Is the value zero? -> Skip it.

   2. Is the value non-zero? -> Evaluate it.

cmp eax, 123 -> 123,eax,==,$z,zf,=

jz eax -> zf,?{,eax,eip,=,}

If you want to run several expressions under a conditional, put them in curly braces:

zf,?{,eip,esp,=[],eax,eip,=,$r,esp,-=,}

Whitespaces, newlines and other chars are ignored. So the first thing when processing a ESIL program is to remove spaces:

esil = r_str_replace (esil, " ", "", R_TRUE);

Syscalls need special treatment. They are indicated by '$' at the beginning of an expression. You can pass an optional numeric value to specify a number of syscall. An ESIL emulator must handle syscalls. See (r_esil_syscall).

Code analysis is a common technique used to extract information from assembly code.

Radare2 has different code analysis techniques implemented in the core and available in different commands.

As long as the whole functionalities of r2 are available with the API as well as using commands. This gives you the ability to implement your own analysis loops using any programming language, even with r2 oneliners, shellscripts, or analysis or core native plugins.

The analysis will show up the internal data structures to identify basic blocks, function trees and to extract opcode-level information.

The most common radare2 analysis command sequence is aa, which stands for "analyze all". That all is referring to all symbols and entry-points. If your binary is stripped you will need to use other commands like aaa, aab, aar, aac or so.

Take some time to understand what each command does and the results after running them to find the best one for your needs.

[0x08048440]> aa

[0x08048440]> pdf @ main

; DATA XREF from 0x08048457 (entry0)

/ (fcn) fcn.08048648 141

| ;-- main:

| 0x08048648 8d4c2404 lea ecx, [esp+0x4]

| 0x0804864c 83e4f0 and esp, 0xfffffff0

| 0x0804864f ff71fc push dword [ecx-0x4]

| 0x08048652 55 push ebp

| ; CODE (CALL) XREF from 0x08048734 (fcn.080486e5)

| 0x08048653 89e5 mov ebp, esp

| 0x08048655 83ec28 sub esp, 0x28

| 0x08048658 894df4 mov [ebp-0xc], ecx

| 0x0804865b 895df8 mov [ebp-0x8], ebx

| 0x0804865e 8975fc mov [ebp-0x4], esi

| 0x08048661 8b19 mov ebx, [ecx]

| 0x08048663 8b7104 mov esi, [ecx+0x4]

| 0x08048666 c744240c000. mov dword [esp+0xc], 0x0

| 0x0804866e c7442408010. mov dword [esp+0x8], 0x1 ; 0x00000001

| 0x08048676 c7442404000. mov dword [esp+0x4], 0x0

| 0x0804867e c7042400000. mov dword [esp], 0x0

| 0x08048685 e852fdffff call sym..imp.ptrace

| sym..imp.ptrace(unk, unk)

| 0x0804868a 85c0 test eax, eax

| ,=< 0x0804868c 7911 jns 0x804869f

| | 0x0804868e c70424cf870. mov dword [esp], str.Don_tuseadebuguer_ ; 0x080487cf

| | 0x08048695 e882fdffff call sym..imp.puts

| | sym..imp.puts()

| | 0x0804869a e80dfdffff call sym..imp.abort

| | sym..imp.abort()

| `-> 0x0804869f 83fb02 cmp ebx, 0x2

|,==< 0x080486a2 7411 je 0x80486b5

|| 0x080486a4 c704240c880. mov dword [esp], str.Youmustgiveapasswordforusethisprogram_ ; 0x0804880c

|| 0x080486ab e86cfdffff call sym..imp.puts

|| sym..imp.puts()

|| 0x080486b0 e8f7fcffff call sym..imp.abort

|| sym..imp.abort()

|`--> 0x080486b5 8b4604 mov eax, [esi+0x4]

| 0x080486b8 890424 mov [esp], eax

| 0x080486bb e8e5feffff call fcn.080485a5

| fcn.080485a5() ; fcn.080484c6+223

| 0x080486c0 b800000000 mov eax, 0x0

| 0x080486c5 8b4df4 mov ecx, [ebp-0xc]

| 0x080486c8 8b5df8 mov ebx, [ebp-0x8]

| 0x080486cb 8b75fc mov esi, [ebp-0x4]

| 0x080486ce 89ec mov esp, ebp

| 0x080486d0 5d pop ebp

| 0x080486d1 8d61fc lea esp, [ecx-0x4]

\ 0x080486d4 c3 ret

In this example, we analyze the whole file (aa) and then print disassembly of the main() function (pdf). The aa command belongs to the family of auto analysis commands and performs only the most basic auto analysis steps. In radare2 there are many different types of the auto analysis commands with a different analysis depth, including partial emulation: aa, aaa, aab, aaaa, ... There is also a mapping of those commands to the r2 CLI options: r2 -A, r2 -AA, and so on.

It is a common sense that completely automated analysis can produce non sequitur results, thus radare2 provides separate commands for the particular stages of the analysis allowing fine-grained control of the analysis process. Moreover, there is a treasure trove of configuration variables for controlling the analysis outcomes. You can find them in anal.* and emu.* cfg variables' namespaces.

There are 5 important program wide half-automated analysis commands:

   • aab - perform basic-block analysis ("Nucleus" algorithm)

   • aac - analyze function calls from one (selected or current function)

   • aaf - analyze all function calls

   • aar - analyze data references

   • aad - analyze pointers to pointers references

Those are only generic semi-automated reference searching algorithms. Radare2 provides a wide choice of manual references' creation of any kind. For this fine-grained control you can use ax commands.

Usage: ax[?d-l*] # see also 'afx?'

| ax list refs

| ax* output radare commands

| ax addr [at] add code ref pointing to addr (from curseek)

| ax- [at] clean all refs/refs from addr

| ax-* clean all refs/refs

| axc addr [at] add generic code ref

| axC addr [at] add code call ref

| axg [addr] show xrefs graph to reach current function

| axg* [addr] show xrefs graph to given address, use .axg*;aggv

| axgj [addr] show xrefs graph to reach current function in json format

| axd addr [at] add data ref

| axq list refs in quiet/human-readable format

| axj list refs in json format

| axF [flg-glob] find data/code references of flags

| axm addr [at] copy data/code references pointing to addr to also point to curseek (or at)

| axt [addr] find data/code references to this address

| axf [addr] find data/code references from this address

| axv [addr] list local variables read-write-exec references

| ax. [addr] find data/code references from and to this address

| axff[j] [addr] find data/code references from this function

| axs addr [at] add string ref

The most commonly used ax commands are axt and axf, especially as a part of various r2pipe scripts. Lets say we see the string in the data or a code section and want to find all places it was referenced from, we should use axt:

[0x0001783a]> pd 2

;-- str.02x:

; STRING XREF from 0x00005de0 (sub.strlen_d50)

; CODE XREF from 0x00017838 (str.._s_s_s + 7)

0x0001783a .string "%%%02x" ; len=7

;-- str.src_ls.c:

; STRING XREF from 0x0000541b (sub.free_b04)

; STRING XREF from 0x0000543a (sub.__assert_fail_41f + 27)

; STRING XREF from 0x00005459 (sub.__assert_fail_41f + 58)

; STRING XREF from 0x00005f9e (sub._setjmp_e30)

; CODE XREF from 0x0001783f (str.02x + 5)

0x00017841 .string "src/ls.c" ; len=9

[0x0001783a]> axt

sub.strlen_d50 0x5de0 [STRING] lea rcx, str.02x

(nofunc) 0x17838 [CODE] jae str.02x

There are also some useful commands under axt. Use axtg to generate radare2 commands which will help you to create graphs according to the XREFs.

[0x08048320]> s main

[0x080483e0]> axtg

agn 0x8048337 "entry0 + 23"

agn 0x80483e0 "main"

age 0x8048337 0x80483e0

Use axt* to split the radare2 commands and set flags on those corresponding XREFs.

Also under ax is axg, which finds the path between two points in the file by showing an XREFs graph to reach the location or function. For example:

:> axg sym.imp.printf

- 0x08048a5c fcn 0x08048a5c sym.imp.printf

- 0x080483e5 fcn 0x080483e0 main

- 0x080483e0 fcn 0x080483e0 main

- 0x08048337 fcn 0x08048320 entry0

- 0x08048425 fcn 0x080483e0 main

Use axg* to generate radare2 commands which will help you to create graphs using agn and age commands, according to the XREFs.

Apart from predefined algorithms to identify functions there is a way to specify a function prelude with a configuration option anal.prelude. For example, like e anal.prelude = 0x554889e5 which means

push rbp

mov rbp, rsp

on x86_64 platform. It should be specified before any analysis commands.

One of the easiest way to see and check the changes of the analysis commands and variables is to perform a scrolling in a Vv special visual mode, allowing functions preview:

When we want to check how analysis changes affect the result in the case of big functions, we can use minimap instead, allowing to see a bigger flow graph on the same screen size. To get into the minimap mode type VV then press p twice:

This mode allows you to see the disassembly of each node separately, just navigate between them using Tab key.

It is not an uncommon case that analysis results are not perfect even after you tried every single configuration option. This is where the "analysis hints" radare2 mechanism comes in. It allows to override some basic opcode or meta-information properties, or even to rewrite the whole opcode string. These commands are located under ah namespace:

Usage: ah[lba-] Analysis Hints

| ah? show this help

| ah? offset show hint of given offset

| ah list hints in human-readable format

| ah. list hints in human-readable format from current offset

| ah- remove all hints

| ah- offset [size] remove hints at given offset

| ah* offset list hints in radare commands format

| aha ppc @ 0x42 force arch ppc for all addrs >= 0x42 or until the next hint

| aha 0 @ 0x84 disable the effect of arch hints for all addrs >= 0x84 or until the next hint

| ahb 16 @ 0x42 force 16bit for all addrs >= 0x42 or until the next hint

| ahb 0 @ 0x84 disable the effect of bits hints for all addrs >= 0x84 or until the next hint

| ahc 0x804804 override call/jump address

| ahd foo a0,33 replace opcode string

| ahe 3,eax,+= set vm analysis string

| ahf 0x804840 override fallback address for call

| ahF 0x10 set stackframe size at current offset

| ahh 0x804840 highlight this address offset in disasm

| ahi[?] 10 define numeric base for immediates (2, 8, 10, 10u, 16, i, p, S, s)

| ahj list hints in JSON

| aho call change opcode type (see aho?) (deprecated, moved to "ahd")

| ahp addr set pointer hint

| ahr val set hint for return value of a function

| ahs 4 set opcode size=4

| ahS jz set asm.syntax=jz for this opcode

| aht [?] <type> Mark immediate as a type offset (deprecated, moved to "aho")

| ahv val change opcode's val field (useful to set jmptbl sizes in jmp rax)

One of the most common cases is to set a particular numeric base for immediates:

[0x00003d54]> ahi?

Usage: ahi [2|8|10|10u|16|bodhipSs] [@ offset] Define numeric base

| ahi <base> set numeric base (2, 8, 10, 16)

| ahi 10|d set base to signed decimal (10), sign bit should depend on receiver size

| ahi 10u|du set base to unsigned decimal (11)

| ahi b set base to binary (2)

| ahi o set base to octal (8)

| ahi h set base to hexadecimal (16)

| ahi i set base to IP address (32)

| ahi p set base to htons(port) (3)

| ahi S set base to syscall (80)

| ahi s set base to string (1)

Radare2 allows managing local variables, no matter their location, stack or registers. The variables' auto analysis is enabled by default but can be disabled with anal.vars configuration option.

The main variables commands are located in afv namespace:

Usage: afv [rbs]

| afv* output r2 command to add args/locals to flagspace

| afv-([name]) remove all or given var

| afv= list function variables and arguments with disasm refs

| afva analyze function arguments/locals

| afvb[?] manipulate bp based arguments/locals

| afvd name output r2 command for displaying the value of args/locals in the debugger

| afvf show BP relative stackframe variables

| afvn [new_name] ([old_name]) rename argument/local

| afvr[?] manipulate register based arguments

| afvR [varname] list addresses where vars are accessed (READ)

| afvs[?] manipulate sp based arguments/locals

| afvt [name] [new_type] change type for given argument/local

| afvW [varname] list addresses where vars are accessed (WRITE)

| afvx show function variable xrefs (same as afvR+afvW)

afvr, afvb and afvs commands are uniform but allow manipulation of register-based arguments and variables, BP/FP-based arguments and variables, and SP-based arguments and variables respectively. If we check the help for afvr we will get the way two others commands works too:

|Usage: afvr [reg] [type] [name]

| afvr list register based arguments

| afvr* same as afvr but in r2 commands

| afvr [reg] [name] ([type]) define register arguments

| afvrj return list of register arguments in JSON format

| afvr- [name] delete register arguments at the given index

| afvrg [reg] [addr] define argument get reference

| afvrs [reg] [addr] define argument set reference

Like many other things variables detection is performed by radare2 automatically, but results can be changed with those arguments/variables control commands. This kind of analysis relies heavily on preloaded function prototypes and the calling-convention, thus loading symbols can improve it. Moreover, after changing something we can rerun variables analysis with afva command. Quite often variables analysis is accompanied with types analysis, see afta command.

The most important aspect of reverse engineering - naming things. Of course, you can rename variable too, affecting all places it was referenced. This can be achieved with afvn for any type of argument or variable. Or you can simply remove the variable or argument with afv- command.

As mentioned before the analysis loop relies heavily on types information while performing variables analysis stages. Thus comes next very important command - afvt, which allows you to change the type of variable:

[0x00003b92]> afvs

var int local_8h @ rsp+0x8

var int local_10h @ rsp+0x10

var int local_28h @ rsp+0x28

var int local_30h @ rsp+0x30

var int local_32h @ rsp+0x32

var int local_38h @ rsp+0x38

var int local_45h @ rsp+0x45

var int local_46h @ rsp+0x46

var int local_47h @ rsp+0x47

var int local_48h @ rsp+0x48

[0x00003b92]> afvt local_10h char*

[0x00003b92]> afvs

var int local_8h @ rsp+0x8

var char* local_10h @ rsp+0x10

var int local_28h @ rsp+0x28

var int local_30h @ rsp+0x30

var int local_32h @ rsp+0x32

var int local_38h @ rsp+0x38

var int local_45h @ rsp+0x45

var int local_46h @ rsp+0x46

var int local_47h @ rsp+0x47

var int local_48h @ rsp+0x48

Less commonly used feature, which is still under heavy development - distinction between variables being read and written. You can list those being read with afvR command and those being written with afvW command. Both commands provide a list of the places those operations are performed:

[0x00003b92]> afvR

local_48h 0x48ee

local_30h 0x3c93,0x520b,0x52ea,0x532c,0x5400,0x3cfb

local_10h 0x4b53,0x5225,0x53bd,0x50cc

local_8h 0x4d40,0x4d99,0x5221,0x53b9,0x50c8,0x4620

local_28h 0x503a,0x51d8,0x51fa,0x52d3,0x531b

local_38h

local_45h 0x50a1

local_47h

local_46h

local_32h 0x3cb1

[0x00003b92]> afvW

local_48h 0x3adf

local_30h 0x3d3e,0x4868,0x5030

local_10h 0x3d0e,0x5035

local_8h 0x3d13,0x4d39,0x5025

local_28h 0x4d00,0x52dc,0x53af,0x5060,0x507a,0x508b

local_38h 0x486d

local_45h 0x5014,0x5068

local_47h 0x501b

local_46h 0x5083

local_32h

[0x00003b92]>

The type inference for local variables and arguments is well integrated with the command afta.

Let's see an example of this with a simple hello_world binary

[0x000007aa]> pdf

| ;-- main:

/ (fcn) sym.main 157

| sym.main ();

| ; var int local_20h @ rbp-0x20

| ; var int local_1ch @ rbp-0x1c

| ; var int local_18h @ rbp-0x18

| ; var int local_10h @ rbp-0x10

| ; var int local_8h @ rbp-0x8

| ; DATA XREF from entry0 (0x6bd)

| 0x000007aa push rbp

| 0x000007ab mov rbp, rsp

| 0x000007ae sub rsp, 0x20

| 0x000007b2 lea rax, str.Hello ; 0x8d4 ; "Hello"

| 0x000007b9 mov qword [local_18h], rax

| 0x000007bd lea rax, str.r2_folks ; 0x8da ; " r2-folks"

| 0x000007c4 mov qword [local_10h], rax

| 0x000007c8 mov rax, qword [local_18h]

| 0x000007cc mov rdi, rax

| 0x000007cf call sym.imp.strlen ; size_t strlen(const char *s)

   • After applying afta

[0x000007aa]> afta

[0x000007aa]> pdf

| ;-- main:

| ;-- rip:

/ (fcn) sym.main 157

| sym.main ();

| ; var size_t local_20h @ rbp-0x20

| ; var size_t size @ rbp-0x1c

| ; var char *src @ rbp-0x18

| ; var char *s2 @ rbp-0x10

| ; var char *dest @ rbp-0x8

| ; DATA XREF from entry0 (0x6bd)

| 0x000007aa push rbp

| 0x000007ab mov rbp, rsp

| 0x000007ae sub rsp, 0x20

| 0x000007b2 lea rax, str.Hello ; 0x8d4 ; "Hello"

| 0x000007b9 mov qword [src], rax

| 0x000007bd lea rax, str.r2_folks ; 0x8da ; " r2-folks"

| 0x000007c4 mov qword [s2], rax

| 0x000007c8 mov rax, qword [src]

| 0x000007cc mov rdi, rax ; const char *s

| 0x000007cf call sym.imp.strlen ; size_t strlen(const char *s)

It also extracts type information from format strings like printf ("fmt : %s , %u , %d", ...), the format specifications are extracted from anal/d/spec.sdb

You could create a new profile for specifying a set of format chars depending on different libraries/operating systems/programming languages like this :

win=spec

spec.win.u32=unsigned int

Then change your default specification to newly created one using this config variable e anal.spec = win

For more information about primitive and user-defined types support in radare2 refer to types chapter.

Radare2 supports the C-syntax data types description. Those types are parsed by a C11-compatible parser and stored in the internal SDB, thus are introspectable with k command.

Most of the related commands are located in t namespace:

[0x000051c0]> t?

| Usage: t # cparse types commands

| t List all loaded types

| tj List all loaded types as json

| t <type> Show type in 'pf' syntax

| t* List types info in r2 commands

| t- <name> Delete types by its name

| t-* Remove all types

| tail [filename] Output the last part of files

| tc [type.name] List all/given types in C output format

| te[?] List all loaded enums

| td[?] <string> Load types from string

| tf List all loaded functions signatures

| tk <sdb-query> Perform sdb query

| tl[?] Show/Link type to an address

| tn[?] [-][addr] manage noreturn function attributes and marks

| to - Open cfg.editor to load types

| to <path> Load types from C header file

| toe [type.name] Open cfg.editor to edit types

| tos <path> Load types from parsed Sdb database

| tp <type> [addr|varname] cast data at <address> to <type> and print it (XXX: type can contain spaces)

| tpv <type> @ [value] Show offset formatted for given type

| tpx <type> <hexpairs> Show value for type with specified byte sequence (XXX: type can contain spaces)

| ts[?] Print loaded struct types

| tu[?] Print loaded union types

| tx[f?] Type xrefs

| tt[?] List all loaded typedefs

Note that the basic (atomic) types are not those from C standard - not char, _Bool, or short. Because those types can be different from one platform to another, radare2 uses definite types like as int8_t or uint64_t and will convert int to int32_t or int64_t depending on the binary or debuggee platform/compiler.

Basic types can be listed using t command, for the structured types you need to use ts, tu or te for enums:

[0x000051c0]> t

char

char *

int

int16_t

int32_t

int64_t

int8_t

long

long long

...

One of the most important things to remember in reverse engineering is a core difference between static analysis and dynamic analysis. As many already know, static analysis suffers from the path explosion problem, which is impossible to solve even in the most basic way without at least a partial emulation.

Thus many professional reverse engineering tools use code emulation while performing an analysis of binary code, and radare2 is no difference here.

For partial emulation (or imprecise full emulation) radare2 uses its own ESIL intermediate language and virtual machine.

Radare2 supports this kind of partial emulation for all platforms that implement ESIL uplifting (x86/x86_64, ARM, arm64, MIPS, powerpc, sparc, AVR, 8051, Gameboy, ...).

One of the most common usages of such emulation is to calculate indirect jumps and conditional jumps.

To see the ESIL representation of the program one can use the ao command or enable the asm.esil configuration variable, to check if the program uplifted correctly, and to grasp how ESIL works:

[0x00001660]> pdf

. (fcn) fcn.00001660 40

│ fcn.00001660 ();

│ ; CALL XREF from 0x00001713 (entry2.fini)

│ 0x00001660 lea rdi, obj.__progname ; 0x207220

│ 0x00001667 push rbp

│ 0x00001668 lea rax, obj.__progname ; 0x207220

│ 0x0000166f cmp rax, rdi

│ 0x00001672 mov rbp, rsp

│ .─< 0x00001675 je 0x1690

│ │ 0x00001677 mov rax, qword [reloc._ITM_deregisterTMCloneTable] ; [0x206fd8:8]=0

│ │ 0x0000167e test rax, rax

│.──< 0x00001681 je 0x1690

│││ 0x00001683 pop rbp

│││ 0x00001684 jmp rax

│``─> 0x00001690 pop rbp

` 0x00001691 ret

[0x00001660]> e asm.esil=true

[0x00001660]> pdf

. (fcn) fcn.00001660 40

│ fcn.00001660 ();

│ ; CALL XREF from 0x00001713 (entry2.fini)

│ 0x00001660 0x205bb9,rip,+,rdi,=

│ 0x00001667 rbp,8,rsp,-=,rsp,=[8]

│ 0x00001668 0x205bb1,rip,+,rax,=

│ 0x0000166f rdi,rax,==,$z,zf,=,$b64,cf,=,$p,pf,=,$s,sf,=,$o,of,=

│ 0x00001672 rsp,rbp,=

│ .─< 0x00001675 zf,?{,5776,rip,=,}

│ │ 0x00001677 0x20595a,rip,+,[8],rax,=

│ │ 0x0000167e 0,rax,rax,&,==,$z,zf,=,$p,pf,=,$s,sf,=,$0,cf,=,$0,of,=

│.──< 0x00001681 zf,?{,5776,rip,=,}

│││ 0x00001683 rsp,[8],rbp,=,8,rsp,+=

│││ 0x00001684 rax,rip,=

│``─> 0x00001690 rsp,[8],rbp,=,8,rsp,+=

` 0x00001691 rsp,[8],rip,=,8,rsp,+=

To manually setup the ESIL imprecise emulation you need to run this command sequence:

   • aei to initialize ESIL VM

   • aeim to initialize ESIL VM memory (stack)

   • aeip to set the initial ESIL VM IP (instruction pointer)

   • a sequence of aer commands to set the initial register values.

While performing emulation, please remember, that ESIL VM cannot emulate external calls or system calls, along with SIMD instructions. Thus the most common scenario is to emulate only a small chunk of the code, like encryption/decryption, unpacking or calculating something.

After we successfully set up the ESIL VM we can interact with it like with a usual debugging mode. Commands interface for ESIL VM is almost identical to the debugging one:

   • aes to step (or s key in visual mode)

   • aesi to step over the function calls

   • aesu <address> to step until some specified address

   • aesue <ESIL expression> to step until some specified ESIL expression met

   • aec to continue until break (Ctrl-C), this one is rarely used though, due to the omnipresence of external calls

In visual mode, all of the debugging hotkeys will work also in ESIL emulation mode.

Along with usual emulation, there is a possibility to record and replay mode:

   • aets to list all current ESIL R&R sessions

   • aets+ to create a new one

   • aesb to step back in the current ESIL R&R session

More about this operation mode you can read in Reverse Debugging chapter.

Apart from the manual emulation mode, it can be used automatically in the analysis loop. For example, the aaaa command performs the ESIL emulation stage along with others. To disable or enable its usage you can use anal.esil configuration variable. There is one more important option, though setting it might be quite dangerous, especially in the case of malware - emu.write which allows ESIL VM to modify memory. Sometimes it is required though, especially in the process of deobfuscating or unpacking code.

To show the process of emulation you can set asm.emu variable, which will show calculated register and memory values in disassembly comments:

[0x00001660]> e asm.emu=true

[0x00001660]> pdf

. (fcn) fcn.00001660 40

│ fcn.00001660 ();

│ ; CALL XREF from 0x00001713 (entry2.fini)

│ 0x00001660 lea rdi, obj.__progname ; 0x207220 ; rdi=0x207220 -> 0x464c457f

│ 0x00001667 push rbp ; rsp=0xfffffffffffffff8

│ 0x00001668 lea rax, obj.__progname ; 0x207220 ; rax=0x207220 -> 0x464c457f

│ 0x0000166f cmp rax, rdi ; zf=0x1 -> 0x2464c45 ; cf=0x0 ; pf=0x1 -> 0x2464c45 ; sf=0x0 ; of=0x0

│ 0x00001672 mov rbp, rsp ; rbp=0xfffffffffffffff8

│ .─< 0x00001675 je 0x1690 ; rip=0x1690 -> 0x1f0fc35d ; likely

│ │ 0x00001677 mov rax, qword [reloc._ITM_deregisterTMCloneTable] ; [0x206fd8:8]=0 ; rax=0x0

│ │ 0x0000167e test rax, rax ; zf=0x1 -> 0x2464c45 ; pf=0x1 -> 0x2464c45 ; sf=0x0 ; cf=0x0 ; of=0x0

│.──< 0x00001681 je 0x1690 ; rip=0x1690 -> 0x1f0fc35d ; likely

│││ 0x00001683 pop rbp ; rbp=0xffffffffffffffff -> 0x4c457fff ; rsp=0x0

│││ 0x00001684 jmp rax ; rip=0x0 ..

│``─> 0x00001690 pop rbp ; rbp=0x10102464c457f ; rsp=0x8 -> 0x464c457f

` 0x00001691 ret ; rip=0x0 ; rsp=0x10 -> 0x3e0003

Note here likely comments, which indicates that ESIL emulation predicted for particular conditional jump to happen.

Apart from the basic ESIL VM setup, you can change the behavior with other options located in emu. and esil. configuration namespaces.

For manipulating ESIL working with memory and stack you can use the following options:

   • esil.stack to enable or disable temporary stack for asm.emu mode

   • esil.stack.addr to set stack address in ESIL VM (like aeim command)

   • esil.stack.size to set stack size in ESIL VM (like aeim command)

   • esil.stack.depth limits the number of PUSH operations into the stack

   • esil.romem specifies read-only access to the ESIL memory

   • esil.fillstack and esil.stack.pattern allows you to use a various pattern for filling ESIL VM stack upon initialization

   • esil.nonull when set stops ESIL execution upon NULL pointer read or write.

Radare2 has its own format of the signatures, allowing to both load/apply and create them on the fly. They are available under the z command namespace:

[0x00000000]> z?

Usage: z[*j-aof/cs] [args] # Manage zignatures

| z show zignatures

| z. find matching zignatures in current offset

| zb[?][n=5] search for best match

| z* show zignatures in radare format

| zq show zignatures in quiet mode

| zj show zignatures in json format

| zk show zignatures in sdb format

| z-zignature delete zignature

| z-* delete all zignatures

| za[?] add zignature

| zg generate zignatures (alias for zaF)

| zo[?] manage zignature files

| zf[?] manage FLIRT signatures

| z/[?] search zignatures

| zc[?] compare current zignspace zignatures with another one

| zs[?] manage zignspaces

| zi show zignatures matching information

To load the created signature file you need to load it from SDB file using zo command or from the compressed SDB file using zoz command.

To create signature you need to make function first, then you can create it from the function:

r2 /bin/ls

[0x000051c0]> aaa # this creates functions, including 'entry0'

[0x000051c0]> zaf entry0 entry

[0x000051c0]> z

entry:

bytes: 31ed4989d15e4889e24883e4f050544c............48............48............ff..........f4

graph: cc=1 nbbs=1 edges=0 ebbs=1

offset: 0x000051c0

[0x000051c0]>

As you can see it made a new signature with a name entry from a function entry0. You can show it in JSON format too, which can be useful for scripting:

[0x000051c0]> zj~{}

[

{

"name": "entry",

"bytes": "31ed4989d15e4889e24883e4f050544c............48............48............ff..........f4",

"graph": {

"cc": "1",

"nbbs": "1",

"edges": "0",

"ebbs": "1"

},

"offset": 20928,

"refs": [

]

}

]

[0x000051c0]>

To remove it just run z-entry.

If you want, instead, to save all created signatures, you need to save it into the SDB file using command zos myentry.

Then we can apply them. Lets open a file again:

r2 /bin/ls

-- Log On. Hack In. Go Anywhere. Get Everything.

[0x000051c0]> zo myentry

[0x000051c0]> z

entry:

bytes: 31ed4989d15e4889e24883e4f050544c............48............48............ff..........f4

graph: cc=1 nbbs=1 edges=0 ebbs=1

offset: 0x000051c0

[0x000051c0]>

This means that the signatures were successfully loaded from the file myentry and now we can search matching functions:

[0x000051c0]> z.

[+] searching 0x000051c0 - 0x000052c0

[+] searching function metrics

hits: 1

[0x000051c0]>

Note that z. command just checks the signatures against the current address. To search signatures across the all file we need to do a bit different thing. There is an important moment though, if we just run it "as is" - it wont find anything:

[0x000051c0]> z/

[+] searching 0x0021dfd0 - 0x002203e8

[+] searching function metrics

hits: 0

[0x000051c0]>

Note the searching address - this is because we need to adjust the searching range first:

[0x000051c0]> e search.in=io.section

[0x000051c0]> z/

[+] searching 0x000038b0 - 0x00015898

[+] searching function metrics

hits: 1

[0x000051c0]>

We are setting the search mode to io.section (it was file by default) to search in the current section (assuming we are currently in the .text section of course). Now we can check, what radare2 found for us:

[0x000051c0]> pd 5

;-- entry0:

;-- sign.bytes.entry_0:

0x000051c0 31ed xor ebp, ebp

0x000051c2 4989d1 mov r9, rdx

0x000051c5 5e pop rsi

0x000051c6 4889e2 mov rdx, rsp

0x000051c9 4883e4f0 and rsp, 0xfffffffffffffff0

[0x000051c0]>

Here we can see the comment of entry0, which is taken from the ELF parsing, but also the sign.bytes.entry_0, which is exactly the result of matching signature.

Signatures configuration stored in the zign. config vars' namespace:

[0x000051c0]> e? zign.

zign.autoload: Autoload all zignatures located in ~/.local/share/radare2/zigns

zign.bytes: Use bytes patterns for matching

zign.diff.bthresh: Threshold for diffing zign bytes [0, 1] (see zc?)

zign.diff.gthresh: Threshold for diffing zign graphs [0, 1] (see zc?)

zign.graph: Use graph metrics for matching

zign.hash: Use Hash for matching

zign.maxsz: Maximum zignature length

zign.mincc: Minimum cyclomatic complexity for matching

zign.minsz: Minimum zignature length for matching

zign.offset: Use original offset for matching

zign.prefix: Default prefix for zignatures matches

zign.refs: Use references for matching

zign.threshold: Minimum similarity required for inclusion in zb output

zign.types: Use types for matching

[0x000051c0]>

Often you know the signature should exist somewhere in a binary but z/ and z. still fail. This is often due to very minor differences between the signature and the function. Maybe the compiler switched two instructions, or your signature is not for the correct function version. In these situations the zb commands can still help point you in the right direction by listing near matches.

[0x000040a0]> zb?

Usage: zb[r?] [args] # search for closest matching signatures

| zb [n] find n closest matching zignatures to function at current offset

| zbr zigname [n] search for n most similar functions to zigname

The zb (zign best) command will show the top 5 closest signatures to a function. Each will contain a score between 1.0 and 0.0.

[0x0041e390]> s sym.fclose

[0x0040fc10]> zb

0.96032 0.92400 B 0.99664 G sym.fclose

0.65971 0.35600 B 0.96342 G sym._nl_expand_alias

0.65770 0.37800 B 0.93740 G sym.fdopen

0.65112 0.35000 B 0.95225 G sym.__run_exit_handlers

0.62532 0.34800 B 0.90264 G sym.__cxa_finalize

In the above example, zb correctly associated the sym.fclose signature to the current function. The z/ and z. command would have failed to match here since both the Byte and Graph scores are less then 1.0. A 30% separation between the first and second place results is also a good indication of a correct match.

The zbr (zign best reverse) accepts a zignature name and attempts to find the closet matching functions. Use an analysis command, like aa to find functions first.

[0x00401b20]> aa

[x] Analyze all flags starting with sym. and entry0 (aa)

[0x00401b20]> zo ./libc.sdb

[0x00401b20]> zbr sym.__libc_malloc 10

0.94873 0.89800 B 0.99946 G sym.malloc

0.65245 0.40600 B 0.89891 G sym._mid_memalign

0.59470 0.38600 B 0.80341 G sym._IO_flush_all_lockp

0.59200 0.28200 B 0.90201 G sym._IO_file_underflow

0.57802 0.30400 B 0.85204 G sym.__libc_realloc

0.57094 0.35200 B 0.78988 G sym.__calloc

0.56785 0.34000 B 0.79570 G sym._IO_un_link.part.0

0.56358 0.36200 B 0.76516 G sym._IO_cleanup

0.56064 0.26000 B 0.86127 G sym.intel_check_word.constprop.0

0.55726 0.28400 B 0.83051 G sym.linear_search_fdes

When analyzing data it is usually handy to have different ways to represent it in order to get new perspectives to allow the analyst to understand how different parts of the program interact.

Representing basic block edges, function calls, string references as graphs show a very clear view of this information.

Radare2 supports various types of graph available through commands starting with ag:

[0x00005000]> ag?

|Usage: ag<graphtype><format> [addr]

| Graph commands:

| aga[format] Data references graph

| agA[format] Global data references graph

| agc[format] Function callgraph

| agC[format] Global callgraph

| agd[format] [fcn addr] Diff graph

| agf[format] Basic blocks function graph

| agi[format] Imports graph

| agr[format] References graph

| agR[format] Global references graph

| agx[format] Cross references graph

| agg[format] Custom graph

| ag- Clear the custom graph

| agn[?] title body Add a node to the custom graph

| age[?] title1 title2 Add an edge to the custom graph

Radare2 provides a wide set of a features to automate boring work. It ranges from the simple sequencing of the commands to the calling scripts/another programs via IPC (Inter-Process Communication), called r2pipe.

As mentioned a few times before there is an ability to sequence commands using ; semicolon operator.

[0x00404800]> pd 1 ; ao 1

0x00404800 b827e66100 mov eax, 0x61e627 ; "tab"

address: 0x404800

opcode: mov eax, 0x61e627

prefix: 0

bytes: b827e66100

ptr: 0x0061e627

refptr: 0

size: 5

type: mov

esil: 6415911,rax,=

stack: null

family: cpu

[0x00404800]>

It simply runs the second command after finishing the first one, like in a shell.

The second important way to sequence the commands is with a simple pipe |

ao|grep address

Note, the | pipe only can pipe output of r2 commands to external (shell) commands, like system programs or builtin shell commands. There is a similar way to sequence r2 commands, using the backtick operator `command`. The quoted part will undergo command substitution and the output will be used as an argument of the command line.

For example, we want to see a few bytes of the memory at the address referred to by the 'mov eax, addr' instruction. We can do that without jumping to it, using a sequence of commands:

[0x00404800]> pd 1

0x00404800 b827e66100 mov eax, 0x61e627 ; "tab"

[0x00404800]> ao

address: 0x404800

opcode: mov eax, 0x61e627

prefix: 0

bytes: b827e66100

ptr: 0x0061e627

refptr: 0

size: 5

type: mov

esil: 6415911,rax,=

stack: null

family: cpu

[0x00404800]> ao~ptr[1]

0x0061e627

0

[0x00404800]> px 10 @ `ao~ptr[1]`

- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF

0x0061e627 7461 6200 2e69 6e74 6572 tab..inter

[0x00404800]>

And of course it's possible to redirect the output of an r2 command into a file, using the > and >> commands

[0x00404800]> px 10 @ `ao~ptr[1]` > example.txt

[0x00404800]> px 10 @ `ao~ptr[1]` >> example.txt

Radare2 also provides quite a few Unix type file processing commands like head, tail, cat, grep and many more. One such command is Uniq, which can be used to filter a file to display only non-duplicate content. So to make a new file with only unique strings, you can do:

[0x00404800]> uniq file > uniq_file

The head command can be used to see the first N number of lines in the file, similarly tail command allows the last N number of lines to be seen.

[0x00404800]> head 3 foodtypes.txt

1 Protein

2 Carbohydrate

3 Fat

[0x00404800]> tail 2 foodtypes.txt

3 Shake

4 Milk

The join command could be used to merge two different files with common first field.

[0x00404800]> cat foodtypes.txt

1 Protein

2 Carbohydrate

3 Fat

[0x00404800]> cat foods.txt

1 Cheese

2 Potato

3 Butter

[0x00404800]> join foodtypes foods.txt

1 Protein Cheese

2 Carbohydrate Potato

3 Fat Butter

Similarly, sorting the content is also possible with the sort command. A typical example could be:

[0x00404800]> sort file

eleven

five

five

great

one

one

radare

The ?$? command describes several helpful variables you can use to do similar actions even more easily, like the $v "immediate value" variable, or the $m opcode memory reference variable.

$ pip install r2pipe

import r2pipe

Use this command to install the r2pipe bindings

$ npm install r2pipe

Here's a sample hello world

const r2pipe = require('r2pipe');

r2pipe.open('/bin/ls', (err, res) => {

if (err) {

throw err;

}

r2.cmd ('af @ entry0', function (o) {

r2.cmd ("pdf @ entry0", function (o) {

console.log (o);

r.quit ()

});

});

});

Checkout the GIT repository for more examples and details.

https://github.com/radareorg/radare2-r2pipe/blob/master/nodejs/r2pipe/README.md

$ r2pm -i r2pipe-go

https://github.com/radare/r2pipe-go

package main

$ cat Cargo.toml

...

[dependencies]

r2pipe = "*"

#[macro_use]

extern crate r2pipe;

use r2pipe::R2Pipe;

fn main() {

let mut r2p = open_pipe!(Some("/bin/ls")).unwrap();

println!("{:?}", r2p.cmd("?e Hello World"));

let json = r2p.cmdj("ij").unwrap();

println!("{}", serde_json::to_string_pretty(&json).unwrap());

println!("ARCH {}", json["bin"]["arch"]);

r2p.close();

}

$ gem install r2pipe

require 'r2pipe'

puts 'r2pipe ruby api demo'

puts '===================='

r2p = R2Pipe.new '/bin/ls'

puts r2p.cmd 'pi 5'

puts r2p.cmd 'pij 1'

puts r2p.json(r2p.cmd 'pij 1')

puts r2p.cmd 'px 64'

r2p.quit