AFLplusplus
linux
Our great sponsors
AFLplusplus | linux | |
---|---|---|
16 | 974 | |
4,552 | 168,342 | |
5.5% | - | |
9.6 | 10.0 | |
7 days ago | 4 days ago | |
C | C | |
Apache License 2.0 | GNU General Public License v3.0 or later |
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.
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.
-
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
-
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.
-
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...
-
Adventures in Fuzzing Matrix’s Encryption
Author here. As one of the other comments mentions, afl++ (and to some extent vanilla afl) already has capability to automatically scrape magic values from arguments to special functions like `strcmp` and the like. The older technique is called libtokencap (https://github.com/AFLplusplus/AFLplusplus/blob/stable/utils...), but afl++ also has a newer feature called AUTODICT (https://github.com/AFLplusplus/AFLplusplus/blob/stable/instr...).
But this only solves the problem of magic constants expected in the input. If the check depends on dynamic properties of the input or happens deeper in the code after the input's already been through some transformations, it can't be solved like this. There are other techniques to help with this, though. One of the earlier attempts to solve such types of more complex checks is called laf-intel (https://github.com/AFLplusplus/AFLplusplus/blob/stable/instr...) and boils down to transforming a more complex check into a nested series of simpler checks. This makes it more probable that the fuzzer's random mutation will be able to solve the outer check and hence hit new coverage, enabling the fuzzer to detect the mutation as productive.
afl++ has a more modern variant of this called CmpLog (https://github.com/AFLplusplus/AFLplusplus/blob/stable/instr...) which is based on the RedQueen technique. The paper for RedQueen is a really interesting read: https://www.syssec.ruhr-uni-bochum.de/media/emma/veroeffentl...
The problem of checksums is at times also solved by simply modifying the binary so that the checksum is neutralized and always succeeds, especially if you have access to source code.
As for the problem of fuzzing stateful things like the double ratchet, one way of tackling the problem is to think of the input to the fuzzer as not only the raw bytes that you'll be passing to the program you're fuzzing, but as a blueprint specifying which high-level operations you'll be performing on the input. Then you teach your fuzzer to be smarter and be able to perform a bunch of those operations.
So, let's say you take 512 bytes as the input to the fuzzer. You treat the first 256 bytes as the message to decode and the latter 256 bytes as the high-level cryptographic operations to perform on this message, each byte specifying one of those operations. So you could say a byte of value 1 represents the operation "ENCRYPT WITH KEY K1", 2 represents "ENCRYPT WITH KEY K2", 3 represents "DECRYPT WITH KEY K1", 4 represents "DECRYPT WITH KEY K2", 5 represents "PERFORM SHA2" and so on. Now you can feasibly end up with a sequence which will take a message encrypted with key K1, decrypt it, modify the message, then re-encrypt with key K2. Or, in the case of the double ratchet algorithm, have it perform multiple successive encryption steps to evolve the state of the ratchet and be able to fuzz more deeply.
Of course, the encoding needs to be rather dense for this to work well so that ideally each low-level bit mutation the fuzzer does on an input still encodes a valid sequence of valid high-level operations.
-
How Fuzzing with QEMU (and AFL) Works
By patching QEMU, TriforceAFL and AFL++ managed to get coverage feedback out of any binary that QEMU can run. How cool is that?!
-
First C++ OSS Project - Liquid Parser/Renderer
Another alternative seems to be AFL / AFLplusplus (a fork): https://github.com/AFLplusplus/AFLplusplus
linux
-
TinyMCE (also) moving from MIT to GPL
Correct. And the combined work needs to carry the MIT license text and copyright attributions for the MIT software authors. With binary distribution it must also be overt, not hidden in some source code drop, but directly accompanying the binary.
Many people who talk about relicensing never credit the MIT developers or distribute the MIT license text. "Because it's GPL now."
I don't think that you believe that, but many developers do.
Some don't see the need for source code scans for Open Source compliance, because the license.txt says GPL, so it's GPL. Prime example is the Linux kernel. There is code under different licenses in there, but people don't even read https://github.com/torvalds/linux/blob/master/COPYING till the end ("In addition, other licenses may also apply.") and conclude it's simply GPL 2 and nothing else.
Also be aware that sublicensing is not the same as relicensing.
-
The Linux Kernel Prepares for Rust 1.77 Upgrade
So If we would only count code and not comments, it is only 9489 LoC Rust. Which would be about 0.03% and if we take all lines and not only LoC it would be around 0.05%
[0] https://github.com/XAMPPRocky/tokei
[1] https://github.com/torvalds/linux/commit/b401b621758e46812da...
-
Proposed Windows NT sync driver brings big Wine/Proton performance improvements
AIUI fsync is built on futex_waitv which has been upstreamed. So this has to be more than that.
https://github.com/torvalds/linux/commit/a0eb2da92b715d0c97b...
-
Tell HN: GitHub no longer readable without JavaScript
git clone --no-checkout --depth 1 https://github.com/torvalds/linux.git $dir
-
PixieFail: Nine Vulnerabilities UEFI Implementations
Device trees are what you get if you don't implement ACPI.
While there are alternatives, you generally seem to get "device trees and a barebones bootloader" on ARM and "UEFI + ACPI" on amd64.
ACPI will list hardware and necessary hardware properties based on some basic API calls to the system interface. UEFI initialises the ACPI data structure and exposes it to the bootloader so the appropriate drivers can be loaded and configured.
With device trees, you basically configure and build the drivers and configuration into the kernel/OS you're trying to load. That's why compiling Linux on amd64 is generally easy and produces a single image, while for many other devices (smartphones, some SBCs) you need to compile a kernel per device. The device trees only need to be imported/written once per device (or device type, depending on how nice the manufacturers are), but that's how you get stuff like this: https://github.com/torvalds/linux/tree/master/arch/arm64/boo...
On ARM there are actually a few devices that implement UEFI, but most of them have Secure Boot locked in and configured to only boot Windows.
ACPI is not perfect and it's not technically required to have UEFI to implement something better than device trees, but I'm not sure if reinventing the wheel here is necessary or even preferable. UEFI already has open source implementations ready to go, with kernels and other tools already containing code to interact with those APIs, whereas a custom ACPI replacement protocol would need more implementation work,
-
Maestro: A Linux-compatible kernel in Rust
The Linux Kernel Driver Interface
(all of your questions answered and then some)
https://github.com/torvalds/linux/blob/master/Documentation/...
-
Uniting the Linux random-number devices
A bit later another commit [1] was merged that makes reads from /dev/urandom opportunistically initialize the RNG. In practice this has the same result as the reverted commit on non-obsolete architectures, which do have a cycle counter and thus jitter entropy.
[1] https://github.com/torvalds/linux/commit/48bff1053c172e6c7f3...
The commit [1] was eventually reverted [2]
[1] https://github.com/torvalds/linux/commit/6f98a4bfee72c22f50a...
-
Linux: Ext4 data corruption in 6.1.64-1
Here's my understanding so far:
In the upstream Linux kernel there were two fixes posted months from each other, one for direct io [0] and the other one for ext4 [1]. The ext4 one was marked for backport to stable (CC: [email protected]), the other was not. The problem is that these commits depend on each other for things to work properly. If you have both, you're fine. If you have only the backported one, you have a problem.
What versions are affected? We know for sure that 6.1.64 is affected, 6.1.55 is not (because it doesn't have the commit). As of right now, 6.1.64 is still marked as "stable" in Debian [2] but if you actually try to install it from the official mirrors (deb.debian.org), you will get error 403. The fix is included in version 6.1.66 which will soon be available.
The issue seems to be only highlighted in the context of Debian but it is not specific to it. The issue is/was in the official upstream release.
[0] https://github.com/torvalds/linux/commit/936e114a245b6e38e0d...
What are some alternatives?
zen-kernel - Zen Patched Kernel Sources
honggfuzz - Security oriented software fuzzer. Supports evolutionary, feedback-driven fuzzing based on code coverage (SW and HW based)
DS4Windows - Like those other ds4tools, but sexier
LibAFL - Advanced Fuzzing Library - Slot your Fuzzer together in Rust! Scales across cores and machines. For Windows, Android, MacOS, Linux, no_std, ...
winapps - Run Windows apps such as Microsoft Office/Adobe in Linux (Ubuntu/Fedora) and GNOME/KDE as if they were a part of the native OS, including Nautilus integration.
Open and cheap DIY IP-KVM based on Raspberry Pi - Open and inexpensive DIY IP-KVM based on Raspberry Pi
oss-fuzz - OSS-Fuzz - continuous fuzzing for open source software.
DsHidMini - Virtual HID Mini-user-mode-driver for Sony DualShock 3 Controllers
serenity - The Serenity Operating System 🐞
syzkaller - syzkaller is an unsupervised coverage-guided kernel fuzzer
RyzenAdj - Adjust power management settings for Ryzen APUs
void-packages - The Void source packages collection