Extend WFP callout to be able to capture other traffic types

[dmiller-nmap]

Windows offers 2 different ways for drivers to inspect network traffic: NDIS LWF and WFP. Npcap uses NDIS LWF to see traffic on the stack between protocol drivers and miniport drivers. Some unusual network situations like VPNs may use a different data path that doesn't pass through our driver. WFP exists in a different part of the stack entirely, and could allow us to inspect traffic at different places, including prior to IPSEC VPN encapsulation. Because the semantics of traffic are different for WFP, we'd have to define and implement an extension to our existing API to let programs use it. The major difference is that there wouldn't be a concept of "capture traffic on this adapter" but rather "capture traffic at this point in the stack" which is pre-routing. That could be analogous to the "any" pseudo-device from libpcap on Linux.

Related: #257

[fyodor]

With a WFP callout, I suppose we could also consider adding certain packet filtering/modification features like we see in some other Windows WFP drivers such as WinDivert.

[fyodor]

I just chatted with @dmiller-nmap about WinDivert and he has some great insights as usual. My takes from the discussion: WinDivert seems to be a great library. It is illustrative of the sort of features we could add using a WFP backend, though we have some concerns about possible performance limitations of the API. Since much of WinDivert's API seems to be a usermode mapping of the WFP callout API, the frequent kernel-to-user mode context switching is likely to make performance much worse than a custom WFP driver would be. We would probably want something architected more like the libpcap API in that the user mode submits more general instructions (e.g. bpf for libpcap) that the driver can then execute on its own without frequent callouts back to user mode. We're also not super happy with our Packet.dll API inherited from WinPcap. It serves it's purpose but is a bit clunky and cobbled together. Rewriting a new Packet.dll (with a new name) would allow us to reuse the same primitives (capture, inject, control, etc) as backends for the libpcap API as well as building blocks for new higher-level concepts like user-mode filtering.