<shapr>
if you instrument your source with afl-clang, afl can scramble inputs in an attempt to exercise every branch of every conditional, things like that
<shapr>
it has nifty tricks where it can 'suspend' the executing binary just before a branch, and then restore that with bits flipped in the input to discover what inputs hit which branches
<ZipCPU>
What constitutes success/failure? I'm not seeing that on their 30sec elevator speech.
<shapr>
best feedback is segfault or other fatal crash
<shapr>
then you know you've found something
<shapr>
if you have any programs you've written in C or C++ that take input, I suspect afl could find bugs in less than 24 hours.
<ZipCPU>
Can it find bugs in non-x86 code?
<ZipCPU>
As in, does it work on the source or the object code?
<shapr>
pretty sure it only needs clang, don't think it's x86 specific
massi has quit [Remote host closed the connection]
<shapr>
qu1j0t3: have not, what is it?
<qu1j0t3>
shapr: One of the first to take that kind of approach, i think. https://klee.github.io/
seldridge has quit [Ping timeout: 240 seconds]
<q3k>
@ZipCPU | Can it find bugs in non-x86 code?
<q3k>
yes, i've used it to find bugs in aarch64 and arm
<q3k>
although some patches are sometimes required
<q3k>
(for afl/llvm magic)
<q3k>
ZipCPU: there's two ways to run software under AFL: compile it from source with appropriate instrumentation (via the afl-gcc/afl-clang scripts)
<q3k>
ZipCPU: or you can run software under qemu user, which also works but is around 10x slower than native instrumentation
<q3k>
ZipCPU: for closed source software you're better off with honggfuzz - that does some very clever instrumentation using various magical intel features
<q3k>
ZipCPU: like intel pt.
<q3k>
ZipCPU: but then, that's intel only :)
<ZipCPU>
I was actually wondering about ZipCPU support ;P
<q3k>
well, afl requires linux
<q3k>
do you have a linux port to zipcpu?
<ZipCPU>
Doh!
<ZipCPU>
I've got all of the hardware pieces together, but ... haven't dug into what it would take to build it. (There's still some MMU connections to be made ...)
<q3k>
anyway, from my experience - it doesn't really matter which platform you run software under to fuzz it
<q3k>
security bugs will appear about the same way on all platforms
<q3k>
(when we're talking _normal_ platforms like x86_65, armv7, armv8)
<q3k>
i fuzzed a few ARM binaries during CTFs by fully decompiling them to C via IDA, cleaning up the resulting pseudocode, and recompiling under intel :)
<gruetzko->
oh, 65bit :D
gruetzko- is now known as gruetzkopf
<q3k>
gruetzkopf: har har :P
<sorear>
Does libfuzzer obsolete afl? Why or why not?
<q3k>
not sure.
etrig has joined #yosys
seldridge has joined #yosys
digshadow has quit [Ping timeout: 240 seconds]
dys has joined #yosys
lutsabound has joined #yosys
digshadow has joined #yosys
guan has quit [Read error: Connection reset by peer]
guan has joined #yosys
<shapr>
is there an interactive web tool for yosys? something where I could write verilog and see how the code might behave with hardware plugged in?
<daveshah>
shapr: yes, there are a few attempts at Yosys in the browser
<daveshah>
Not sure if any quite meet that description though