some reason. I needed this because I got
6>LINK : fatal error LNK1104: cannot open file 'nsock.lib'
6>Build log was saved at "file://c:\cygwin\home\david\nmap\ncat\Release\BuildLog.htm"
6>ncat - 1 error(s), 1 warning(s)
the first time I built the solution after cleaning. I had to build it a second
time to let ncat find nsock.lib.
o Added the Ndiff utility, which compares the results of Nmap scans.
See ndiff/README and http://nmap.org/ndiff/ for more
information. [David]
o Fixed an integer overflow that could cause the scan delay to grow
large for no reason in some circumstances. [David]
whether a probe response counts as a drop for scan delay purposes. This avoids
an integer overflow in TIMEVAL_SUBTRACT that caused all responses to probes
retransmitted from the retry stack to be counted as drops. This would cause the
scan to grind to a near-halt, with the scan delay at 1000 ms, if even a few
hundred probes were retransmitted from the bench.
Increased max_successful_tryno for 192.168.0.190 to 1 (packet drop)
Increased max_successful_tryno for 192.168.0.190 to 2 (packet drop)
Increasing send delay for 192.168.0.190 from 0 to 5 due to 216 out of 718 dropped probes since last increase.
Increased max_successful_tryno for 192.168.0.190 to 3 (packet drop)
Increasing send delay for 192.168.0.190 from 5 to 10 due to 92 out of 305 dropped probes since last increase.
Increasing send delay for 192.168.0.190 from 10 to 20 due to 11 out of 11 dropped probes since last increase.
Increasing send delay for 192.168.0.190 from 20 to 40 due to 11 out of 11 dropped probes since last increase.
Increasing send delay for 192.168.0.190 from 40 to 80 due to 11 out of 11 dropped probes since last increase.
Increasing send delay for 192.168.0.190 from 80 to 160 due to 11 out of 11 dropped probes since last increase.
Increasing send delay for 192.168.0.190 from 160 to 320 due to 11 out of 11 dropped probes since last increase.
...
The problem was in this bit of code:
if ((!rcvdtime && TIMEVAL_SUBTRACT(probe->sent, hss->sdn.last_boost) > 0) ||
(probe->tryno > 0 && TIMEVAL_SUBTRACT(probe->prevSent, hss->sdn.last_boost) > 0)) {
the TIMEVAL_SUBTRACT(probe->prevSent, hss->sdn.last_boost) > 0) to be specific.
When a probe is retransmitted, the time it was sent is recorded in the prevSent
member of the retransmit probe. prevSent is properly set in retransmitProbe,
but it is not set in sendNextRetryStackProbe, which sends probes that have been
moved from the bench to the retry stack. The problem is that when probes are
moved to the bench they are compressed to probespecs and lose most of their
auxiliary information, like the send time. When they are retransmitted as real
UltraProbe objects, their prevSent message is left initialized to { 0, 0 }.
That led to the integer overflow, with TIMEVAL_SUBTRACT returning a nonsense
(but positive) value.
I fixed it by using TIMEVAL_AFTER(...), which works like
TIMEVAL_SUBTRACT(...) > 0 except that it is immune to integer overflows. Every
other timeval is after { 0, 0 }, so the condition is false for probes
retransmitted from the bench, as it should be. However this is not the most
correct solution. Better would be to somehow store each probe's send time with
it on the bench so it could be restored when it is retransmitted. The way the
bench and the retry stack work makes that cumbersome though, and this is the
only place prevSent is used, so I think this solution is acceptable.
did this with the idea of making diffing like scan aggregation, with known
characteristics carrying forward through unknown. But it can be confusing. I
think when you diff
nmap scanme.nmap.org
and
nmap -F scanme.nmap.org
you want to see that the gopher port changes from closed to unknown, because
it's not scanned by fast scan.
some bug fixes and precautionary measures. A 0.9.9 release is
already mentioned in their online changelog (with a whole lot
of entries), but there is no set release date that I've seen.
Tested on XP with Nmap and Ncat.
Windows and UNIX, and install/distro system for the source tarball, RPM, OS X
installer (thanks to David) and the Windows installer.
configure --without-ncat keeps it out on Unix
Something like it should remain a part of NSE, because it helped me to see what
was in the Lua stack inside GDB. I got the function from
http://www.lua.org/pil/24.2.3.html.
o A script could be executed twice if it was given with the --script
option, also in the "version" category, and version detection (-sV)
was requested. This has been fixed. [David]
file name is already in the table. Previously duplicates were only checked for
in a table that was an upvalue of the entry function, allowing duplicates to
sneak in elsewhere.
This prevents a script from being loaded twice when it is given by name, and is
in the "version" category and version detection is used.
sent to nmap-dev before the Comm update to default to bytes=1, but added after
the change. I tested the scripts out and they still work fine of course.
- not returning services in the same fashion as parse_services(protocol) did
- bad logic prevented parse_file( filename, { } ) from returning an array
of lines where filename was one of Nmap's data files (as it does for
other files)
- creating a table key with a value of nil when the pattern for the key
matches, but the pattern for the value doesn't - this was made most
obvious by the recent changes as it prevented them returning the correct
data
npf (Winpcap) service during install/uninstall. Also the silent
install mode was improved to avoid a case where the Winpcap
uninstaller was (non-silently) shown. [Rob Nicholls]
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">
involves traffic between the target and a third-party host. It's fairly
innocuous because there's no third-party traffic from the scanning computer, so
I left it in the default category.
