1. Home
  2. /
  3. Lehrstuhl für Systemsicherheit
  4. /
  5. Lehre
  6. /
  7. Abschlussarbeiten
  8. /
  9. Fuzzing, Binary Rewriting, System...

Fuzzing, Binary Rewriting, System Programming, Emulation

Research Overview

In my research I mainly focus on improving modern fuzzing techniques with the goal of overcoming limitations and unlocking new types of applications such that they can be tested by automated security analysis tools.

Nils Bars

Master's Thesis: Uncovering Fuzzing Roadblocks in Widely Used Software

Fuzzing is a widely used, automated technique to uncover bugs in modern software. For fuzzing to be effective, it is paramount to generate inputs that cover as much code (paths) as possible in the target program. To this end, many techniques, such as symbolic execution or taint tracking, were suggested by previous research. While these techniques target specific data constructs such as checksums or magic values, it remains unclear whether other types of common roadblocks are blocking the fuzzers‘ progress.
In this thesis, you are asked to thoroughly analyze common obstacles blocking the AFL++ fuzzer during fuzzing of widely used software. To this end, you are provided with fuzzing results amounting to eight CPU years, but you will need to set up your own fuzzing experiments as well. 


  • Preferably Python or Rust
  • Development of high performance multithreaded code for data processing
  • Previous experience or interest in using tools for tracing binaries during execution

Master's Thesis: Improving Binary Fuzzing through Trace Re-Translation

Modern fuzzers, such as AFL++, rely on binary re-translators such as QEMU for fuzzing targets that are only available as a binary. Such tools allow augmenting binaries during execution, mostly to inject custom code that implements efficient feedback mechanisms such as code coverage. Unfortunately, these capabilities come at the cost of performance degeneration since translating the target binary to an intermediate representation (IR), modifying this IR, and then translating it back, is not free. However, as opposed to the common use case of emulators, fuzzers consecutively & rapidly execute the targets while applying (generally) relatively small modifications to the input of the target. Consequently, in many cases, the same code path is exercised during execution. This insight allows us to focus on such single, hot paths.
In this thesis, your task is to implement a fuzzing-specific QEMU (user mode) optimization that exploits the abovementioned observation.


  • Low level concepts, JIT, C and x86-64 Assembly
  • Preferably Python or Rust
  • Development of high performance code
  • Previous experience or interest in using tools for tracing binaries during execution.

Master's Thesis: Hypervisor-based Cheats

Cheating has been an integral part of gaming since its first days. While back then, it was limited to single-player games, nowadays, it can even cause economic damage if used in contests that award money. While professional tournaments provide hardware to the participants in a controlled environment, gamers can participate remotely in competitions with relatively low payouts. Game developers try to counter cheating with so-called anti-cheat engines, such as VAC, PunkBuster, or BattlEye. However, these anti-cheat engines focus mainly on cheats running in user space or kernel space, but it is unknown whether they reliably detect hypervisor-based cheats or even attempt doing so.
In this thesis, you will develop a cheat that runs inside a virtual machine monitor (VMM) and can apply arbitrary modifications to the virtualized OS. Furthermore, you are asked to answer several research questions such as:
  • Do modern games employ any kind of countermeasures to avoid the execution inside a VM?
  • Can such a cheat be implemented for a modern multiplayer game?
  • What methods can detect such cheats or the presence of a VMM?
  • In what ways can a VMM-based cheat be used to gain an advantage?


  • Low level concepts, Paging, C and x86-64 Assembly
  • Preferably Python or Rust
  • Working IOMMU setup with GPU pass through and some games to test it
  •  Preferably experience with QEMU system emulation