20

I am about to use Wireshark for some traffic monitoring on my Windows computer. While working on it, I was wondering how Wireshark manages to catch low level network packets before Windows does.

First of all, a network interface on my NIC receives a packet. The NIC then does some initial checks (CRC, right MAC address, ... etc. ). Assuming that the verification was successful, the NIC forwards the packet. But how and where?

I understand that drivers are the glue between the NIC and the OS or any other application. I further guess that there's a separate driver for Windows and Wireshark (WinPcap?). Otherwise, Wireshark wouldn't be able to receive Ethernet frames. Are there two or more NIC drivers coexisting at the same time? How does the NIC know, which one to use?

Hansi
  • 211
  • 1
  • 6
  • Your premise is incorrect. The NIC always hands the packet off to Windows (specifically, to the device driver and then the network stack), and it's up to Windows to decide what to do with it. Windows has a feature where a program can ask to receive copies of packets "as they were on the wire", perhaps applying a filter, and Wireshark uses that feature. Wireshark does *not* bypass Windows. – zwol Jun 13 '16 at 19:31
  • (There are experimental operating systems which attempt to do extremely-high-speed networking better by allowing packets to be delivered directly from the network card to the application, but AFAIK Windows cannot do this: you always at least go through the NDIS layer.) – zwol Jun 13 '16 at 19:33

2 Answers2

38

The I/O model in Windows is based on a stack of components. Data must flow through the various components of that stack that exists between the physical network card, and the application that will consume the data. Sometimes those various components inspect the data (a TCP packet for example,) as they flow through the stack, and based on the contents of that packet, the data may be altered, or the packet may be discarded entirely.

Network Stack

This is a simplified model of the "network stack" that packets flow through in order to get from the application to the wire and vice versa.

One of the most interesting components shown in the screenshot above is the WFP (Windows Filtering Platform) Callout API. If we zoomed in on that, it might look something like this:

Windows Filtering Platform

Developers are free to plug in their own modules into the appropriate places in this stack. For instance, antivirus products typically use a "filter driver" that plugs in to this model and inspects network traffic or provides firewall capabilities. The Windows Firewall service also obviously fits in to this model as well.

If you wanted to write an application that records network traffic, such as Wireshark, then the appropriate way to do it would be to use a driver of your own, and insert it into the stack as low as possible so that it can detect network packets before your firewall module has a chance to drop them.

So there are many "drivers" involved in this process. Many different types of drivers too. Also, other forms of input/output on the system, such as hard disk drive reads and writes, follow very similar models.

One other note - WFP callouts are not the only way to insinuate yourself into the network stack. WinPCap as an example, interfaces with NDIS directly with a driver, meaning it has a chance to intercept traffic before any filtering has taken place at all.

NDIS Drivers

WinPCap

References:

Next Generation TCP/IP Stack in Vista+

Windows Filtering Platform Architecture

Ryan Ries
  • 55,011
  • 9
  • 138
  • 197
  • 3
    Outstanding diagrams. Are these posted on microsoft.com somewhere? If so, I would love to poke around and see what other information is available alongside these. – EEAA Jun 12 '16 at 18:59
  • @EEAA Edited the answer to provide the couple of references I used in this case. – Ryan Ries Jun 12 '16 at 19:12
  • 1
    Perfect answer. Well and easy explained, awesome visualisation and sources provided! Thank you so much! – Hansi Jun 12 '16 at 22:10
  • 1
    +1, worth mentioning that there is an open source driver built atop WFP that makes it trivial to write such applications called [WinDivert](https://github.com/basil00/Divert). I've also written a [.NET wrapper](https://github.com/TechnikEmpire/Divert.Net) for it. –  Jun 13 '16 at 12:47
  • 1
    It used to be the case there was something called the "Layered Service Provider" - where you could intercept _and rewrite_ packets - is there some replacement for that ability? Is it part of the "filtering" API? (Oh wait, never mind: I just looked at the WinDivert link from @TechnikEmpire and see that that's possible.) – davidbak Jun 13 '16 at 20:54
  • 1
    @davidbak yes, WinDivert is a kind of a hybrid. The callout driver APIs are meant for developers to build specific drivers that can do anything beyond simply dropping a packet (requires no driver). WinDivert is such a driver but it's generic, providing full access to packets by pushing and popping packets in and out of kernel and user mode space. –  Jun 13 '16 at 21:12
3

As Ryan Ries' answer says:

WinPCap as an example, interfaces with NDIS directly with a driver, meaning it has a chance to intercept traffic before any filtering has taken place at all.

and this is a description, in the WinPcap documentation, of how that works.

  • This would have been better as an edit to Ryan's answer. It's not an answer in its own right. – Lightness Races in Orbit Jun 12 '16 at 22:48
  • 2
    Actually, yes, it *is* an answer to his question - more so than Ryan's answer. The question was "how does Wireshark do it"; Ryan's answer gives a lot of information about a mechanism that WinPcap (which is what Wireshark uses) *doesn't* use, so it's certainly interesting, but not relevant to the original question. The link I posted describes how *WinPcap* does it, which *is* relevant to the original question. –  Jun 13 '16 at 01:05
  • 7
    Maybe if you'd quoted and explained the relevant passages from the third-party resource. If nothing else, a link-only answer is not an answer. That's SE policy. All your answer adds to this page is, literally, "there is a description of how Ries's answer works somewhere else on the internet" – Lightness Races in Orbit Jun 13 '16 at 01:36