GsoC 2025 Project Idea List

[rmalmain]

GSoC 2025 Project Idea List

Here is our proposal list for GSoC 2025.

Proposal 1: Tool for Automated generic/bounds simplification

Create a (general, not LibAFL-specific) rust tool to simplify/minimze bounds

Description

As commented by many users and maintainers of LibAFL, our codebase is absolutely full of complicated generics. We use these to allow for structured and statically-checked compatibility between various components provided in our codebase, and is a critical part of how LibAFL is structured.

Unfortunately, these can be very difficult to maintain. Our goal is to develop a tool capable of assisting developers in this maintenance process.

Please check out issue #2868 for more details.

Expected Outcomes

A tool that works on any rust code, tries to minimize the used bounds, and fixes the code

Skills Expected

• Rust
• A good understanding of Generics and the Rust Type system

Possible Mentors

• @addisoncrump
• @tokatoka

Expected size of the project

The project is expected to take either 175 or 350 hours.

Difficulty Rating

The overall difficulty of this project is expected to be medium.

Proposal 2: Adapt qemuafl Frontend to LibAFL QEMU

The project consists of adapting the frontend of qemuafl, the AFL++'s QEMU fork, with LibAFL QEMU.

Description

The end goal of this project would be to run fuzzers built for qemuafl while using LibAFL QEMU as the backend, in a retrocompatible way.
A draft PR is already available and can be used as a starting point by the student.
Ideally, the student would measure the performance (in terms of exec/s and coverage) of the new qemuafl adaptation with some fuzzers to evaluate how the final implementation compares with the reference.

Expected Outcomes

In short, we expect the student to make the new frontend work for most fuzzers developed for qemuafl while maintaining (at least) similar performance.

See #1983 for an initial implementation that still lacks features.

The main tasks the student would have to perform are the following:

• Speak the AFL++ forkserver protocol (check the draft PR).
• Add TCG caching to the LibAFL QEMU forkserver
• Use LibAFL QEMU snapshots where possible
• Add as many env variable features as possible

Skills Expected

We expect the student to:

• have a strong background in the Rust and C languages.
• be familiar with fuzzing.
• ideally, have some experience using AFL++ and / or LibAFL.
• ideally, have prior experience with the QEMU project.

Possible Mentors

The possible mentors for this project are:

• @domenukk
• @rmalmain

Expected size of the project

The project is expected to take either 175 or 350 hours.

Difficulty Rating

The overall difficulty of this project is expected to be medium.

Original post

This proposition is mostly an adaptation of issue #2964.

Proposal 3: Network Emulation for LibAFL_QEMU

Implement syscall emulation for filesystem and network in libafl_qemu.

Description

The student must implement something similar to preeny and FitM to hook the network API and an emulator filesystem that can be snapshot-restored always hooking the syscall in libafl_qemu user mode

Expected Outcomes

A working network emulation layer for LibAFL_QEMU

Required Skills

• Good understanding of Rust, C, system programming
• Ideally: prior knowledge in emulators and fuzzing

Difficulty Rating

The overall difficulty of this project is expected to be medium.

Possible mentors

• @domenukk
• @rmalmain

Expected size of the project

The project is expected to take either 175 or 350 hours, depending on details

Proposal 4: Remote Worker Stage

Mutations and execution of a Stage is always on the machine LibAFL runs at. For very slow targets it may be beneficial to offload the actual executions to stateless worker.

Description

We could add a RemoteWorkerLauncherStage that builds n work packages, each including a next scheduled corpus entry, all metadata for this Testcase, the current feedback state, as well as additional random corpus entries for splicing.
The work package should then be posted to Redis or some other queue db (very much like celery, whatever a rust alternative is).
After the execution, the results should be collected in an extra stage

Expected Outcome:

The implementation and a set of working examples, including:
LibAFL Workers / RemoteWorkerLauncherStage + RemoteWorkerCollectorStage

Required Skills

• Rust
• Prior knowledge in distributed computing and/or fuzzing are a plus

Difficulty Rating

easy to medium

Possible mentors

• @domenukk
• @tokatoka
• @addisoncrump

Length

175 hours

[tokatoka]

If you are interested send us a mail at gsoc@aflplus.plus