Building a reverse engineering lab on Linux

Before analysing anything remotely interesting, you want an environment that is (a) reproducible and (b) isolated, so a sample can’t touch anything you care about. Here’s the setup I use for reverse engineering and binary analysis. Nothing exotic — just a clean, contained baseline.

Note: Only analyse binaries you’re allowed to analyse — your own builds, intentionally vulnerable practice targets, or CTF challenges. Isolation protects your machine; it isn’t a licence to run other people’s malware.

1. An isolated VM

The lab lives in a virtual machine, never on the host. I use a Debian-based guest with networking set to host-only (or disabled entirely for untrusted samples), and I snapshot a clean state so I can roll back after every session.

# after a fresh install + tooling, take a baseline snapshot
# (VirtualBox example)
VBoxManage snapshot "re-lab" take "clean-baseline" --description "tools installed, no samples"

Roll back whenever you want to start fresh:

VBoxManage snapshot "re-lab" restore "clean-baseline"

2. Core toolkit

The static + dynamic analysis basics:

sudo apt update && sudo apt install -y \
  gdb \
  binutils \
  file \
  xxd \
  radare2 \
  ltrace \
  strace \
  patchelf

A quick tour of what each does:

Tool	Use
file	First look — what is this binary?
xxd	Raw hex dump for headers and strings
radare2	Disassembly, static analysis, patching
gdb	Dynamic analysis, breakpoints, memory
ltrace / strace	Library and syscall tracing

For a friendlier disassembler, add Ghidra (free, from the NSA) or the free version of Binary Ninja or IDA — but r2 and gdb will carry you a long way.

3. A first look at a binary

Say you have a challenge binary called crackme:

file crackme
# crackme: ELF 64-bit LSB pie executable, x86-64 ...

strings -n 6 crackme | less    # readable strings, often leaks hints

Then open it in radare2 and analyse:

r2 -A crackme

Inside r2, a few commands to get oriented:

afl        # list functions
s main     # seek to main
pdf        # print disassembly of the current function

From here it’s the usual loop: read the disassembly, find the comparison that decides success vs failure, and work backwards to what input satisfies it.

4. Cleaning up

When you’re done, roll the VM back to the clean snapshot. Nothing persists, nothing leaks. That’s the whole point.

---

That’s the baseline I start every RE session from. In a future post I’ll walk through actually solving a crackme end to end with this setup.