Radare2: `aac` crashes on some binaries

[resilar]

It seems that on some binaries aac takes very long time (~40secs) and then crashes. I know for sure that radare2 used to work for these binaries in the past, but I am too lazy to bisect the bug. Example:

[def@arch vbox]% gdb --args r2 HEROES3.EXE  # dl: http://huumeet.info/~def/r2/HEROES3.EXE
Reading symbols from r2...done.
(gdb) r
Starting program: /usr/local/bin/r2 HEROES3.EXE
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
 -- Experts agree, security holes suck, and we fixed some of them!
[0x0061a2b4]> aac
*** Error in '/usr/local/bin/r2': free(): invalid pointer: 0x00005555594019ef ***
...
Program received signal SIGABRT, Aborted.
0x00007ffff4264295 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff4264295 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff42656da in abort () from /usr/lib/libc.so.6
#2  0x00007ffff429fd50 in __libc_message () from /usr/lib/libc.so.6
#3  0x00007ffff42a5546 in malloc_printerr () from /usr/lib/libc.so.6
#4  0x00007ffff42a5d1e in _int_free () from /usr/lib/libc.so.6
#5  0x00007ffff462dfa5 in sdb_fmt_free (stru=0x7fffffffd2a0, fmt=0x7ffff6644cf5 "zdz") at fmt.c:131
#6  0x00007ffff64b9c16 in r_anal_var_get (a=0x5555557db7c0, addr=5154592, kind=98 'b', scope=1, delta=8) at var.c:287
#7  0x00007ffff64b1904 in get_used_var (anal=0x5555557db7c0, op=0x7fffffffd3b0) at op.c:73
#8  0x00007ffff64b1a85 in r_anal_op (anal=0x5555557db7c0, op=0x7fffffffd3b0, addr=5154638, data=0x555555c9b7a1 "\213U\bPQR\213Ήu\360\350\342;\021", len=399) at op.c:100
#9  0x00007ffff7afd1b2 in cmd_anal_calls (core=0x55555575ba00 <r>, input=0x555555c5ffd3 "") at cmd_anal.c:2906
#10 0x00007ffff7b0160d in cmd_anal_all (core=0x55555575ba00 <r>, input=0x555555c5ffd2 "c") at cmd_anal.c:4143
#11 0x00007ffff7b0266d in cmd_anal (data=0x55555575ba00 <r>, input=0x555555c5ffd1 "ac") at cmd_anal.c:4462
#12 0x00007ffff7b5f019 in r_cmd_call (cmd=0x55555580f240, input=0x555555c5ffd0 "aac") at cmd_api.c:210
#13 0x00007ffff7b2b748 in r_core_cmd_subst_i (core=0x55555575ba00 <r>, cmd=0x555555c5ffd0 "aac", colon=0x0) at cmd.c:1853
#14 0x00007ffff7b2948c in r_core_cmd_subst (core=0x55555575ba00 <r>, cmd=0x555555c5ffd0 "aac") at cmd.c:1249
#15 0x00007ffff7b2ccc6 in r_core_cmd (core=0x55555575ba00 <r>, cstr=0x5555558493a0 "aac", log=1) at cmd.c:2260
#16 0x00007ffff7ad79b4 in r_core_prompt_exec (r=0x55555575ba00 <r>) at core.c:1624
#17 0x00005555555598b8 in main (argc=2, argv=0x7fffffffe8c8, envp=0x7fffffffe8e0) at radare2.c:943
(gdb) f 5
#5  0x00007ffff462dfa5 in sdb_fmt_free (stru=0x7fffffffd2a0, fmt=0x7ffff6644cf5 "zdz") at fmt.c:131
131         case 's': free ((void*)*((char**)(stru+len))); break;
(gdb) p stru
$1 = (void *) 0x7fffffffd2a0
(gdb) p len
$2 = 8

[resilar]

Moreover, aac for this binary also takes very long time but eventually finishes. However, it renders disassembly view of visual mode almost unusable by causing an input lag of 1-2 secs after every keypress (e.g., j and k) in additional to occasional freezes requiring the r2 process to be killed externally.

[alvarofe]

mm I am seeing in sdb_fmt_free in the fmt parameter the following zdz this was change around 2014 in the commit a6b34c4d539422324da5d8e3e848da66e189ff4f for czdz so it seems you are using an old version of r2 because i don't get any segfault so far, though i agree is slow as hell.

[alvarofe]

It takes time and the scroll is slow is because of binary is huge and r2 does not handle that very well yet. We are aware of that.

[resilar]

@alvarofe scrolling in visual mode works perfectly before running the aac command, so the binary size is not the issue I think (in my experience, r2 has always handled 6MB files quite easily). I am also running the latest radare2. Just to make sure, I made a fresh clone from radare/radare2.git and I am still getting the same crash:

[def@arch vbox]% r2 -version   
radare2 0.10.4-git 11822 @ linux-x86-64 git.0.10.3-403-g2f5ead1
commit: 2f5ead1efd481af5864acad26fc7307d2555e8f3 build: 2016-07-04
[def@arch vbox]% gdb --args r2 HEROES3.EXE 
Reading symbols from r2...done.
(gdb) r
Starting program: /usr/local/bin/r2 HEROES3.EXE
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
 -- Enable asm.trace to see the tracing information inside the disassembly
[0x0061a2b4]> aac
*** Error in '/usr/local/bin/r2': free(): invalid pointer: 0x000055555928942f ***

[resilar]

These look like related issues: #5221, #5241, #5235. In #5221, @radare and @ret2libc talk about some recent changes in the way how functions are represented (as ranges vs. lists of ranges using interval trees and skip lists), which may explain the problems with aac.

[radare]

ping @alvarofe ?

[alvarofe]

About the slowness with the analysis for some reason happen i have not researched further why sorry. If you know where to look just define function by function when needed with af this refers to http://radare.today/posts/analysis-by-default/ is not the solution by just workaround. Regarding the crash i still don't get why you get in the backtrace zdz in sdb_fmt_free when you can see a #define SDB_VARTYPE_FMT "czdz" in the source code. Do you have any config variable or maybe is linking against an old version of r2 that was installed before?

[resilar]

I do not think that I have mismatching versions because r2 --version would report that. I tried on another computer (no previous r2 installed) and now I get SEGFAULT here:

[kosh tmp]% gdb -quiet --args r2 HEROES3.EXE
Reading symbols from r2...done.
(gdb) r
Starting program: /m/home/home4/42/hirvolt1/unix/radare2/root/bin/r2 HEROES3.EXE
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
 -- Change your fortune types with 'e cfg.fortunetype = fun,tips,nsfw' in your ~/.radare2rc
[0x0061a2b4]> aac

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x00007ffff424571e in __GI___strdup (s=0x0) at strdup.c:41
#2  0x00007ffff64935bc in r_anal_var_get (a=0x5555557dbe80, addr=5154592, 
    kind=98 'b', scope=1, delta=8) at var.c:283
#3  0x00007ffff648aded in get_used_var (anal=0x5555557dbe80, 
    op=0x7fffffffcef0) at op.c:73
#4  0x00007ffff648af6e in r_anal_op (anal=0x5555557dbe80, 
    op=0x7fffffffcef0, addr=5154638, 
    data=0x5555559cec51 "\213U\bPQR\213Ήu\360\350\342;\021", len=399)
    at op.c:100
#5  0x00007ffff7af363f in cmd_anal_calls (core=0x55555575c5c0 <r>, 
    input=0x5555558490f3 "") at cmd_anal.c:2906
#6  0x00007ffff7af7fad in cmd_anal_all (core=0x55555575c5c0 <r>, 
    input=0x5555558490f2 "c") at cmd_anal.c:4143
#7  0x00007ffff7af912e in cmd_anal (data=0x55555575c5c0 <r>, 
    input=0x5555558490f1 "ac") at cmd_anal.c:4462
#8  0x00007ffff7b5b8f3 in r_cmd_call (cmd=0x55555580eed0, 
    input=0x5555558490f0 "aac") at cmd_api.c:210
#9  0x00007ffff7b25b0f in r_core_cmd_subst_i (core=0x55555575c5c0 <r>, 
    cmd=0x5555558490f0 "aac", colon=0x0) at cmd.c:1853
#10 0x00007ffff7b234a4 in r_core_cmd_subst (core=0x55555575c5c0 <r>, 
    cmd=0x5555558490f0 "aac") at cmd.c:1249
#11 0x00007ffff7b2723c in r_core_cmd (core=0x55555575c5c0 <r>, 
    cstr=0x555555849390 "aac", log=1) at cmd.c:2260
#12 0x00007ffff7acb309 in r_core_prompt_exec (r=0x55555575c5c0 <r>)
    at core.c:1624
#13 0x0000555555559f1e in main (argc=2, argv=0x7fffffffe408, 
    envp=0x7fffffffe420) at radare2.c:943
(gdb) f 2
#2  0x00007ffff64935bc in r_anal_var_get (a=0x5555557dbe80, addr=5154592, 
    kind=98 'b', scope=1, delta=8) at var.c:283
283     av->name = strdup (vt.name);
(gdb) p vt.name
$1 = 0x0

[resilar]

Ok I took some time to bisect the bug(s). The SIGABRT was introduced by this commit: b31dd80. The SIGSEGV is more recent, introduced by SDB update a745a9a. Finally, aac became very slow somewhere between the commits 632dccc and 608b79d (also fucking up the visual disassembly mode) - I'll look into this later.

[radare]

Thats a simple null deref

On 08 Jul 2016, at 13:38, resilar [email protected] wrote:

I do not think that I have mismatching versions because r2 --version would report that. I tried on another computer (no previous r2 installed) and now I get SEGFAULT here:

[kosh tmp]% gdb -quiet --args r2 HEROES3.EXE
Reading symbols from r2...done.
(gdb) r
Starting program: /m/home/home4/42/hirvolt1/unix/radare2/root/bin/r2 HEROES3.EXE
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
-- Change your fortune types with 'e cfg.fortunetype = fun,tips,nsfw' in your ~/.radare2rc
[0x0061a2b4]> aac

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt

0 strlen () at ../sysdeps/x86_64/strlen.S:106

1 0x00007ffff424571e in __GI___strdup (s=0x0) at strdup.c:41

2 0x00007ffff64935bc in r_anal_var_get (a=0x5555557dbe80, addr=5154592,

kind=98 'b', scope=1, delta=8) at var.c:283

3 0x00007ffff648aded in get_used_var (anal=0x5555557dbe80,

op=0x7fffffffcef0) at op.c:73

4 0x00007ffff648af6e in r_anal_op (anal=0x5555557dbe80,

op=0x7fffffffcef0, addr=5154638, 
data=0x5555559cec51 "\213U\bPQR\213Ήu\360\350\342;\021", len=399)
at op.c:100

5 0x00007ffff7af363f in cmd_anal_calls (core=0x55555575c5c0 ,

input=0x5555558490f3 "") at cmd_anal.c:2906

6 0x00007ffff7af7fad in cmd_anal_all (core=0x55555575c5c0 ,

input=0x5555558490f2 "c") at cmd_anal.c:4143

7 0x00007ffff7af912e in cmd_anal (data=0x55555575c5c0 ,

input=0x5555558490f1 "ac") at cmd_anal.c:4462

8 0x00007ffff7b5b8f3 in r_cmd_call (cmd=0x55555580eed0,

input=0x5555558490f0 "aac") at cmd_api.c:210

9 0x00007ffff7b25b0f in r_core_cmd_subst_i (core=0x55555575c5c0 ,

cmd=0x5555558490f0 "aac", colon=0x0) at cmd.c:1853

10 0x00007ffff7b234a4 in r_core_cmd_subst (core=0x55555575c5c0 ,

cmd=0x5555558490f0 "aac") at cmd.c:1249

11 0x00007ffff7b2723c in r_core_cmd (core=0x55555575c5c0 ,

cstr=0x555555849390 "aac", log=1) at cmd.c:2260

12 0x00007ffff7acb309 in r_core_prompt_exec (r=0x55555575c5c0 )

at core.c:1624

13 0x0000555555559f1e in main (argc=2, argv=0x7fffffffe408,

envp=0x7fffffffe420) at radare2.c:943

(gdb) f 2

2 0x00007ffff64935bc in r_anal_var_get (a=0x5555557dbe80, addr=5154592,

kind=98 'b', scope=1, delta=8) at var.c:283

283 av->name = strdup (vt.name);
(gdb) p vt.name
$1 = 0x0
Maybe this is easier to debug... I'll bisect the bug when I have time (probably next week).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.