proposal. This only affects Nmap's root directory. We might also need to
modify the code which autogenerates Nmap's source code files such as IPv6
fingerprinting code.
for file in `grep "* including the terms and conditions of this license text as well. \*" * -r --files-with-match `; do sed "s/\* including the terms and conditions of this license text as well. \*/* including the terms and conditions of this license text as well. */g" -i $file; done
This is a refactoring of target parsing that stores different types of
target specifications as different classes. The eventual intention is to
allow easy iteration over each specification for the purpose of IPv6
multicast host discovery.
This is simple IPv6 unicast ranges. For example,
nmap -6 en.wikipedia.org/120 -sn
The other, more complicated part of this overall change is automatic
multicast scanning of large local subnets. That part isn't done yet.
This is the way it worked for IPv6 (with the exception of a slash in an
IPv6 address, which has also been made into a warning)--warn about the
bogus specification and carry on with the other targets.
The main use for this is preventing the whole scan from being stopped
when a bad specification appears in a hostgroup after the first.
You could use "-e en0" to automatically add scope ids to your IPv6
addresses, so you didn't need the write "fe80::1234%en0". But this only
happened for the route_dst calculation, and could lead to later failures
in sendmsg when the address didn't have a scope id.
Some function declared parameters like this:
int f(const char * const s)
Where appropriate, I changed to
int f(const char *s)
The second const is a qualifier on the pointer itself; i.e., the value
of s may not be changed (may not be made to point to anything else)
within the function. This is probably not what was intended. The first
const is what prevents modifying things referenced through s.
unspecified and causes a segmentation fault on Android Bionic libc.
Vlatko fixed the bug in his Android binaries and it was first reported
by @alexismm2.
as for IPv4. This makes the output more uniform and gives NSE access to
host.targetname for IPv6 hosts.
This is what IPv4 output looks like:
$ nmap -sL www.kame.net
Nmap scan report for www.kame.net (203.178.141.194)
rDNS record for 203.178.141.194: orange.kame.net
Nmap done: 1 IP address (0 hosts up) scanned in 0.16 seconds
$ nmap -sL www.debian.org
Nmap scan report for www.debian.org (128.31.0.51)
Other addresses for www.debian.org (not scanned): 206.12.19.7
rDNS record for 128.31.0.51: senfl.debian.org
Nmap done: 1 IP address (0 hosts up) scanned in 0.17 seconds
Here is the output before this change. Notice that the target name is
missing and there is no separate "rDNS" line.
$ nmap -6 -sL www.kame.net
Nmap scan report for 2001:200:dff:fff1:216:3eff:feb1:44d7
Nmap done: 1 IP address (0 hosts up) scanned in 0.04 seconds
$ nmap -6 -sL www.debian.org
Nmap scan report for bellini.debian.org (2607:f8f0:610:4000:211:25ff:fec4:5b28)
Nmap done: 1 IP address (0 hosts up) scanned in 0.11 seconds
Here is the output after this change:
$ ./nmap -6 -sL www.kame.net
Nmap scan report for www.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7)
Nmap done: 1 IP address (0 hosts up) scanned in 1.04 seconds
$ ./nmap -6 -sL www.debian.org
Nmap scan report for www.debian.org (2607:f8f0:610:4000:211:25ff:fec4:5b28)
rDNS record for 2607:f8f0:610:4000:211:25ff:fec4:5b28: bellini.debian.org
Nmap done: 1 IP address (0 hosts up) scanned in 0.07 seconds
resolve except that it returns all resolved addresses. Use this new
function to resolve IPv4 addresses instead of gethostbyname in
TargetGroup.cc. The gethostbyname code assumed that only IPv4 addresses
would be returned. If the resolver returned IPv6 addresses, TargetGroup
would blindly copy the first four bytes of the IPv6 address into the
IPv4 struct. This was first reported by Mats Erik Andersson at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584301; he also
suggested the fix.
report. It looks like this.
$ ./nmap google.com -sn
Starting Nmap 5.30BETA1 ( http://nmap.org ) at 2010-05-10 23:57 MDT
Nmap scan report for google.com (66.102.7.99)
Host is up (0.073s latency).
Other addresses for google.com (not scanned): 66.102.7.104
rDNS record for 66.102.7.99: lax04s01-in-f99.1e100.net
This replaces the line
Hostname google.com resolves to 2 IPs. Only scanned 66.102.7.99
group. Not doing this was the cause of off-by-one errors that led to
assertion failures and, potentially, excluded hosts being scanned. Here
is the comment I added:
/* The decision to skip a range was based on the address that came immediately
before what our current array contains now. For example, if we have just
handed out 0.0.0.0 from the the range 0-5.0.0.0, and we're asked to skip
the first octet, we want to advance to 1.0.0.0. But 1.0.0.0 is what is in
the current array right now, because TargetGroup::get_next_host advances
the array after returning an address. If we didn't step back we would
erroneously skip ahead to 2.0.0.0. */
"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.
