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
characters in the target entry (those whose UTF-8 encoding contains
a byte that counts as whitespace in the Windows locale):
File "zenmapGUI\ScanNotebook.pyo", line 184, in _target_entry_changed
File "zenmapCore\NmapOptions.pyo", line 719, in render_string
UnicodeDecodeError: 'utf8' codec can't decode byte 0xc3 in position 1:
unexpected end of data
One such character is a with grave accent, U+00E0, which in UTF-8 is
C0 A0, where the A0 is interpreted as a no-break space when the
string is interpreted byte by byte. [David]
sockaddr instead of sockaddr_storage so it got only a fraction of the
address and the inet_ntop function would look outside of the structure
into adjacent memory. A scan of localhost would look like this:
NSE: TCP ::a00:0:600:0:1234 > ::a00:4d2:0:0:25 | CONNECT
Here, for example, that 4d2 is the port number 1234 from the other
structure. Now it prints correctly:
NSE: TCP ::1:1234 > ::1:25 | CONNECT
when an attempt is made to use a file descriptor whose number is not
less than FD_SETSIZE. This applies only on non-Windows platforms
where FD_SETSIZE is a limit on the value of file descriptors as well
as a limit on the number of descriptors in the set. The error will
look like
nsock_core.c:186: Attempt to FD_SET fd 1024, which is not less
than FD_SETSIZE (1024). Try using a lower parallelism.
Thanks to Brandon Enright for discovering the problem and much help
debugging it, and to Jay Fink for submitting an initial patch. [David]
o [Ncat] Fixed proxy connections in connect mode on Windows. Because
the dup function does not work on Windows, an assertion failure
would be raised reading
(fh >= 0 && (unsigned)fd < (unsigned)_nhandle)
[David]
o [Ncat] Fixed the combination of --max-conns and --exec on Windows.
The count of connected clients was not decreased when the program
spawned by --exec finished. With --max-conns 5, for example, no more
connections would be allowed after the fifth, even if some of the
earlier ones had ended. Jon Greaves reported the problem and Venkat
contributed a patch.
o [Ncat] The code that manages the count of connected clients has been
made robust with respect to signals. The code was contributed by
Solar Designer.
to reconnect a socket with SSL because the initial communication on the socket
is done without SSL. See this thread [1] for more details.
[1] http://seclists.org/nmap-dev/2009/q4/3
