WinPcap

WinPcap war die Treiber- und Bibliotheksschicht, über die Programme unter Windows Netzwerkpakete mitschneiden konnten. Sie hat zwei Jahrzehnte lang jedes Analysewerkzeug auf dieser Plattform getragen — und wird seit Jahren nicht mehr gepflegt.

Was WinPcap war

Windows erlaubt keinem Programm, den Netzwerkverkehr vollständig mitzulesen. Dafür braucht es einen Treiber im Kernel, der sich in den Netzwerkstapel einhängt.

WinPcap bestand aus drei Teilen:

npf.sys — der Kerneltreiber, der die Pakete abgreift.

packet.dll — die systemnahe Schnittstelle zum Treiber.

wpcap.dll — die Bibliothek, die dieselbe Schnittstelle anbietet wie libpcap unter Unix.

Der letzte Punkt war der entscheidende: Weil die API dieselbe war, ließen sich Programme aus der Unix-Welt mit vergleichsweise geringem Aufwand nach Windows bringen. Wireshark, Nmap, Snort und zahlreiche weitere Werkzeuge hatten dadurch überhaupt eine Windows-Fassung.

Warum die Pflege endete

Die letzte Fassung 4.1.3 stammt aus dem Jahr 2013. Danach hat das Projekt die Entwicklung eingestellt und verweist auf Npcap als Nachfolger. Drei Gründe liefen zusammen:

NDIS 5 war überholt. WinPcap hängte sich über eine Schnittstelle in den Netzwerkstapel, die Microsoft schon mit Windows Vista durch NDIS 6 ersetzt hatte. Die alte Schnittstelle blieb aus Kompatibilitätsgründen erhalten, bekam aber keine Pflege mehr — mit Folgen für Durchsatz und Stabilität auf neueren Systemen.

Die Treibersignatur. Windows verlangt für Kerneltreiber zunehmend strengere Signaturen. Ein Treiber von 2013 erfüllt diese Anforderungen nicht mehr überall, und ohne aktive Entwicklung gab es niemanden, der neu signiert hätte.

Kein Loopback. Verkehr, den ein Rechner mit sich selbst austauscht, war mit WinPcap grundsätzlich nicht erfassbar. Für die Fehlersuche an lokal laufenden Diensten war das eine harte Grenze — und sie ließ sich mit NDIS 5 nicht überwinden.

Was heute an seine Stelle tritt

Npcap ist der direkte Nachfolger, entstanden aus Verbesserungen am WinPcap-Code. Es nutzt NDIS 6, kann Loopback-Verkehr erfassen und wird aktiv entwickelt. Wichtig beim Wechsel: Der Installer ersetzt eine vorhandene WinPcap-Installation standardmäßig; wer ein Altprogramm betreibt, das nur mit WinPcap läuft, kann den kompatiblen Modus abwählen. Zu beachten ist dort außerdem die Lizenz, die enger ist als bei WinPcap.

pktmon ist seit Windows 10 als Bordmittel enthalten. Es braucht keine Installation und keinen Fremdtreiber, bietet aber eine andere Bedienung und keine libpcap-Schnittstelle. Für einen Mitschnitt auf einem System, auf dem man nichts installieren darf oder will, ist es oft der kürzere Weg.

Was beim Antreffen im Bestand zu tun ist

WinPcap findet sich weiterhin auf Systemen — teils als Altinstallation, teils weil ein Programm es mitbringt. Zwei Punkte sprechen für den Austausch:

Ein Kerneltreiber ohne Pflege ist eine Angriffsfläche, für die es keine Korrekturen mehr gibt. Und ein Mitschnittwerkzeug, das plötzlich keine Adapter mehr anzeigt oder nach einem Windows-Update gar nicht startet, hat in der Regel genau diese Ursache — der veraltete Treiber lädt nicht mehr.

Die Deinstallation ist unauffällig: Programme, die auf die Bibliothek zugreifen, finden nach einer Npcap-Installation im kompatiblen Modus dieselben Dateinamen vor.

Abgrenzung

Npcap ist der Nachfolger und sollte die Wahl für jede neue Installation sein.

libpcap ist die Bibliothek der Unix-Welt, deren Schnittstelle WinPcap nachbildete. Das Dateiformat der Mitschnitte ist auf beiden Plattformen gleich.

Win10Pcap war ein Zwischenschritt eines Drittanbieters mit NDIS-6-Unterstützung, inzwischen ebenfalls ohne Pflege.

pktmon löst dieselbe Aufgabe mit Bordmitteln.

Quellen

• WinPcap: Projektseite mit Hinweis auf die eingestellte Pflege
• Npcap: Projektseite und Hinweise zur Migration
• Microsoft: NDIS-Versionen und Filtertreiber