Reverse engineering lab: reading programs with gdb, radare2, strace and ltrace on one VM

This lab teaches how to read a program that has no source code. Each student gets an Ubuntu VM with a compiler, the debugger gdb, the disassembler radare2, binutils, strace and ltrace, and five small programs written for the lab, each of which hides a key. Students find the keys by looking at the programs, as a defender or a student of compilers would, and write them in a file.

It is reading and understanding only, on programs the lab compiled itself. Nothing is installed on the student’s computer, and nothing here teaches malware, breaking the licence of real software, key generators for it, hiding a program from a debugger, exploits, or looking at any program that is not the lab’s own.

What students learn

A ladder of five programs, each read with a different tool. The first keeps its password in the open, which strings and objdump or radare2 show without running it. The second builds its password while it runs, so students stop it in gdb at the string comparison and read the answer out of memory. The third asks for a number and tests it with a few steps of arithmetic, which students read in the disassembly and work backwards. The fourth joins two halves of a key, which ltrace shows in a library call. The fifth looks for a file whose name holds the key, which strace shows in a system call.

Behind it is the lesson a defender needs: whatever a program must know in order to work, a reader can find, so a secret kept in a program is not a secret.

Keys that are different on every copy

The lab’s repository is public, so no key is in it. When a student’s VM first starts, the setup makes new random keys, stores them in a folder that only the administrator can enter, builds the programs with them and deletes the sources. The setup never prints a key. A student’s answers are checked against their own copy’s keys, so a classmate’s answers, the README and the lab’s files give nothing away. A student who uses sudo on their own machine could read the stored keys: the lab trusts a student with their own machine, and the keys are for learning, not for secrecy against the person who owns the VM.

Run it in your browser

VM labs are set as a lab task in a module, and the sample is on the lab’s page. The machine is small: one CPU, 1 GB of memory and 10 GB of disk. The tools together use well under a tenth of that memory.

  1. Add the lab. In a module you teach, add a task and choose the Ubuntu VM lab card. The page shows a short description of the machine instead of a compose file.
  2. Start from the sample. The page offers ready-made labs to start from. Choose Reverse engineering. Using a sample replaces the text, and Undo brings yours back.
  3. Publish and start your own copy. Publish, then Start. The lab’s own setup script installs the compiler, gdb, radare2, strace and ltrace from Ubuntu’s archive, makes new random keys, builds the programs with them and writes the README, the first time the VM starts, in a few minutes.
  4. Open the terminal. Open its terminal and read README.md in the home folder: it says what to do and gives none of the answers.

A basic lesson on this lab

Reverse Engineering Basics is a small lesson worked in this lab, which is an Ubuntu VM. It has a hook, an I can outcome, the one rule, key words, a starter, a check after each idea, a common mistake and an exit check, and each step has a Run button that types its command into the machine’s terminal. A student looks at a harmless program with file, strings, objdump, radare2, gdb, ltrace and strace.

The lesson looks around and leaves the five programs with keys, which are the lab’s own task, to the student, so it hands out no answers.

How it is marked

The lab has a check. It runs on a copy of the saved machine after a fresh start and reads the file answers.txt in the student’s home folder. Each of the five keys must be the key made for that student’s copy of that program, so a guess, an empty line, another copy’s key or a key put against the wrong program does not pass. The check also tries every program with its own key, so a program that was changed is noticed. The first line of what the check printed says which program is wrong.

  1. Hand it out. Assign the lab like any task, with a due date if you want one. Each student gets a VM of their own, kept between sessions, with keys of their own.
  2. Run the check. On a student’s row in the class list, press Run the check. It starts a copy of their saved machine that is not saved back, runs the lab’s check script as root and shows whether it passed, what it printed and when. The student is not told the result.
  3. Mark it. Read the first line of what the check printed: it names the first program whose key is missing or not the key of that copy. Send the work back with a reason if it needs more.

The definition on GitHub

The file is the whole lab definition, the same text the platform runs: size, setup script, the five programs’ sources, README and check. Copy it and change the programs or the keys to make a longer lab.

Try this lab, and what it costs

A free personal account can work through the basic lessons in this lab, with enough free credit each month to follow most lessons and no card. For a class, a school or college has its first 365 days free for up to 50 students, then pays per student a year, with every lab included and staff free.

Questions people ask

Does the lab need a licence or special software?
No. The compiler, gdb, radare2, binutils, strace and ltrace are open source and come from Ubuntu’s archive when the student’s VM starts. Nothing of them is distributed by us.
Is this teaching people to break into software?
No. The programs are the lab’s own toys and each one is read to understand how a program works, which is what a defender, a developer without the source and a student of compilers all need. The lab never teaches malware, breaking the licence of real software, key generators, hiding a program from a debugger, exploits, or looking at any program that is not its own, and a student’s copy cannot reach the internet to fetch one.
Can students harm anything?
Only their own copy. The programs run as the student and the VM reaches Ubuntu’s archive and nothing else on the free tier. The programs cannot be broken by reading them.
Was the lab tested in a real student VM?
The setup, the lesson’s commands, the check and every way of faking it were run in a real Ubuntu 26.04 container, and each of the five keys was found with the tool the lab means, as a user with no administrator rights. A booted student VM, with the machine’s own kernel, is worth one try before a class.