chsh -s /usr/bin/r2

Radare2's prompt is quite powerful and handy to use, but sometimes you need to interact with the filesystem or spawn system programs.. and spawning new shells or quitting r2 is not an option.

For those cases, the simplest solution would be to just type ! and then type the shell command you like. This prefix command will just escape to the shell and run the text you type as in the system shell.

Radare2 also implements pipes, like pif | wc -l to count the number of instructions in a function (careful, commands after the pipe are shell commands, not radare2 ones!). If you want to count the number of lines of a command you can also do it with the internal grep operator in r2 ~, using the '?' modifier like this: pif~?.

If you want to use the result of a command inside another one, just surround it with `, like `pi `?v 2 + 2`.

To run several commands in a row, you can separate them with a ;. Now you're wondering what to do when you actually need to use a ; in a command, like to do some ROP-gadget search. Simply double-quote the whole command: "/R/ pop e[abc]x;ret"

Sometimes, you're running radare2 in a shitty highy-restricted/complex environment, and you don't have a shell (for example, when you boot to radare2). This is why we have re-implemented some useful shell commands directly into radare2, like ls, pwd, cd, rm, mv, ... and also an internal grep!

You can grep on words pdf~exit to grep on exit, you can count number of line with it pif~?, to indent JSON like pij~{}, use the internal pager on the whole thing with pij~{}.. (yes, the internal pager is ..); but one of its most powerful feature is the ability to select by columns, with the bracket operator: iz~[1] to select only the first column, iz~1337[1] to select the first column of the matching results.

To manage your opened file, feel free to check the relevant documentation in oo?. The most useful commands being oo+ to reopen the file in read-write mode and ood to reopen it in debug mode.

To finish this blogpost, allow us to mention the fact that radare2 has its own webserver. While this might seems super-overkill, it's actually useful to debug embedded systems, for example, a watch of an iPhone. Simply launch the web server with =h port and connect to it with your web-browser; you can now debug your device within the web-interface, remotely! You can also use this one liner: r2 -qc=h /bin/ls.

In some cases, you'll probably be interested in exposing the filesystem of the device to the outer world by using the internal HTTP server. This is done with the '=h' command, but you'll need to tune some variables to share the rootfs instead of the r2 webui:

> e http.root=/
> e http.bind=0.0.0.0
> e http.port=9999
> =h

If you don't like the webui, you can always use the rap protocol with =: port, and connect to it by issuing o rap://9999. Both remote interfaces can be used from the commandline of r2 by using the r2web://, rap://, r2pipe:// and r2 -C connection methods.

Interview of ret2libc

Almost one month since our last article, time flees. This article is an interview of a new contributor, that greatly enhanced one of the most visually impressive feature of radare2, the one that our propaganda department contributors loves to show at conferences!

  • Who are you ?

Hi, I'm ret2libc, I was an IDA addicted and this is my 10th day that I don't use IDA.

  • Hi ret2libc

Just joking, I still use IDA, but I'd really love to switch in the future, when r2 will be good enough. I am a Computer Science student, I like security related stuff, RE, malwares and... CTFs!

  • Why contributing to radare2 ?

Just use IDA instead, like everyone else.

Well, there are just plenty of bugs to fix and it's really fun. r2 is not perfect (yet), but it's an opportunity to be involved in a very good project and full of anal nice people. Also, I was really annoyed by the fact that I have to switch to Windows or a Windows VM everytime I just want to analyze a binary, even a simple one.

Instead r2 works almost everywhere, I just need my terminal. It's free, it's cool and it can be a good enough tool to work with binaries from some CTF.

So, let's try it, but... wait, there's only plain disassembly here, where is my graph?? Ok, VV and, well, I've found what I wanted to improve ;)

  • You have fixed a big pile of bugs regarding graphs, that's pretty impressive. Do you have a strong background in programming/maths ?

Let's say I have a background in programming/maths. As I mentioned, I'm a Computer Science student.

  • Why the graph?

I think it's one of the fundamental feature a disassembler should have. It makes you understand at a glance what's going on in a program and many times it's the only thing I need from IDA.

  • What are you currently implementing ? Someone told me about colours in graphs.

I've just finished implementing an algorithm to have a better layout for the nodes of the ASCII-Art graph, so that you won't have anymore (at least, you shouldn't) overlapping nodes or nodes placed in really wrong positions. Don't expect IDA's graph, but it's already something ;)

Since, at the moment, you can only see one function in the ASCII-Art graph, currently I'm implementing a way to move between called functions and go back and forth between them, without having to leave the graph mode. Something like what you get in Visual Mode with [0-9] shortcuts (#2907).

For the colours in graph, I think you will have to wait a little bit. In the meantime, if you feel brave you can start to use 'VV!', but don't say I didn't warn you.

  • What is the plan for the next months ? Are you going to continue to work on r2 ?

Of course I will continue contributing to r2, in my spare time! I'm planning to focus on graph, as I've done lately. In particular I think you will see:

  • issue #2907 fixed: move between called functions with [0-9] keys
  • enhancement in the edges layout. They are a real mess at the moment and for a good enough graph it's one of the fundamental thing that has to be fixed.
  • mouse support for node selection
  • last, and also least :P, you will see colored disassembly in the graph, unless someone else want to implement it before me (you are welcome!!)
  • a lot of other cool stuff, but that's another story and everything else really depends on having a good and strong starting point.
  • What about, a GUI ?

What? GUI? Pff, we just have the terminal :)

Really, I'd really like to see a cool GUI for r2, but don't count on me.

  • Most hated/lover feature of r2 ?
  • Most hated feature: anal.hasnext set to true as default!
  • Most loved feature: ASCII-Art graph, of course ;)
  • Advices for new contributors and users ?

Contributors, just focus on something you'd like to be present in r2 and implement it, maintain it and add tests!!

Users, keep using IDA, unless you want to take the red pill and see how deep the rabbit-hole goes ;)

  • Last word ?

Maybe we will see r2 1.0 in the future! VVRRRRRRRRRRRRRRRRRRR

  • Screenshots ?

Graph example Example of graph

Disasm in graph Disassembly in graph, without colours (yet)

Update from the GSoC 2

As part of GSoC I (dkreuter) and sushant94 have been working the last three weeks on what should become the basis for a decompiler integrated with the radare2 reversing framework.

For now it's a standalone program written in Rust that can read the radare2 code format ESIL. The rough process involves generating control and data flow graphs in SSA form for the input, applying simplifications on that, similar to compilers, and picking appropriate constructs in a target language to represent the input. The result will be a more intuitive representaton of the analyzed program.

The task is hard even in theory, as a program that prints 4 could've been compiled from print(4) or print(2+2). There's no way to know. Right now however, we're just trying to get the first and simplest case (4→4) to work. But the insight, that the decompilation process is neccessarily a interpretation process, is what I try to consider in my designs.

The alternatives to Rust we considered were OCaml and C++. None of us has written Rust or OCaml before, but seemed like many C++ skills would be transferrable to Rust (at some cost of idiomaticness). The first two weeks were full of gotchas, but now I'm very comfortable with the language. The Rust IRC channel was very helpful in that regard.
Rust has plenty of cool features including a very expressive typesystem (X<U> extends Y<Z> + Q where Z extends X<U>, etc.), a checker that ensures there are no double frees, aliasing non-const pointers or dangling pointers (without garbage collector), tagged unions, a nice build system unlike C++ (Apparently the C++ modules proposal didn't make it for C++17), type checks for metaprogramming (C++ uses duck typing instead), nicey integrated documentation generation and testing and pattern matching.
In C++ terms, all references in Rust are const restrict * const and have move-semantics per default. It does make some tasks more tedious than normally. (eg. swap(&x[4], &x[5]) needs workarounds to compile) But I still think that these defaults will prevent more problems that they cause.

So while sushant94 has been working on parsing and representing the data coming from radare2 (with good results it seems), I've been working on the graph data structures, which turned out to be more complicated than anticipated.
Firstly, an SSA graph is doesn't only have nodes and edges, it also has one level of nesting of nodes (computations in basic-blocks) and it also has "edge-order" (A node representing subtraction needs to know which edge represents its first or second operand.) meaning that we couldn't just use a preexisting library (without adaptions). Also, the fact that Rust wants a statically determinable tree of ownership to exist clashes a bit with the requirements of a graph.
In the end we used an existing graph library for the upper level (the basic blocks) and manually manage the lower one with instruction lists in each block. Integers are used as "pointers" between nodes on both levels. Another challenge were the Phi nodes which (unlike other instructions) have a variable number of operands. They have as many operands as their containing basic block has incoming control flow edges. It leads to a lot of special casing, making the code messy. I hope to find time to revisit this later (after GSoC probably).

Once that's done we'll work on some more integration with radare2 and begin the first code that interacts with the graphs, like simplification (2+x+2 → 4+x) and dead code elimination (if(0){/*delete this*/}).