If you've ever been ghosted by your own compiler in the middle of a build—congratulations, you're ready for the chaotic dating life that is fuzzing. Or as I like to call it: fuzzling, because this unholy blend of "fuzzing" and "puzzling" is exactly what happens when you feed random nonsense to a compiler and sit back like a mad scientist watching it combust.
Imagine you gave a 2-year-old toddler a box of Lego and asked them to build a spaceship. Now imagine giving the same toddler caffeine, 4,000 more Legos, and a deadline. That's basically what we're doing with solfuzzer: giving it ridiculous Solidity inputs and watching if the compiler dies of confusion.
But here's the twist. We're not testing if the code breaks—no, no, no, that’s for people who still have hope in life. We're checking if the compiler itself implodes. Like, segmentation fault, null pointer, throws-up-and-dies kind of implosion.
Yes. We’re debugging the debugger.
American Fuzzy Lop (AFL) is the tool we use to generate randomized, mutated, brain-melting inputs for our compiler. AFL is like that friend who pokes every single item in a museum just to see which one sets off the alarm.
To make this spicy romance between AFL and solfuzzer happen, you compile your code using afl-gcc or afl-clang. If you don’t, AFL will scream at you like an overworked parent:
"[-] PROGRAM ABORT: No instrumentation detected"
Which is a fancy way of saying: “You forgot to add the secret sauce, buddy.”
Your initial test files (or corpus, if you're feeling fancy) should be small, innocent-looking source files, ideally under 1kB. Tiny gremlins, really. One function, one chaos. If you give it War and Peace written in Solidity, AFL will probably just run away and join a monastery.
You can extract test files from Solidity’s test suite using this beautifully named script:
Editisolate_tests.py
Which sounds less like a developer tool and more like a dystopian sci-fi protocol.
You run the fuzzer like this:
afl-fuzz -m 60 -i /tmp/test_cases -o /tmp/fuzzer_reports -- /path/to/solfuzzer
The -m 60 tells the fuzzer, “Yes, you may use 60MB of memory to destroy my sanity.”
Soon, /tmp/fuzzer_reports will start filling up with files named like a drunk robot had a keyboard seizure:
id:000023,sig:11,src:000004,op:havoc,rep:16
Each one of those is a tiny masterpiece of mayhem that made your compiler curl up into a ball and sob quietly in the corner.
Now that your fuzzer has vomited hundreds of broken files, it’s time to Marie Kondo that chaos. Use:
scripts/uniqueErrors.sh
This filters out duplicates, so you’re left with only the most unique and creative ways your compiler failed. It’s like an Oscars ceremony but for catastrophic segmentation faults.
Fuzzling is the fine art of weaponizing nonsense. It's beautiful. It’s chaotic. It’s the only time in life when making things worse is actually considered a valuable contribution to open source.
So go forth, brave fuzzler. May your compilers crash early, crash often, and leave behind glorious core dumps worthy of Valhalla.
Just remember: if you're not hearing screams from your compiler...
are you even fuzzing hard enough?
<100 subscribers