WinAFL

[Michal Zalewski]

Yep, it's happening!

https://github.com/ivanfratric/winafl

:-)

[Jacek Wielemborek]

W dniu 12.07.2016 o 04:47, Michal Zalewski pisze:

> Yep, it's happening!
>
> https://github.com/ivanfratric/winafl
>
> :-)

Yay! It would be nice to see a platform-specific part of the patch and
figure out if it could be somehow factored out to one specific file...
there's so many fuzzing scenarios that it would make hacking AFL much
easier if there was only a specific piece of code that needs adapting
for new platforms.

Anyway, great news! :)

[Tim Newsham]

Yay! It would be nice to see a platform-specific part of the patch and
figure out if it could be somehow factored out to one specific file...
there's so many fuzzing scenarios that it would make hacking AFL much
easier if there was only a specific piece of code that needs adapting
for new platforms.

I'm curious, are there any plans for an afl refactor?  AFL's been pretty

successful and seems to be outgrowing its current code base.

[Tim Newsham]

I'm curious, are there any plans for an afl refactor?  AFL's been pretty

successful and seems to be outgrowing its current code base.

I've been thinking that a modular implementation of the tools (afl-fuzz, tmin, cmin,

showmap, etc) in a high level language like golang (with C code where warranted

for performance) would be nice.  Having modular shared code for interacting

with the fuzz server and for generating test cases would be nice for experimenting

with new features and strategies...  that said, I haven't had any time to sink

into it... 

[Jacek Wielemborek]

W dniu 13.07.2016 o 00:49, Tim Newsham pisze:

For what it's worth, here's my (most likely unfinished) attempt at
factoring out fuzzing engine:

https://github.com/d33tah/afl-refactor

Also, a quote of my post from 2015:

> I had a go at trying to integrate this with Go using the cgo extension.
> Here are the results:
>
> https://github.com/d33tah/afl-refactor/tree/go
>
> It's now possible to reference Go functions within afl-fuzz and the
> other way round - the idea is that this way, the most complicated pieces
> of C code could be rewritten to a higher-level language. Anyone willing
> to experiment with that?

Thread can be found here:

https://groups.google.com/d/msg/afl-users/TCMsWHN2dDA/dJY6cKMGEAAJ

Cheers,
d33tah

[Michal Zalewski]

> I'm curious, are there any plans for an afl refactor? AFL's been pretty
> successful and seems to be outgrowing its current code base.

Yeah, eventually... no, probably not in Go =)

[Tim Newsham]

Yeah, eventually... no, probably not in Go =)

What are your plans and goals?  Are you targeting C? 

[Michal Zalewski]

> What are your plans and goals? Are you targeting C?

It's not much of a plan just yet... but generally, it needs a more
logical layout (without one giant .c blob), with better code reuse
between afl-fuzz and auxiliary tools; and better support for your own
mutation algorithms, etc. Support for several other things
(auto-scaling to multiple cores, better timeout detection, the ability
to save stdout / stderr and maybe even use it in fuzzing, and so on)
would be nice, too.

It's going to be C, I don't want garbage collection or threads
breaking the current model too much.

/mz