This brings in four discrete changes:
1. The widening of ranges for T test expressions in nmap-os-db. Any expressions
that were not already ranges were expanded to cover plus and minus five of
their original values.
2. The normalization of TG expressions in nmap-os-db. Nmap is only capable of
outputting 0x20, 0x40, 0x80, and 0xFF for a TG value, but many fingerprints
had values other than these. They have all been rounded to their nearest
likely value.
3. The elimination of the U1.TOS and IE.TOSI tests (both having to do with type
of service). This was effected by setting their MatchPoints to 0.
4. A cleanup and refactoring of OS fingerprint output code. This should not
have any impact on output, except in one case: when debugging is non-zero or
verbosity is greater than one, and at least one perfect match was found,
Nmap used to print "OS Fingerprint:" before the fingerprint. Now it prints
"TCP/IP fingerprint:" in this case like in all the others.
value of the "args" attribute.
On Windows, I created a user account with the name "Kurt Gödel". When I ran a
scan in Zenmap, Nmap created a temporary XML file that started like
<?xml version="1.0" ?>
<?xml-stylesheet href="nmap.xsl" type="text/xsl"?>
<!-- Nmap 4.75 scan initiated Wed Sep 10 11:16:58 2008 as: nmap -T4 -F -oX c:\docume~1\kurtgö~1\locals~1\temp\zenmap-bcbuy6.xml 192.168.0.1 -->
<nmaprun scanner="nmap" args="nmap -T4 -F -oX c:\docume~1\kurtgö~1\locals~1\temp\zenmap-bcbuy6.xml 192.168.0.1" start="1221067018" startstr="Wed Sep 10 11:16:58 2008" version="4.75" xmloutputversion="1.02">
Notice the ö characters in the file names. They were not in UTF-8 but probably
whatever the filesystem encoding is. Because Nmap's XML does not declare an
encoding, it defaults to UTF-8, meaning this particular file was not even
well-formed. In Zenmap it caused a crash like
CRASH REPORTED:
SYS.PLATFORM: win32
OS.NAME: nt
Zenmap Version: 4.75
TRACEBACK:
Traceback (most recent call last):
File "C:\cygwin\home\david\nmap\zenmap\zenmapGUI\ScanNotebook.py", line 387, in verify_execution
self.load_from_command(scan)
File "C:\cygwin\home\david\nmap\zenmap\zenmapGUI\ScanNotebook.py", line 400, in load_from_command
parsed = self._parse(command.get_xml_output_filename())
File "C:\cygwin\home\david\nmap\zenmap\zenmapGUI\ScanNotebook.py", line 444, in _parse
parsed.parse_file(file_to_parse)
File "C:\cygwin\home\david\nmap\zenmap\zenmapCore\NmapParser.py", line 749, in parse_file
self.parse(f)
File "C:\cygwin\home\david\nmap\zenmap\zenmapCore\NmapParser.py", line 743, in parse
self.parser.parse(f)
File "c:\Python25\lib\xml\sax\expatreader.py", line 107, in parse
xmlreader.IncrementalParser.parse(self, source)
File "c:\Python25\lib\xml\sax\xmlreader.py", line 123, in parse
self.feed(buffer)
File "c:\Python25\lib\xml\sax\expatreader.py", line 211, in feed
self._err_handler.fatalError(exc)
File "c:\Python25\lib\xml\sax\handler.py", line 38, in fatalError
raise exception
SAXParseException: c:\docume~1\kurtgö~1\locals~1\temp\zenmap-bcbuy6.xml:3:92: not well-formed (invalid token)
Plus Internet Explorer wouldn't even open it.
This change escapes the XML so it looks like
<?xml version="1.0" ?>
<?xml-stylesheet href="nmap.xsl" type="text/xsl"?>
<!-- Nmap 4.75 scan initiated Wed Sep 10 11:52:19 2008 as: nmap -PE -PA21,23,80,3389 -A -v -T4 -oX c:\docume~1\kurtgö~1\locals~1\temp\zenmap-zih7f5.xml 192.168.0.1 -->
<nmaprun scanner="nmap" args="nmap -PE -PA21,23,80,3389 -A -v -T4 -oX c:\docume~1\kurtgö~1\locals~1\temp\zenmap-zih7f5.xml 192.168.0.1" start="1221069139" startstr="Wed Sep 10 11:52:19 2008" version="4.75" xmloutputversion="1.02">
prevent error messages like: "log_vwrite: vnsprintf failed. Even after
increasing bufferlen to 819200, Vsnprintf returned -1 (logt == 1)."
Thanks to prozente0 for the report.
those that don't have a libdnet name that maps to them. This should be a help
in debugging, as it now shows all the libdnet names, all the libpcap names, and
how they all relate to each other.
dnet names to WinPcap names) to use the no-nonsense approach of simply
calling DnetName2PcapName for every interface returned by getinterfaces.
DnetName2PcapName calls intf_get_pcap_devname, which is same function
called by eth_open on Windows, so now the output really reflects Nmap's
view of the world.
This doesn't remove interface aliases, so if you have any aliases
enabled, you will see what look like duplicated lines. I have chosen to
leave them in for now to assist with debugging if any alias-related
problems come up in the future. They could be taken out easily if this
is not desired.
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-5http://www.winpcap.org/misc/faq.htm#Q-13
within a larger scan. The information is added to the XML host
element like so: [host starttime="1198292349" endtime="1198292370"]
(but of couse with angle brackets rather than square ones). It is
also printed in normal output if -d or "-v -v" are
specified. [Brandon, Kris, Fyodor]
only code left in Nmap that still uses rand() is in the Lua math
library. Perhaps at some point we'll need to expose high-quality random
numbers to Lua via our custom nmap library.
minutes. Part of what printStatusMessage does is display the total
elapsed time. The code looked like this:
log_write(LOG_STDOUT,
"Stats: %d:%02d:%02d elapsed; %d hosts completed (%d up), %d undergoing %s\n",
time/60/24, time/60 % 24, time % 60, o.numhosts_scanned - o.numhosts_scanning,
o.numhosts_up, o.numhosts_scanning, scantype2str(o.current_scantype));
where time is the number of seconds since the program started. However,
this code acts as though each hour has only 24 minutes. That is, after
0:23:59 it would become 1:00:00. This commit changes the 24s to 60s to
make it work right.
output. While those are allowed in XML attributes, they get
normalized which can make formatting the output difficult for
applications which parse Nmap XML. [Joao Medeiros, David, Fyodor]
