radareorg / radare2

UNIX-like reverse engineering framework and command-line toolset
https://www.radare.org/
GNU Lesser General Public License v3.0
20.68k stars 3k forks source link

syscall resolving doesnt work in debug mode #18691

Open michaelortmann opened 3 years ago

michaelortmann commented 3 years ago

Environment

Thu May 13 09:11:15 PM CEST 2021
radare2 5.2.1 0 @ linux-x86-64 git.5.2.1
commit: unknown build: 2021-04-26__23:00:17
Linux x86_64

Description

I expect radare2 to resolve syscalls even in debug mode.

Test

  1. Create a simplified example binary to analyze:
$ cat hello.asm 
          global    _start

          section   .text
_start:   mov       rax, 1                  ; system call for write
          mov       rdi, 1                  ; file handle 1 is stdout
          mov       rsi, message            ; address of string to output
          mov       rdx, 13                 ; number of bytes
          syscall                           ; invoke operating system to do the write
          mov       rax, 60                 ; system call for exit
          xor       rdi, rdi                ; exit code 0
          syscall                           ; invoke operating system to exit

          section   .data
message:  db        "Hello, World", 10      ; note the newline at the end
$ nasm -felf64 hello.asm && ld hello.o && ./a.out
Hello, World
  1. Let radare2 resolve the syscalls of this a.out in static analysis mode:
$ r2 -A a.out
[...]
[0x00401000]> e asm.emu=1
[0x00401000]> pdf
[...]
│           0x00401019      0f05           syscall                     ; 1 = write (1, "Hello, World...................................................", 13)
[...]
└           0x00401023      0f05           syscall                     ; 60 = exit (0)

Good, this is what i expected.

  1. Let radare2 resolve the syscalls of this a.out in debug mode:
[0x00401000]> ood
[...]
[0x00401000]> pdf
[...]
│           0x00401019      0f05           syscall                     ; 59 = execve ("...............................................................", "...............................................................", "...............................................................")
[...]
└           0x00401023      0f05           syscall                     ; 59 = execve ("...............................................................", "...............................................................", "...............................................................")

Bad, this execve for any syscall looks off.

  1. Lets run it:
[0x00401000]> db 0x00401019
[0x00401000]> dc
hit breakpoint at: 0x401019
[0x00401019]> pdf
[...]
│           0x00401019 b    0f05           syscall                     ; -1 = unknown ()
[...]
└           0x00401023      0f05           syscall                     ; -1 = unknown ()

Bad, this -1 for any syscall looks off.

trufae commented 3 years ago

This is probably caused by the abuse of RAnal->esil instance, the pd loop may have its own instance so it doesnt affect the debugging session which in some cases its tied to native reg and non-cached io. Should be easy to fix but requires some refactoring in disasm.c

trufae commented 3 years ago

Screenshot 2021-07-30 at 12 37 18