Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nmap 7.70 with Npcap 0.99-r2 in WinPcap API-compatible mode can't scan localhost #392

Closed
dmiller-nmap opened this issue Mar 29, 2018 · 4 comments

Comments

@dmiller-nmap
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Mar 29, 2018

Nmap 7.70 is failing to inject packets on the Npcap Loopback Adapter, but only when Npcap is installed in WinPcap API-compatible mode. Everything looks fine, but all ports come back filtered and Wireshark doesn't see the traffic. In native install mode, everything works. In both modes, packet injection on other interfaces (for remote scans) works fine.

@dmiller-nmap
Copy link
Contributor Author

@dmiller-nmap dmiller-nmap commented Mar 29, 2018

Affects Npcap 0.99-r1 and 0.99-r2, but not earlier releases.

@dmiller-nmap
Copy link
Contributor Author

@dmiller-nmap dmiller-nmap commented Apr 3, 2018

This is because we started using the Service registry key ("HKLM:\System\CurrentControlSet\Services\npcap\Parameters" usually, but also "npf\Parameters" under WinPcap API-compatible mode) to determine installation settings and features. Specifically, the LoopbackAdapter value needs to be read by the driver in order to do injection on the loopback adapter. NPFInstall.exe -il is writing it only to the "npf\Parameters" key, so the standard driver doesn't see it.

Remaining questions that need to be answered before we can fix it:

  1. Why is NPFInstall.exe using the "npf" service name? That should only be possible with NPFInstall2.exe, the WinPcap API-compatible version.
  2. How can or should NPFInstall.exe record the loopback adapter name for both versions of the driver? One possibility would be only allowing Npcap features like loopback capture and injection when using the native (i.e. not WinPcap API-compatible) driver and API.

@dmiller-nmap
Copy link
Contributor Author

@dmiller-nmap dmiller-nmap commented Apr 4, 2018

It seems I was mistaken about NPFInstall.exe vs. NPFInstall2.exe. In WinPcap API-compatible mode, the former uses the "npf" name and the latter uses the "npcap" name. I don't see that this is documented anywhere, so I might change it. This would fix the problem for anything using the npcap service, but would then introduce it for things using the "npf" service name. As I mentioned, though, this could be a satisfactory solution, limiting newer features to programs using the Npcap API, not the WinPcap API.

@dmiller-nmap
Copy link
Contributor Author

@dmiller-nmap dmiller-nmap commented Apr 5, 2018

Most likely fix for the next release will be installing the native "npcap service" version of NPFInstall.exe as NPFInstall.exe, and making NPFInstall2.exe be the WinPcap API-compatible "npf service" version. This will effectively shift the bug from the native mode to the compatible mode, which should only be used to allow legacy programs to run until they are rewritten for the Npcap API.

@fyodor fyodor transferred this issue from nmap/nmap May 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant