Hey Guys,
I have uploaded Nmap 4.10 to the Nmap site and will post it to the -hackers tonight or tomorrow if nobody finds any significant problems until then. This release may have to last all summer, since I'm about to make some disruptive changes (such as adding the new OS detection system). So please give it a try. Here are the goods:
http://download.insecure.org/nmap/di...p-4.10.tar.bz2
http://download.insecure.org/nmap/dist/nmap-4.10.tgz
http://download.insecure.org/nmap/di...4.10-setup.exe
http://download.insecure.org/nmap/di...4.10-win32.zip
http://download.insecure.org/nmap/di...4.10-1.src.rpm
http://download.insecure.org/nmap/di....10-1.i386.rpm
http://download.insecure.org/nmap/di....10-1.i386.rpm
http://download.insecure.org/nmap/di...0-1.x86_64.rpm
http://download.insecure.org/nmap/di...0-1.x86_64.rpm
And here are the changes since 4.04BETA1 (and then since the last formal release, 4.03):
4.10
o Updated nmap-mac-prefixes to reflect the latest OUI DB from the IEEE
(
http://standards.ieee.org/regauth/oui/oui.txt) as of May 31, 2006.
Also added a couple unregistered OUI's (for QEMU and Bochs)
suggested by Robert Millan (rmh(a)aybabtu.com).
o Fixed a bug which could cause false "open" ports when doing a UDP
scan of localhost. This usually only happened when you scan tens of
thousands of ports (e.g. -p- option).
o Fixed a bug in service detection which could lead to a crash when
"--version-intensity 0" was used with a UDP scan. Thanks to Makoto
Shiotsuki (shio(a)st.rim.or.jp) for reporting the problem and Doug
Hoyte for producing a patch.
o Made some AIX and HP-UX portability fixes to Libdnet and NmapFE.
These were sent in by Peter O'Gorman
(nmap-dev(a)mlists.thewrittenword.com).
o When you do a UDP+TCP scan, the TCP ports are now shown first (in
numerical order), followed by the UDP ports (also in order). This
contrasts with the old format which showed all ports together in
numerical order, regardless of protocol. This was at first a "bug",
but then I started thinking this behavior may be better. If you
have a preference for one format or the other, please post your
reasons to nmap-dev.
o Changed mass_dns system to print a warning if it can't find any
available DNS servers, but not quit like it used to. Thanks to Doug
Hoyte for the patch.
4.04BETA1
o Integrated all of your submissions (about a thousand) from the first
quarter of this year! Please keep 'em coming! The DB has increased
from 3,153 signatures representing 381 protocols in 4.03 to 3,441
signatures representing 401 protocols. No other tool comes close!
Many of the already existing match lines were improved too. Thanks
to Version Detection Czar Doug Hoyte for doing this.
o Nmap now allows multiple ingored port states. If a 65K-port scan
had, 64K filtered ports, 1K closed ports, and a few dozen open
ports, Nmap used to list the dozen open ones among a thousand lines
of closed ports. Now Nmap will give reports like "Not shown: 64330
filtered ports, 1000 closed ports" or "All 2051 scanned ports on
192.168.0.69 are closed (1051) or filtered (1000)", and omit all of
those ports from the table. Open ports are never ignored. XML
output can now have multiple <extraports> directive (one for each
ignored state). The number of ports in a single state before it is
consolidated defaults to 26 or more, though that number increases as
you add -v or -d options. With -d3 or higher, no ports will be
consolidated. The XML output should probably be augmented to give
the extraports directive 'ip', 'tcp', and 'udp' attributes which
specify the corresponding port numbers in the given state in the
same listing format as the nmaprun.scaninfo.services attribute, but
that part hasn't yet been implemented. If you absoultely need the
exact port numbers for each state in the XML, use -d3 for now.
o Nmap now ignores certain ICMP error message rate limiting (rather
than slowing down to accomidate it) in cases such as SYN scan where
an ICMP message and no response mean the same thing (port filtered).
This is currently only done at timing level Aggressive (-T4) or
higher, though we may make it the default if we don't hear problems
with it. In addition, the --defeat-rst-ratelimit option has been
added, which causes Nmap not to slow down to accomidate RST rate
limits when encountered. For a SYN scan, this may cause closed
ports to be labeled 'filtered' becuase Nmap refused to slow down
enough to correspond to the rate limiting. Learn more about this
new option at
http://www.insecure.org/nmap/man/ . Thanks to Martin
Macok (martin.macok(a)underground.cz) for writing the patch that
these changes were based on.
o Moved my Nmap development environment to Visual C++ 2005 Express
edition. In typical "MS Upgrade Treadmill" fashion, Visual Studio
2003 users will no longer be able to compile Nmap using the new
solution files. The compilation, installation, and execution
instructions at
http://www.insecure.org/nmap/install/inst-windows.html have been
upgraded.
o Automated my Windows build system so that I just have to type a
single make command in the mswin32 directory. Thanks to Scott
Worley (smw(a)pobox.com>, Shane & Jenny Walters
(yfisaqt(a)waltersinamerica.com), and Alex Prinsier
(aphexer(a)mailhaven.com) for reading my appeal in the 4.03
CHANGELOG and assisting.
o Changed the PortList class to use much more efficient data
structures and algorithms which take advantage of Nmap-specific
behavior patterns. Thanks to Marek Majkowski
(majek(a)forest.one.pl) for the patch.
o Fixed a bug which prevented certain TCP+UDP scan commands, such as
"nmap -sSU -p1-65535 localhost" from scanning both TCP and UDP.
Instead they gave the error message "WARNING: UDP scan was requested,
but no udp ports were specified. Skipping this scan type". Thanks to
Doug Hoyte for the patch.
o Nmap has traditionally required you to specify -T* timing options
before any more granular options like --max-rtt-timeout, otherwise the
general timing option would overwrite the value from your more
specific request. This has now been fixed so that the more specific
options always have precendence. Thanks to Doug Hoyte for this patch.
o Fixed a couple possible memory leaks reported by Ted Kremenek
(kremenek(a)cs.stanford.edu) from the Stanford University sofware static analysis lab ("Checker" project).
o Nmap now prints a warning when you specify a target name which
resolves to multiple IP addresses. Nmap proceeds to scan only the
first of those addresses (as it always has done). Thanks to Doug
Hoyte for the patch. The warning looks like this:
Warning: Hostname google.com resolves to 3 IPs. Using 66.102.7.99.
o Disallow --host-timeout values of less than 1500ms, print a warning
for values less than 15s.
o Changed all instances of inet_aton() into calls to inet_pton()
instead. This allowed us to remove inet_aton.c from nbase. Thanks to
KX (kxmail(a)gmail.com) for the patch.
o When debugging (-d) is specified, Nmap now prints a report on the
timing variables in use. Thanks to Doug Hoyte for the patch. The
report loos like this:
---------- Timing report ----------
hostgroups: min 1, max 100000
rtt-timeouts: init 250, min 50, max 300
scan-delay: TCP 5, UDP 1000
parallelism: min 0, max 0
max-retries: 2, host-timeout 900000
-----------------------------------
o Modified the WinPcap installer file to explicitly uninstall an
existing WinPcap (if you select that you wish to replace it) rather
than just overwriting the old version. Thanks to Doug Hoyte for
making this change.
o Added some P2P application ports to the nmap-services file. Thanks
to Martin Macok for the patch.
o The write buffer length increased in 4.03 was increased even further
when the debugging or verbosity levels are more than 2 (e.g. -d3).
Thanks to Brandon Enright (bmenrigh(a)ucsd.edu) for the patch. The
goal is to prevent you from ever seeing the fatal error:
"log_vwrite: write buffer not large enough -- need to increase"
o Added a note to the Nmap configure dragon that people sick of him
can submit their own ASCII art to
nmap-dev@insecure.org . If you
are wondering WTF I am talking about, it is probably because only
most elite Nmap users -- the ones who compile from source on UNIX --
get to see the 'l33t ASCII Art.
Cheers,
-F
Reply With Quote