Reply to the PEDA vs r2 blogpost

In this post i’ll try to address some of the examples shown in this blog post.

I’ll not comment all the sections, just the ones that missed some information or there were better ways to do it. So let’s begin!

Showing binary headers can be done with rabin2 -H or the iH command inside r2. You can surely use r2 -nn if you want to have all the flags pointing at each field of each struct inside the binary headers but depending on your needs iH should be good.

Well, r2 could do better at this, but argument and variable analysis is already implemented. Those are accessible with the afv command after running af to analyze the given function. After that you can display the telescoped values using the following line

> .afv*;pxr $w@@fcnvar*

But if you want to see the real formatted value of the variable using the type information you may want do use afvd like this:

> .afvd local_20h

I will now implement better command to manage local variables as well as global ones using afv subcommands without the need to pipe multiple commands to achieve the thing and enable json output as well as human formatting. Feel free to open issues adding more suggestions to improve the support for local vars and arguments analysis.

That’s the wrong way to use rarun2 from r2. Because that will basically debug rarun2 instead of ls. The -R flag in r2 allows to pass rarun2 profile directives to the debugger backend in the io plugin.

r2 -R aslr=false -d ls

Nothing wrong here, but there are tons of options in “e search.” to check out. Like for example only look for aligned hits, or specify the boundaries of the search.

e search.in=dbg.maps.exec

In addition the @ operator have some nice search modifiers like @/ and @@/. Those are used to run a command in a specific search hit or all the hits.

For example, this line replaces all 0x90 with 0x77

> wx 77 @@/x 90

Tracing in r2 works in debugger mode and it’s slowly improving with esil. Sadly this issue got forgotten in time and it hasnt been addressed yet. But you can do that and it works:

> e dbg.trace=true
> ds 10 # perform 10 steps
> dtd # show linear disasm of those 10 traced instructions

There are several more options and festures for tracing code, you can trace write operations thanks to the esil assisted debugging, show how many times a specific instruction has been executed, and probably the most important thing, you can do backstep and honor breakpoints with back-continue on any platform.

The tracing capabilities and commands are being reworked a bit recently but there’s much more stuff to improve, so feel free to hang on #radare and propose your changes/commands with a PR.

The reason why this expression doesn’t works is because @rsp refers to the rsp flag, there’s no reason to sync all regs into flags on every bphit. So the recommended way to express this would be:

pxr@r:SP

The reason why SP is written in uppercase is because the r: modifier of @ will resolve that using the r_reg api and SP is an alias register name that works for all architectures, so you don’t have to care about rsp, sp, esp or so

It is also handy to put multiline scripts into separate files and just run

> dbc main . Script.r2

The problem here is that the -d is opening the binary for debugging. In this io backend, the write permissions are granted already so its not necessary to use -w. Also, bear in mind that when you are patching the binary in memory when debugging, those changes will not be applied to the disk file.

It will be possible to track all the write operations and generate a patch script to run like it’s done with the wc command when io.cache is set. But this is something to be done and will be done probably after merging the SIOL branch to avoid more merge conflicts.

Also, is good to notice that the w command have wa and wao subcommands that allows to patch instructions or pseudo instructions

wa nop @ main

Those patterns can be also generated with ragg2. So just type this

>!ragg2 -P 100

In addition. The wopD command have a * modifier which will print the pattern in hexpairs prefixed with “wx”. So you can use that to view the pattern and prefix that command with a dot to run that.

> .wopD* 100

So this was a quick post trying to explain in more detail the capabilities of r2, trying to find better ways to do things is always fun, hope you enjoyed this blogpost and learned some new hints that makes your r2 sessions more pleasant.

— pancake