November 12th, 2024

Using QEMU-user emulation to reverse engineer binaries (2021)

QEMU's qemu-user enables program emulation across CPU architectures, facilitating reverse engineering with advanced tracing, gdb integration for remote debugging, and CPU spoofing to bypass detection by advanced programs.

Read original article

Using QEMU-user emulation to reverse engineer binaries (2021)

QEMU is a versatile software primarily recognized for full system emulation under Linux's KVM, but it also offers qemu-user, which allows for the emulation of individual programs across different CPU architectures. While its main application is to run programs designed for one architecture on another, it can also be utilized for reverse engineering. This is achieved by running a qemu-user emulator that targets the same architecture as the host, enabling debugging and tracing without detection by the program being analyzed. The emulator includes powerful tracing features that surpass traditional tools like strace, which can be detected by the programs they trace. Users can compile a sample program and run it with various tracing options to observe its behavior at different levels, including CPU registers and disassembly of instructions. Additionally, qemu-user supports integration with gdb for remote debugging, allowing users to set breakpoints and inspect program execution transparently. Although some advanced programs may check for specific CPU types, qemu-user can spoof CPU identities to mitigate this issue. Overall, qemu-user provides a robust set of tools for reverse engineering binaries, making it a valuable resource for developers and security researchers.

- QEMU's qemu-user allows emulation of individual programs across CPU architectures.

- It can be used for reverse engineering without detection by the analyzed program.

- The emulator offers advanced tracing features that surpass traditional tools.

- Integration with gdb enables remote debugging and inspection of program execution.

- CPU spoofing is possible to bypass checks by advanced programs.

Re-visiting VM/386 (2023)

The author shares experiences with VM/386, an emulation software from 1988. Running on 86box, it enables multitasking on an 80386 processor with graphical PC programs, despite limitations hindering broader success.

A bit more regarding UTM SE on the iPad

The author shares insights on using UTM SE on an M1 iPad Pro, noting limitations for local development but suitability for older systems or games. Comparisons with a-Shell and iSH are discussed.

KLEE Symbolic Execution Engine

KLEE is a symbolic virtual machine based on LLVM, enabling symbolic execution of bitcode with a POSIX/Linux emulation layer, allowing input replay on native and emulated environments for software testing.

Deterministic Replay of QEMU Emulation

QEMU version 9.0.94 introduces a record/replay feature for deterministic virtual machine execution, supporting multiple hardware platforms, snapshotting, automatic data recording, and reverse debugging capabilities using GDB commands.

FEX 2409 – benchmarks are upwards of 10% faster

FEX-2409 enhances FEX-Emu performance with over 10% speed improvements, optimizes processor flag handling, and features a redesigned FEXConfig tool for better usability. Users can update via Ubuntu PPA.

4 comments

By @pbrowne011 - 3 months

I had not considered using a VM instead of strace when a program can detect ptrace(2) being used - good idea.

> Normally when reverse engineering a program, it is common to use tracing programs like strace. These tracing programs are quite useful, but they suffer from a design flaw: they use ptrace(2) to accomplish the tracing, which can be detected by the program being traced.

One way to do this would be to call ptrace() from your program and check if it returns the error EPERM. From the man page:

       EPERM  The specified process cannot be traced.  This could be because the tracer has  insufficient  privileges
              (the  required  capability  is CAP_SYS_PTRACE); unprivileged processes cannot trace processes that they
              cannot send signals to or those running set-user-ID/set-group-ID programs, for obvious reasons.  Alter‐
              natively, the process may already be being traced, or (on kernels before 2.6.26) be init(1) (PID 1).

However, this is not the best solution, as if your system has a security policy already in place for ptrace() detection, your process might get detected and killed. Other methods from the calling process might involve timing mechanisms, breakpoint detection, or checking other factors in the process' environment. One problem with the workaround suggested in this post (running a process from qemu-user) is that if it is truly security hardened, it might rely on timing differences smaller than the speed of VM instruction execution.

As a user or sysadmin, one way to detect ptrace is to use Yama [1], a Linux kernel module that creates an entry in /proc/sys/kernel/yama/ptrace_scope to configure a user's desired level of ptrace protection, from 0 (normal - any process can call ptrace() on another process owned by the same user) to 3 (completely disabling ptrace).

[1] https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama....

By @pbrowne011 - 3 months

Prior thread (with comments): https://news.ycombinator.com/item?id=27046272