time errors are not affected by this change). If verbose is 4 or greater than
a simple message is output saying what file could not be loaded due to X
library missing. If debugging is set, then the previous error message is
used.
o Zenmap no longer outputs XML elements and attributes that are not in
the Nmap XML DTD. This was done mostly by removing things from
Zenmap's output, and adding a few new optional things to the Nmap
DTD. A scan's profile name, host comments, and interactive text
output are what were added to nmap.dtd. The .usr filename extension
for saved Zenmap files is deprecated in favor of the .xml extension
commonly used with Nmap. Because of these changes the
xmloutputversion has been increased to 1.03. [David]
are the profile_name attribute of the nmaprun element, the comment attribute of
the host element, and the output element. All of them are optional so this new
DTD is backwards-compatible.
The output element is a replacement for what was the nmap_output attribute in
Zenmap. It just holds the plain text of interactive output. It can be
interpersed in chunks with the host elements, though Zenmap always writes it in
one big block.
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
