search

jtpereyda / boofuzz

A fork and successor of the Sulley Fuzzing Framework
GNU General Public License v2.0
2.02k stars 343 forks source link

SOCK_RAW and SOCK_DGRAM on Windows #103

Open jtpereyda opened 7 years ago

jtpereyda commented 7 years ago

If somebody is really in a mood for pain, they could implement SocketConnection's raw-l2 and raw-l3 options on Windows.

One way to do this might be with WinPcap. References:

If I understand correctly, WinPcap would allow behavior similar to SOCK_RAW, in which MACs must be supplied by the user (but not CRCs). To emulate SOCK_DGRAM may require custom code to figure out the right MAC addresses based on the included IP packet information.

winter3angle commented 7 years ago

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

jtpereyda commented 7 years ago

Cool research; thanks for posting it here...

hackathi commented 4 years ago

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.

jtpereyda commented 4 years ago

@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.

gogo2464 commented 3 years ago

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.