Nmap 7.90 Released

Published: 2020-10-04. Last Updated: 2020-10-04 09:45:34 UTC
by Didier Stevens (Version: 1)
6 comment(s)

Nmap 7.90 is released, right after the release of Npcap 1.00, .

2 elements from the announcement I want to highlight:

With the production-ready and highly performant Npcap 1.00 driver included, we can finally recommend Nmap on Windows as a true peer to the traditional Linux builds.
We also did some long-needed license cleanup and gave the license a name (Nmap Public Source License) to avoid the previous confusion of Nmap being under "GPLv2 with various clarifications and exceptions". The NPSL is still based on the GPLv2, but brings in terms from some other popular open source licenses.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

Keywords:
6 comment(s)

Comments

no more network devices with npcap?

Anonymous

Oct 4th 2020
4 years ago

One thing that I have discovered since moving to a situation where work from home is 100% pertains to the use of Nmap while connected to a VPN. My company has been moving to the Microsoft Always on VPN for several reasons. The current implementation uses the SSTP protocol (Secure Socket Tunneling Protocol). SSTP does not use an Ethernet adapter, it uses a WAN miniport. Nmap does not support WAN miniports. So ... Nmap is not an option on Windows ... at least not as a Windows installation. I have found the work around. If you have a Linux instance running using WSL2 you can use Nmap from the WSL2 VM (it has to be WSL2, not WSL1). Since WSL 2 uses an actual virtual machine, that VM has a virtual NIC that is seen as an Ethernet adpater by Nmap. You can install and run Nmap in that Linux VM and you will be able to use all of the Nmap functionality that you would expect. WSL is a great thing for oh so many reasons!

Anonymous

Oct 5th 2020
4 years ago

The NMAP/NPCAP documentation says that it does support WAN Miniport adapters ( https://nmap.org/npcap/guide/npcap-internals.html ) - have you tried a connect scan (using -sT)? I've had to use that option in the past for some non-ethernet interfaces (especially VPN)

Anonymous

Oct 5th 2020
4 years ago

Maybe it will work with this new Npcap driver. I did not try with Nmap 7.9. My previous experience on attempting this was with Nmap 7.8. I had zero luck. I will check and report back. Either way I still think that it is valuable to know that with WSL you have an additional tool in the toolbox. IMHO ...

Anonymous

Oct 5th 2020
4 years ago

I tried these two scans using the Windows v 7.9 with Npcap 1.0. This scan "nmap -sT -T4 -A -v -Pn 10.x.x.x" resulted in some port discovery but the scan died after that point - "Only ethernet devices can be used for raw scans on Windows, and
"ppp0" is not an ethernet device. Use the --unprivileged option for this scan. QUITTING!Only ethernet devices can be used for raw scans on Windows, and "ppp0" is not an ethernet device. Use the --unprivileged option for this scan. QUITTING!

I tried with this scan command line "nmap -T4 -A -v -Pn 10.x.x.x" and it discovered no ports and quit immediately with the same error as above.

Then I tried this scan command "nmap -sT -T4 -A -v -Pn --unprivileged 10.x.x.x" and ended up with ports being discovered and then this error "Assertion failed: (*parent_ptr)->index == parent_idx, file src\gh_heap.c, line 98"

Nmap on WSL2 works great, giving me all the expected results without any errors ;-) You do need to know the command lines but I have setup aliases for all the common ones

alias NmapIntenseNoPing='nmap -T4 -A -v -Pn'
alias NmapPingScan='nmap -sn'
alias NmapQuickScan='nmap -T4 -F'
alias NmapQuickScanPlus='nmap -sV -T4 -O -F --version-light'

Anonymous

Oct 5th 2020
4 years ago

WSL does rock, and is a nice workaround in this case!
Raw port scans on non-ethernet adapters is hit and miss (mostly miss), but doing the scan with "-sT" uses the OS calls to make the TCP connection, it should work even over a PPP connection. Looks like you've tripped over a bug!

Tripping over pointers in C is a time-honoured and easy thing to do (speaking as someone who's coded pointers to arrays of functions, that then return pointers themselves) - and once you make a mistake (dropping or adding a "*" for instance), the harder you look the more correct your mistake looks.

The offending code (or at least the one that throws the error) in this case line 98 in this while loop:

94 while (cur_idx > 0) {
95 parent_idx = (cur_idx - 1) >> 1;
96
97 parent_ptr = hnode_ptr(heap, parent_idx);
98 assert((*parent_ptr)->index == parent_idx);
99
100 if (heap->cmp_op(*parent_ptr, hnode))
101 break;
102
103 (*parent_ptr)->index = cur_idx;
104 *cur_ptr = *parent_ptr;
105 cur_ptr = parent_ptr;
106 cur_idx = parent_idx;
107 action = 1;
108 }

I won't be debugging this anytime soon - but if any of our readers are interested and work out a code fix, let us know!

Anonymous

Oct 5th 2020
4 years ago

Login here to join the discussion.


Top of page
Diary Archives