Security Testing

Project 1: Bugfixes and Setup Time Changes

Written on 11.12.2025 14:51 by Valentin Huber

I was made aware of two distinct bugs with the project setup, and found one cheating avenue, all of which was fixed by a commit that was just pushed to the repositories of all students that have already accepted the project 1 (please run git pull!) — students who have not yet accepted the project will automatically get the newest version. Here are the changes in detail:

• Previously, the runtime of any logic run at the top level of fuzzer.py (or any other file imported from there) was not accounted. This means that in principle, students would have been able to use an arbitrary amount of runtime to pre-compute inputs, such that their entire hour of running the target could be spent in the target, even when using a very slow fuzzer. This would obviously be considered cheating. We have changed the behavior as follows: The setup logic is now times. If it takes longer than 5 minutes, any additional time is deducted from your fuzzing budget. Some examples:
  • If your setup logic takes 3 seconds, you will get 60 minutes of fuzzing.
  • If your setup logic takes 4.5 minutes, you will still get 60 minutes of fuzzing.
  • If your setup logic takes 8 (5 + 3 extra) minutes, you will only get 57 (60 - 3) minutes of fuzzing.
• On Windows systems, git has (as is normal for its operation) converted the line endings of non-binary files to CRLF, instead of the LF used in UNIX, when you cloned the repository. This is done to allow ordinary Windows programs to change the files. The line endings are changed back once the changes are pulled to a UNIX system. However, on a Windows machine, some files (specifically apt-packages.txt and run_and_get_coverage.sh) are simply copied from the Windows host to the Ubuntu Docker image, without the intermediate fixes through git. This lead to failures when trying to build the Docker images on Windows systems, since the extra characters are not legal in those places in Ubuntu. To fix this, the line endings are now manually converted in the Dockerfile.
• If your fuzzer called some other process that either (a) calls the default system-wide Python interpreter, or (b) is only available as a Python dependency, this would previously fail, because the virtual environment, into which all Python dependencies are installed, was not correctly activated. This should now be fixed.

If you have any questions regarding these changes, please ask them in the forum. I would also like to thank all the students that have reported these bugs and helped me find fixes. Enjoy your fuzzing!