Reverse Engineering Tools: A Free Starter Kit for Your First Binary

Reverse engineering tools are the programs that let you read software without its source code: a disassembler and decompiler to turn machine code into something readable, a debugger to watch it run, and a couple of small utilities to tell you what kind of file you're holding. In November 2026 you can build a capable starter kit from four free tools, and this post sets them up and walks through a first session on a program you compile yourself.

Where Devirt fits in this kit: the free tools below take you a long way. They stop when a function has been virtualized by a protector like VMProtect or Themida. That is the part Devirt recovers, as an IDA database with a ledger of which functions were proven. You can start with a free assessment on a file you own or are authorized to analyze.

Practicing on your own build matters for two reasons. You know what the answer should be, so you can check every guess the tools make. And you're not taking apart someone else's software, which keeps the legal question simple.

What tools do you need to start reverse engineering?

The reverse engineering tools you need to start are four free programs: a disassembler and decompiler (Ghidra), a debugger (x64dbg on Windows), a file triage tool (Detect It Easy) and a hex editor (such as ImHex). With those four installed, a beginner can take apart a small program they compiled themselves, without paying for a license.

IDA Pro and Binary Ninja are commercial and very good, and both have free editions for non-commercial use. You don't need either for a first binary. A longer list of reverse engineering tools, sorted by the job each one does, covers what to add later.

Install the starter kit

Ghidra (disassembler and decompiler)

Ghidra is free. The NSA released it as open source in 2019, and its source code is on GitHub under the Apache 2.0 license. It disassembles and decompiles programs for many processor families, including x86, x64 and ARM. It runs on Java, so install a supported JDK first, then unzip the release and start it with the launcher script.

x64dbg (debugger)

x64dbg is an open-source debugger for Windows programs. The download includes x32dbg for 32-bit programs and x64dbg for 64-bit ones, so open whichever matches your binary. On Linux, GDB fills the same role.

Detect It Easy (file triage)

Detect It Easy, usually shortened to DIE, reads a file's headers and signatures and tells you what it is: the file format, the compiler that probably built it, and whether a packer or protector has been applied. It's the first thing to run on any binary you didn't build.

A hex editor

A hex editor shows the raw bytes. ImHex is free and open source, and HxD is a popular free choice on Windows. You won't live in it. It's where you check what the other tools claim.

Build a practice binary you're allowed to take apart

The best first target is a program you wrote, because you can check every conclusion against the source. Save this as practice.c:

#include <stdio.h> #include <string.h> static int checksum(const char *s) { int sum = 0; for (size_t i = 0; i < strlen(s); i++) sum = sum * 31 + s[i]; return sum; } int main(int argc, char **argv) { const char *name = argc > 1 ? argv[1] : "devirt"; printf("checksum(%s) = %d\n", name, checksum(name)); return 0; } 

Build it twice with GCC (on Windows, the MinGW-w64 toolchain): once with debug symbols and no optimization, once optimized and stripped, the way most shipped programs look.

gcc -O0 -g -o practice.exe practice.c gcc -O2 -s -o practice_stripped.exe practice.c 

Start with practice.exe, then repeat everything below on practice_stripped.exe. The difference between the two is most of what reverse engineering is about.

Pass 1: triage

Triage tells you what you're dealing with before you spend time on it. Open practice_stripped.exe in Detect It Easy. It should report a PE64 file built by a GCC/MinGW toolchain, with no packer. That "no packer" line is the important one: if DIE reported a packer or a protector, everything you see in Ghidra later would be the wrapper, not the program. A guide to Detect It Easy and PEiD results explains how to read that output.

Then open the same file in the hex editor. The first two bytes are MZ, and a little further in you'll find PE followed by two zero bytes, the start of the PE header. Scroll down and the string checksum(%s) = %d is sitting in plain sight. That's a quick sanity check that the file isn't encrypted.

Pass 2: read it in Ghidra

Ghidra turns the machine code into assembly and then into C-like pseudocode. Create a project, import practice.exe, and accept the auto-analysis when Ghidra offers it.

1. In the Symbol Tree, open Functions and select main. The debug build keeps the name, so the Decompiler window shows something close to your source.
2. Now import practice_stripped.exe. There's no main in the symbol list any more, only names like FUN_140001500.
3. Open Window → Defined Strings, find checksum(%s) = %d, and follow its cross-reference to the function that uses it. That's main.
4. Press L on the function and on its variables to rename them. At -O2, GCC will most likely have inlined checksum into main, so look for a loop inside main that walks the string and multiplies by 31 (Ghidra may show * 0x1f, or a shift and a subtraction). That loop is checksum.

That last step is the core skill, and it's why you build the stripped version too: the optimizer reshapes your code, and you learn to recognize it anyway. Ghidra hands you correct but anonymous code, and you supply the meaning. An AI decompiler can suggest names, but you still confirm them the way you just did.

Pass 3: watch it run in x64dbg

x64dbg shows what the code does at runtime, which settles anything the static view left unclear. Open practice_stripped.exe, then right-click in the CPU view and choose Search for → Current Module → String references. Double-click checksum(%s) = %d to land in main.

A few lines below the string reference is the call to printf. Set a breakpoint on that call with F2 and run with F9 (x64dbg pauses at the program's entry point first, so you may need to press it again). Windows x64 code passes the first arguments in RCX, RDX and R8, so when the breakpoint hits, R8 holds the checksum about to be printed. Step over the call with F8 and compare it with the console output. Then set an argument with File → Change Command Line, such as your own name, restart, and watch the value change. When the debugger, the decompiler and the source all agree, you've completed the loop that every bigger job repeats.

Where do AI tools fit?

AI tools fit on top of a reverse engineering toolchain, not in place of it. A language model can rename variables and explain decompiled code that Ghidra or IDA produced, but it reads the decompiler's output, so its answers are only as reliable as that output. Treat AI suggestions as hypotheses to check in the debugger, not as findings.

The next step up is connecting an agent to your tools. A Ghidra MCP or IDA MCP server lets an assistant query the open project instead of pasted snippets. It's worth trying once you can check its answers yourself.

When does the starter kit stop working?

The starter kit stops working on VM-protected code. Protectors such as VMProtect and Themida convert selected functions into bytecode for a private virtual machine, so Ghidra and x64dbg show the protector's interpreter loop instead of the original logic. Recovering those functions is a separate job called devirtualization.

You'll usually spot it in triage, because DIE names the protector. In Ghidra it shows up as one large function full of jumps between short handlers, with your strings nowhere near the code that uses them. Packing is different: a packed file unpacks itself in memory, and a dump gets the original code back. The difference between unpacking and devirtualization decides which of those jobs you're facing. Lighter tricks such as renamed symbols and encoded strings fall under general code obfuscation, and the starter kit still handles those.

Before opening a file you didn't build, Devirt's free browser check reads its file type and protection indicators on your own machine, without uploading it. When it reports a VM protector, you know the starter kit will show you the protector's interpreter, not the program.

Is it legal to reverse engineer software?

Reverse engineering software you wrote, or are authorized to analyze, is generally lawful. The legal limits usually come from license terms and copyright law: the EU Software Directive and the US DMCA, for example, both contain interoperability exceptions with conditions. This is general information, not legal advice. Practice on programs you compiled yourself, and keep anything you didn't write inside a virtual machine.

How to keep practicing with reverse engineering tools

Repeat the three passes on slightly bigger programs of your own: one that reads a file, one that opens a network socket, one built with a different compiler. Each new program teaches you a pattern you'll recognize in the next one. When a target turns out to be VM-protected and you're authorized to analyze it, that's the point where the free tools hand over to devirtualization.

Written by Devirt, an automated devirtualization service for authorized analysis of protected software.