SOCK_RAW and SOCK_DGRAM on Windows about boofuzz HOT 5 OPEN

bump

As it currently stands, scapy has done all the legwork; with scapy it would just boil down to something like the code posted in this stackoverflow answer.

Still, scapy is quite a heavvy dependency, so before opening a PR I thought I'd discuss some options.

1. Just adding scapy as a dependency.
   Pro: easy.
   Con: huge dependency.

Sidenote: I really like the ease-of-use of scapy when defining packets. It'd be interesting to see if it's possible to autogenerate boofuzz blocks out of a scapy packet. If this were about to happen, then pulling in scapy as a dependency isn't too bad anymore.

2. Grab the source code of the L2 implementation from there, as scapy is GPL2 as well
   Pro: Minimal impact
   Con: it needs to be manually kept up to date by someone (which I for varying reasons can't do).

3. Use their implementation to roll our own.
   Pro: Could be directly in the L2/L3 classes, would be very clean.
   Con: Someone has to write it (which this issue is all about).

Personally, I'd go for 1 or 2, but I don't feel that that is supposed to be my decision.

from boofuzz.

I used to get 'raw sockets' working on sulley by applying ERNW fellas patch (descriped here https://www.troopers.de/media/filer_public/cf/16/cf162afc-dc95-460b-8a0a-576692e18e71/menderich-layer2_fuzzing_troopers08.pdf) by hand. Guys used Dug Song's dnet for raw L2 support on Windows. Not a best solution IMO, though

from boofuzz.

Cool research; thanks for posting it here...

from boofuzz.

@mistressofjellyfish Great idea. If somebody needs to get it working and wants to throw in scapy, I wouldn't be opposed. If it has performance impacts, we could probably limit/mitigate it to only when you actually need to use scapy.

Option 2 or 3 or somewhere in between would be great. Ideally there would be a pretty small excerpt we could grab from scapy and tweak. If anybody wants to do that that would be killer. : )

On the aside of defining packets: I haven't spent a lot of time working out the details, but it would be nice if a format could be used both to generate fuzz packets and to parse inputs (not sure if Scapy's approach favors this or not). I realized this while reading the Smart Greybox Fuzzing paper (https://arxiv.org/pdf/1811.09447.pdf). They reference a "File Cracker" module that is able to parse inputs and provide a full or partial match to a protocol message (sections 3.1 and 5.2). Being able to generate and parse with one protocol definition would be really slick and provide several advantages. It would also make it easy (easier) to plug boofuzz into AFLSmart in place of Peach.

from boofuzz.

I am very enthousiast to use scapy in boofuzz. So we could fuzz any protocol even wifi firmware and even unknow custom protocols: https://scapy.readthedocs.io/en/latest/build_dissect.html

So yes @mistressofjellyfish I think we should integrate scapy in boofuzz.

from boofuzz.