Re: Problems converting Dnet names to WinPcap

[David Fifield <david () bamsoftware com>]

On Thu, Jun 05, 2008 at 07:07:42PM -0400, Mike pattrick wrote:
> David and I have been discussing how dubious the for loop near line
> 350 of output.cc is. To recap, it is the loop that prints out the
> following information:
> DEV  WINDEVICE
> eth0 \Device\NPF_{43939745-59EC-4539-AA18-FA1950DEABD7}
> eth1 \Device\NPF_{2E9F517C-BB63-4CDC-88DC-9EE3BC9F8270}
> ...
>
> The problem is, it gets information from Dnet for the 'dev' names and
> WinPcap for the 'windevice' names and just assumes that they will be
> in the proper order(actually reverse order for some odd reason). There
> is really no guarantee that these two names will correctly line up and
> I have discovered that they sometimes get mixed up when bridging
> network devices[1].
>
> Can anyone else think of a way to properly relate a Dnet name to a
> WinPcap name?

I have been investigating this today. I explored a number of avenues.

I started by seeing what WinPcap uses to get the list of interfaces.
When using the IP Helper API, it uses the functions GetAdaptersInfo and
GetAdaptersAddresses.
        http://msdn.microsoft.com/en-us/library/aa365917(VS.85).aspx
        http://msdn.microsoft.com/en-us/library/aa365915(VS.85).aspx
These functions return enough information to match up WinPcap names, in
particular the hex GUID string. However, GetAdaptersInfo only supports
IPv4 and GetAdaptersAddresses is only available on XP and Vista. This is
not such a big deal because GetAdaptersInfo can be dynamically loaded.

I also tried using the function GetAdapterIndex
        http://msdn.microsoft.com/en-us/library/aa365909(VS.85).aspx
which takes an adapter name like "\Device\TCPIP_{...}" and returns an
index into the table of adapters. It's not too hard to extract the GUID
from a WinPcap name and build the "\Device\TCPIP_" string. I got an
implementation of this approach working. However, two things bother me
about it:
1. Old versions of WinPcap don't use the GUID names (only before Windows
   2000 I think, so it may not matter), and
2. I found the "\Device\TCPIP_" trick only by Googling, so I don't know
   if it's reliable.

Then I noticed that Nmap ships with a (very modified) libdnet 1.10,
while version 1.11 is available from http://libdnet.sourceforge.net/.
One of the changes in this version is the way names are mapped to
WinPcap names. It now matches up hardware MAC addresses. Previously it
matched up the device description strings, which didn't work at all.

The new libdnet approach seems very reasonable to me, and a step more
robust than Nmap's current approach of matching IP addresses (which of
course it could still fall back on). I recommend we bring in the 1.11
changes, or at least this one. I hacked up a quick version and it worked
fine, but then again the computer I tested it on doesn't have
complicated interfaces.

> David suggested using the DnetName2PcapName
> function, however this function relies on IP addresses, so cant return
> proper results for interfaces with no IP set; it also doesn't return
> anything for local host and handles bridged connections poorly[2].

I committed the change to have the output of the list generated by
DnetName2PcapName only. The reason for this is, that function uses
intf_get_pcap_devname, which is the same function used by eth_open to
map a dnet interface name to a WinPcap name. In other words, the
DEV/WINDEVICE output should exactly match Nmap's notion of things, even
if Nmap's notion is incomplete.

This brings what may be a startling change: the lo0 loopback interface
no longer maps to /Device/NPF_GenericDialupAdapter, but to no adapter at
all (signified by "<none>"). I believe the old behavior was wrong,
merely an artifact of the way the code happened to line up two lists of
interfaces. /Device/NFP_GenericDialupAdapter is for dialup and VPN
capture, and the loopback interface isn't supported by WinPcap (or
Windows for that matter) at all. See
http://www.winpcap.org/misc/faq.htm#Q-5
http://www.winpcap.org/misc/faq.htm#Q-13

As for bridging, I tried to bridge two interfaces and it worked fine,
although I had to restart WinPcap with "net stop npf; net start npf".
The two interfaces comprising the bridge disappeared from both
"nmap --iflist" and "ipconfig", where they were replaced by the bridge
interface.

David

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org