
CVE-2014-1824 – A New Windows Fuzzing Target - lelf
http://blog.beyondtrust.com/cve-2014-1824-searching-for-windows-attack-surface
======
pascal_cuoq
> many common <programs notoriously available in binary form only> are
> becoming reasonably hard targets to fuzz and find interesting crashes. There
> are two solutions to this: write a better fuzzer (<link to source-level
> fuzzer>)

If you are writing a blog post and have no ideas for the introduction, please
just skip it rather than crowbarring in an awkward reference to other items in
the news.

~~~
jacquesgt
AFL isn’t a source-level fuzzer. It interposes between the compiler and the
assembler to add instrumentation to assembly code emitted by the compiler.
Shouldn’t it be possible to do the same thing via binary rewriting or
emulation in cases where source access isn’t possible? The first one would be
hard and the second one would be slow, but I don’t think there’s anything
about AFL’s approach that would stop this from working.

~~~
pascal_cuoq
I agree that it would be completely possible in principle to make an AFL-style
fuzzer for binary, and that then it would risk being either brittle or slow
(depending on the instrumentation technique used to measure coverage), two
properties that AFL explicitly set out to avoid. So a hypothetical AFL for
binaries is not really AFL any longer until someone proves it's possible to
make one with the same good behavior.

A modified hypervisor that would use the features initially intended for
“replay debugging” for measuring coverage instead could be cool, though.

