that they are not the default, remove duplicate dummy fules for them,
and combine the modification with an existing one for Flex/Bison removal
in NMAP_MODIFICATIONS.
/nmap-exp/david/nmap-token. This brings in the following changes:
Use a strict tryno equality test in check_tryno_pingseq. This appears to
have no effect in the current code, because the way we traverse the
probe list backwards ensures that probes with a higher tryno are tried
first. However this protects against matching the wrong tryno if that
behavior is ever changed.
Factor out the code that checks for a match of a TCP packet.
Add some extra checks when matching up TCP probes, to avoid confusing
responses to SYN and ACK probes when they are sent to the same host on
the same port, with the same tryno and pingseq, in a ping scan that
includes both -PS and -PA. I think this is the only case where there can
be confusion. The new rules are: A SYN/ACK can only be matched to a SYN
probe. A RST/ACK can only be matched to a SYN or FIN. A bare RST cannot
be matched to a SYN or FIN.
Make an important change in the way the tryno and pingseq are encoded
for TCP probes with the ACK flag set when --source-port is in effect.
According to RFC 793, responses to ACK packets on an unestablished
connection (CLOSED and LISTEN states in particular) should send a RST
response with a SEQ value the same as the received ACK value. So for
example, if it's in the CLOSED state and wants to send a RST, it sends
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
if the received packet does not have the ACK flag set, but
<SEQ=SEG.ACK><CTL=RST>
This caused a problem because in the second case, the response does not
reflect our sent SEQ value, which is where the tryno and pingseq are
encoded. The response's acknowledgement number, while not valid because
the ACK flag is not set, is typically 0. Decoding this with seq32_decode
would result in a decoding error, leading to a
Bad Sequence number from host
message. In this case the probe was allowed to match any TCP probe with
the same ports and address, even though the pingseq and tryno might be
off or the probe is a different kind of probe entirely (like a SYN
probe).
Here's a summary of what has changed, with <tryno,pingseq> standing for
an encoded tryno and pingseq.
Before:
Non-ACK probes sent with SEQ=<tryno,pingseq>, ACK=0.
ACK probes sent with SEQ=<tryno,pingseq>, ACK=random
Probes matched against ACK and ACK - 1.
Now:
Non-ACK probes sent with SEQ=<tryno,pingseq>, ACK=0.
ACK probes sent with SEQ=0, ACK=<tryno,pingseq>.
Probes matched against ACK, ACK - 1, and SEQ.
Matching against the SEQ field may also help in some other weird cases.
In the LISTEN state, the receiving TCP is supposed to check that "the
security/compartment on the incoming segment does not exactly match the
security/compartment in the TCB," and if it doesn't, return
<SEQ=SEG.ACK><CTL=RST>
just like in the ACK case. I don't know how common that sort of thing is.
o Nmap now prefers to display the hostname supplied by the user instead
of the reverse-DNS name in most places. If a reverse DNS record
exists, and it differs from the user-supplied name, it is printed
like this:
Nmap scan report for www.google.com (74.125.53.103)
rDNS record for 74.125.53.103: pw-in-f103.1e100.net
See http://seclists.org/nmap-dev/2009/q4/199 for a summary of other
minor changes to output. [David]
"base address" from which a group of addresses were derived, for example
in "scanme.nmap.org/24", "scanme.nmap.org" would be the base address.
Use these methods to set the target name of that one host even when
addresses come from a netmask.
o UPgrades to latest version of WinPcap (4.1.1)
o corrects a long-standing bug in our WinPcap installer (we surrounded
the install path in the registry with double quotes, which meant we
wouldn't uninstall our older versions during an install)
o removed the GUI option to select where the WinPcap files are
installed (all of the important ones end up in the Windows directory
anyway). WinPcap folder is installed in the same Program Files
location on x64 platforms as the official WinPcap installer uses
(although we're not sure that is the best place)
o Rob notes that he's successfully tested the installer on XP SP3,
2003 SP2 x86, Vista SP2 x86 and Windows 7 x64
