Radare2: radiff2 -g dumps raw disassembly in graph output

[Siguza]

Work environment

| Questions | Answers
|------------------------------------------------------|--------------------
| OS/arch/bits (mandatory) | macOS 10.12, x86_64h
| File format of the file you reverse (mandatory) | Mach-O
| Architecture/bits of the file (mandatory) | arm64
| r2 -v full output, not truncated (mandatory) | radare2 3.4.0-git 21471 @ darwin-x86-64 git.3.3.0-289-g110b5fb15 commit: 110b5fb15c00602550e5a38ee4896246daac0203 build: 2019-03-28__17:27:26

Steps to reproduce the behavior

These are my test files: kernels.zip
This is the command I'm running:

radiff2 -g 0xfffffff007558ca8,0xfffffff007554ff4 kernel_120 kernel_122 2>/dev/null

And these are the first 30 lines of output I get:

;-- OSUnserializeXML(charconst*,OSString**):
; CODE XREF from sym.OSUnserializeXML_charconst__unsignedlong_OSString (0xfffffff007558d44)
0xfffffff007557250      stp x28, x27, [sp, -0x60]!
0xfffffff007557254      stp x26, x25, [sp + var_10h]
0xfffffff007557258      stp x24, x23, [sp + var_20h]
0xfffffff00755725c      stp x22, x21, [sp + var_30h]
0xfffffff007557260      stp x20, x19, [sp + var_40h]
0xfffffff007557264      stp x29, x30, [sp + var_50h]
0xfffffff007557268      add x29, sp, 0x50
0xfffffff00755726c      sub sp, sp, 0xb20
0xfffffff007557270      mov x20, x1
0xfffffff007557274      mov x21, x0
0xfffffff007557278      add x22, sp, 0x2f8
0xfffffff00755727c      nop
0xfffffff007557280      nop
0xfffffff007557284      ldr x8, sym.___stack_chk_guard
0xfffffff007557288      str x8, [x22, 0x820]
0xfffffff00755728c      cbz x21, 0xfffffff007557364
     ldxr w8, [x26]
     add w8, w8, w1
     stxr w9, w8, [x26]
     cbnz w9, 0xfffffff00755364c
digraph code {
    graph [bgcolor=azure fontsize=8 fontname="Courier" splines="ortho"];
    node [fillcolor=gray style=filled shape=box];
    edge [arrowhead="normal"];
    "0xfffffff007557250" -> "0xfffffff007557364" [color="green"];
    "0xfffffff007557250" -> "0xfffffff007557290" [color="red"];
 "0xfffffff007557250" [fillcolor="orange",color="black", fontname="Courier", label="", URL="sym.OSUnserializeXML_charconst__unsignedlong_OSString/0xfffffff007557250"]
    "0xfffffff007557290" -> "0xfffffff007557364" [color="green"];

From line 23 onward, the output is valid DOT, but not only is there a big chunk of stray disassembly before it, but when I remove that part and look at the resulting graph, that same disassembled block is also missing.

[XVilka]

@deepakchethan can you please take a look at this one?

[deepakchethan]

Currently working on this :)
Can be reproduced with radiff2 -g main -m d /bin/ls /bin/cat

We also get warnings when we do radiff2 -g main -m d /bin/cat /bin/ls. Should we avoid displaying them when we are printing in dot ?

[deepakchethan]

This is runPendingAnal issue. For the first time, during the first run it prints the disassembly

[radare]

@deepakchethan any updates on this?

[radare]

ping @deepakchethan

[kuqadk3]

Hi, I am looking into this problem as suggested by @XVilka . It would be great if someone could give me some insights. What's the problem? what's the expected behavior?

Btw, I couldn't find runPendingAnal function, is it a typo mistake @deepakchethan ?
(okay, runPendingAnal is now run_pending_anal)
Thanks you guys ;)

[Siguza]

The expected output is a a graph file in the DOT language, highlighting the differences between the two input files/specified addresses.
The actual output with current radare (radare2 4.3.0-git 24615 @ darwin-x86-64 git.4.2.1-194-gf74dd3144, commit: f74dd31440fe90491c51420abc22edfb4d079958 build: 2020-03-03__04:51:32) and the provided files & command, is some disassembly followed by a monster ASCII graph.

[kuqadk3]

So basically it's something wrong that made the code output a DOT graph in the middle of the function?

[radare]

its just calling the right apis i think, everything needed is implemented

On 3 Mar 2020, at 05:01, Siguza [e-mail] wrote:

The expected output is a a graph file in the DOT language https://en.wikipedia.org/wiki/DOT_(graph_description_language), highlighting the differences between the two input files/specified addresses.
The actual output with current radare (radare2 4.3.0-git 24615 @ darwin-x86-64 git.4.2.1-194-gf74dd3144, commit: f74dd31440fe90491c51420abc22edfb4d079958 build: 2020-03-03__04:51:32) and the provided files & command, is some disassembly followed by a monster ASCII graph.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/radareorg/radare2/issues/13540?email_source=notifications&email_token=AAG75FV2ZDKDKNW3AYIVJYTRFR6IJA5CNFSM4HCCZ2D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENR75TQ#issuecomment-593755854, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG75FQLHFE5VQQW7T6JGDTRFR6IJANCNFSM4HCCZ2DQ.

[deepakchethan]

The method name has been changed. it's run_pending_anal now :)

Hi, I am looking into this problem as suggested by @XVilka . It would be great if someone could give me some insights. What's the problem? what's the expected behavior?

Btw, I couldn't find runPendingAnal function, is it a typo mistake @deepakchethan ?
(okay, runPendingAnal is now run_pending_anal)
Thanks you guys ;)

[kuqadk3]

Seems like it was solved in recent PR (!?) since I could not find run_pending_anal anymore and could not reproduce the error. If so, I would love to know which PR, thanks!

[Siguza]

Yep, with -m d I get the expected output now.
I'll close this then. I don't know which commit solved it, but thanks a lot either way. :)