schmu
AFLplusplus
schmu | AFLplusplus | |
---|---|---|
3 | 16 | |
24 | 4,646 | |
- | 1.8% | |
9.5 | 9.7 | |
5 days ago | 2 days ago | |
OCaml | C | |
European Union Public License 1.2 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
schmu
-
November 2022 monthly "What are you working on?" thread
Since the last time I posted, I finished implementing pattern matching for schmu. To make matching on multiple columns less confusing I also added a tuple syntax to the language (finally), which are treated as anonymous records in codegen. Since then, I'm trying to overhaul my memory management, as my RAII-like solution only worked for linear code. In my first big departure from OCaml semantics, I decided to implement mutable value semantics. The paper linked in the Val language introduction makes a strong case for value semantics and after watching a couple of talks by Dave Abrahams, I wanted to try see how it feels. By making mutability be transitive and explicit, it also fixes one of the (few) gripes I have with OCaml that an array can never be really const as it is a reference type (it's possible to enforce constness with modules, but that's not exactly lightweight, syntax wise). Implementing mutable value semantics was pretty straight forward on the typing side, but I'm still not completely done with the codegen. This is due to 1. Assumptions about immutability I made in a lot of places are now wrong, and I had to completely change the way I pass values to functions. 2. I had to implement reference counted arrays, which was more work than I thought it would be. There are still edge-cases coming up in testing from time to time. Yesterday I finally managed it work for tail recursion, yay! I'm looking forward to getting rid of unneeded reference count updates in the future, by moving them to compile time, at least for linear code, lobster style. That's also an excuse to read that Perceus paper again. For the rest of November, I want to enhance my module system a bit. In particular, I want to add signatures and allow locally abstract types. I hope to have this in place before December to do the Advent of Code in my language.
-
September 2022 monthly "What are you working on?" thread
I'm still working on my toy language schmu, an ML-inspired language which uses LLVM as backend.
-
May 2022 monthly "What are you working on?" thread
I spent the time off over the Easter break to write the first program in my language which is not an explicit test and ended up implementing Ray Tracing In One Weekend. It was very rewarding to see how usable the language is already.
AFLplusplus
-
Decoding C/C++ Compilation Process: From Source Code to Binary
It could be cool to see some explanation of CFG representations or GIMPLE/LLVM here. GCC/Clang can print those out as text, or just compile to that code and not go lower if you ask them to. There are some interesting things you can do with bytecode, like Rellic, AFL++, or optview2. It seems a bit reductive imo to go straight from high-level code to disassembly without at all examining any layers in between. Especially if we use something like Polygeist or CIR.
-
Why is my fuzzer running so slow?
Honestly, I wouldn't bother writing your own fuzzer, and just use one of the existing solutions, like afl++. Contrary to popular belief, good fuzzers do not just generate random bytes; the way they generate data depends on a genetic algorithm based on the code paths taken by the program. AFL++ can also fuzz regular binaries that weren't instrumented, but according to the documentation it is much less effective.
-
Olive programming language
Be outside the loop? At least that's how they do it in their example https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.persistent_mode.md
-
How do you test compiler projects?
I use fuzzers, as every programmer should, and do not commit unless my compiler can be fuzzed for at least 24 hours without any crashes (if I were selling the software, I'd increase that period). I use AFL++ in LTO mode and comby-decomposer with a crappy script I made to collect crash test cases. I am also interested in afl-compiler-fuzzer, but have not yet tried it. Later, I'd like to try my hand at making a test generator that reaches codegen more often (no compile errors in the random source code). I use afl-tmin to minimize test cases, but the result is always illegible without manual work, and usually has extra junk the minimizer is incapable of deleting. Something like C-Reduce would be useful here.
-
November 2022 monthly "What are you working on?" thread
1: https://github.com/ArkScript-lang/Ark 2: https://github.com/AFLplusplus/AFLplusplus
-
AFLplusplus VS jazzer.js - a user suggested alternative
2 projects | 12 Sep 2022
- New Mode for AFL++
-
Frelatage: A fuzzing library to find vulnerabilities and bugs in Python applications
Frelatage is a coverage-based Python fuzzing library which can be used to fuzz python code. The development of Frelatage was inspired by various other fuzzers, including AFL/AFL++, Atheris and PyFuzzer.The main purpose of the project is to take advantage of the best features of these fuzzers and gather them together into a new tool in order to efficiently fuzz python applications.
-
Fuzzing: Automated Bug Hunting in Software
I personally have not gone over any books over the topic so I cannot recommend books. However, there is a popular fuzzer known as AFL++ that specifies its technical workings and has a tutorial on its usage in the documentation. You can find it here. I found using the tool helped me gain a good understanding of the topic.
-
60x speed-up of Linux “perf”
With AFL++ you can even determine exactly where the fork happens:
https://github.com/AFLplusplus/AFLplusplus/blob/stable/instr...
What are some alternatives?
Forscape - Scientific computing language
honggfuzz - Security oriented software fuzzer. Supports evolutionary, feedback-driven fuzzing based on code coverage (SW and HW based)
vult - Vult is a transcompiler well suited to write high-performance DSP code
LibAFL - Advanced Fuzzing Library - Slot your Fuzzer together in Rust! Scales across cores and machines. For Windows, Android, MacOS, Linux, no_std, ...
GLhf - OpenGL Application Abstraction
oss-fuzz - OSS-Fuzz - continuous fuzzing for open source software.
peridot - A fast functional language based on two level type theory
syzkaller - syzkaller is an unsupervised coverage-guided kernel fuzzer
awesome-low-level-programming-languages - A curated list of low level programming languages (i.e. suitable for OS and game programming)
American Fuzzy Lop - american fuzzy lop - a security-oriented fuzzer
Cwerg - The best C-like language that can be implemented in 10kLOC.
sharpfuzz - AFL-based fuzz testing for .NET