"afbij" otput wrog json format

GhostFrankWu commented 4 weeks ago

Environment

radare2 5.9.1 32046 @ linux-x86-64
birth: git.5.9.0-163-gb9e47794e3 2024-05-10__18:31:14
commit: b9e47794e3c7287326c63bbbd0122d8ab363cbd0
options: gpl -O? cs:5 cl:2 make
Linux x86_64

Description

For x86, "afbi" returns multiple basic blocks. This will make "afbij" output wrong json format, example:

[0x08048736]> aaaa
[0x08048736]> afbij @ 0x804f41f
{"addr":134542360,"size":8,"jump":134542368,"opaddr":134542360,"inputs":1,"outputs":1,"ninstr":1,"instrs":[134542360],"traced":1}
{"addr":134542361,"size":7,"jump":134542368,"opaddr":134542361,"inputs":1,"outputs":1,"ninstr":1,"instrs":[134542361],"traced":1}

.text:0804F40E loc_804F40E:                            ; CODE XREF: sub_804F360+68↑j
.text:0804F40E                 cmp     large dword ptr gs:0Ch, 0
.text:0804F416                 jz      short loc_804F419
.text:0804F418                 lock
.text:0804F419
.text:0804F419 loc_804F419:                            ; CODE XREF: sub_804F360+B6↑j
.text:0804F419                 sub     ds:dword_80EC4C0, 1
.text:0804F420                 jz      short loc_804F42D
.text:0804F422                 lea     eax, dword_80EC4C0
.text:0804F428                 call    sub_806FE40
.text:0804F42D
.text:0804F42D loc_804F42D:                            ; CODE XREF: sub_804F360+C0↑j
.text:0804F42D                 or      [esp+15Ch+var_A4], 10000h
.text:0804F438                 sub     esp, 4
.text:0804F43B                 lea     edi, [esp+160h+var_128]

I'm not sure if this is expected behavior, but based on https://github.com/radareorg/radare2/issues/18284#issuecomment-792330115 , at lest result format of json is went wrong.

Test

I'm not sure if this is caused by the "afbij" or "lock" instruction form x86 arch, as in my environment, r2 actually seems unable to deassemble the code at that address.
I was unable to craft a simple binary to reproduce this problem, so here I provide my original binary program (a statically linked CTF challenge): 754392adc-radare2-issue.zip

trufae commented 3 weeks ago

This address is part of two basic blocks, i dont think any other tool except radare supports a single address to be covered by two basic blocks or a single basic block shared between two functions. And this is a design decision.

This address is not in the begining of any instruction in any basic block. the address is not listed in your disasm and its neither listed in the disasm of r2.

Yeah showing two json objects as output is not valid json, so it should be fixed

As you can see, the address is in the middle of two instructions listed as two separate basic blocks, so linear disassembly wont show it properly unless you set flags on each basic block and then use the bbmiddle option, use pdr or agfv

.afb*
e asm.bbmiddle=true

As you see r2 can disassemble the lock instruction properly, but that's an antidisassembly trick and needs to be treated properly to handle it.

trufae commented 3 weeks ago

So my proposal here is:

Make afbj return an array (may break some scripts i guess, but worth doing the change) fixed in https://github.com/radareorg/radare2/pull/22948

if you enable asm.bbmiddle, which should be set by default you should be able to see both instructions, the lock and the sub. so its the je that breaks the thing and the lock is actually never executed i think

radareorg / radare2