Description
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
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:
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
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
Length
175 hours
Proposal 5: Reimplement Frida-ASAN using the new librasan infrastructure
Currently we have two implementations of ASAN, one in frida-mode and one in librasan.
Description
librasan is a new framework for building ASAN implementations, developed initially for various QEMU ASAN use cases. It is built to be modular and extensible.
Frida-ASAN is an implementation of ASAN for frida-mode.
There are numerous overlaps between these two implementations, and we would like to merge them, in as much as that is possible, by reimplementing Frida-ASAN in terms of librasan.
Expected Outcome:
A new implementation of Frida-ASAN using librasan, with duplicate code and functionality removed, and a set of unit and integration tests which verify that the implementation is correct.
Required Skills
- Rust
- C and systems programming
- Prior experience in frida usage (including Stalker) an advantage.
- Prior experience in allocator development an advantage.
Difficulty Rating
medium
Possible mentors
Length
175 or 350 hours