Fyodor got the warning
NmapOps.cc: In function âchar* filename_to_url(const char*)â:
NmapOps.cc:195: warning: comparison is always true due to limited range of data type
and later a segmentation fault.
Previously the code checked for a zero (or negative) return value, but I want
to assign some tests a value of 0 during OS scan refinement. Now it checks
errno, makes sure the entire value was consumed, and errors on negative
numbers. In addition to allowing values of 0, this change catches bogus values
where garbage follows the number.
completed hosts from the lists after two minutes. These hosts are
kept around in case there is a late response, but this draws the
line on how long we wait and hence keep this information in memory.
See http://seclists.org/nmap-dev/2008/q3/0902.html for more.
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.
