Debugging in QEMU

Running Firmware in QEMU¶

Use qemu-system-<arch> to emulate the target hardware. For ARM-based IoT devices:

qemu-system-arm -M versatilepb -kernel firmware.bin -nographic

- -M versatilepb: Emulates a generic ARM development board.
- -kernel: Loads the firmware binary as the kernel (specifically for Linux kernels). For non-ELF firmware formats (e.g., flat binaries), use -fda firmware.bin instead.
- -nographic: Redirects output to the terminal (useful for debugging).

Note: Adjust the machine type (-M) based on the target device's architecture (e.g., raspi3 for Raspberry Pi).

Debugging with GDB¶

Attach GDB to the QEMU process for low-level analysis:

Start QEMU with GDB server support:

qemu-system-arm -M versatilepb -kernel firmware.bin -s -S

-s: Enables GDB server on TCP port 1234.
-S: Pauses execution until a debugger connects.
Connect with GDB:
```
gdb-multiarch firmware.elf
(gdb) target remote :123x4
(gdb) break main
(gdb) continue
```
Replace firmware.elf with a disassembled firmware binary (use objdump or radare2 to generate).

Example: Disassemble firmware with objdump (requires ELF format):

objdump -D firmware.bin > firmware.dis

For non-ELF firmware, use tools like binwalk or radare2 to extract or analyze the binary first.

Advanced Debugging Techniques¶

Hardware Breakpoints: Use watch or hwbreak in GDB to monitor memory addresses.
Memory Analysis: Inspect register values with info registers and memory regions with x/10x 0x<address>.

System Call Tracing: Use QEMU's -d flag to log system calls:

qemu-system-arm -d in_asm,out_asm -M versatilepb -kernel firmware.bin

Key takeaways¶

QEMU enables firmware analysis by emulating target hardware without physical devices.
GDB integration allows precise control over execution and memory inspection.
Firmware disassembly and system call tracing are critical for understanding behavior.
Always validate compatibility between firmware and QEMU machine types.
Combine QEMU with tools like radare2 or objdump for deeper reverse engineering.