The (eventual) unification of Nmap and Zenmap XML output

[David Fifield]

Hello,

Nmap can produce output in XML. When you save scan results in Zenmap,
they are saved in a format called USR. You may not know that USR is
almost the same as Nmap XML, with less output supported and a little bit
of extra information describing the profile and the Nmap text output.

I want to make the two formats the same, so that there is no difference
between the XML produced by Nmap and the XML produced by Zenmap. The
existing Nmap XML processors should be able to work on both. Toward that
end, I wrote this detailed comparison of the two formats:

http://www.bamsoftware.com/wiki/Nmap/ComparingNmapAndZenmapXML

It has a side-by-side annotated comparison of the two formats, followed
by analysis and recommendations for unifying them. Please give it a read
if you're interested, especially the recommendations at the end, because
that's what I'm least sure about.

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

[Arturo 'Buanzo' Busleiman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

David Fifield wrote:
| I want to make the two formats the same, so that there is no difference
| between the XML produced by Nmap and the XML produced by Zenmap. The

+1 on that suggestion. I noticed it when reviewing the zenmap chapter, and meant to mention it
but... you know.

- --
Arturo "Buanzo" Busleiman
Independent Linux and Security Consultant - SANS - OISSG - OWASP
http://www.buanzo.com.ar/pro/eng.html
Mailing List Archives at http://archiver.mailfighter.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIf+GEAlpOsGhXcE0RCtz7AJ93wKuls4vLYob2ega9PDN54zPNcACfUN5F
pH00A50l7SdHcUEqSwJj4Ko=
=Lbeh
-----END PGP SIGNATURE-----

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

[Fyodor]

On Thu, Jul 17, 2008 at 05:15:42PM -0600, David Fifield wrote:

> I want to make the two formats the same, so that there is no difference
> between the XML produced by Nmap and the XML produced by Zenmap. The
> existing Nmap XML processors should be able to work on both. Toward that
> end, I wrote this detailed comparison of the two formats:
>
> http://www.bamsoftware.com/wiki/Nmap/ComparingNmapAndZenmapXML
>
> It has a side-by-side annotated comparison of the two formats, followed
> by analysis and recommendations for unifying them. Please give it a read
> if you're interested, especially the recommendations at the end, because
> that's what I'm least sure about.

David, that is an excellent writeup and I think your recommendations
are spot on.  I'll add this to the Nmap TODO.  One aspect you didn't
mention (maybe because it is trivial) is that the merged format should
probably use a consistent file format.  Nmap already uses .xml for the
XML format when you use -oA.  That would be a good choice (and is
better than .usr IMHO).

There is also the issue of whether we will ever want Nmap itself to
include its interactive output in the XML.  If that is desireable,
we'd probably need to spread the <output> elements throughout the file
(e.g. in each host element).  And clients such as Zenmap would just
need to concatenate them all.  After all, Nmap can't insert the output
for its whole run at the beginning of the file unless it waits for the
whole scan to complete before writing the output.  And that sounds
undesireable.

The disadvantage to having Nmap store normal output in the XML file is
that it would bloat the output file size.  Here are some log file
sizes from a recent run:

-rw-r--r-- 1 root root  602720 Jul  4 13:58 initialrecon-190114-070308.gnmap
-rw-r--r-- 1 root root 2071221 Jul  4 13:58 initialrecon-190114-070308.nmap
-rw-r--r-- 1 root root 9346162 Jul  4 13:58 initialrecon-190114-070308.xml

So including normal output in the XML data might increase the file
sizes by 25% or so.

An advantage to storing this data is that tools such as Zenmap can
display it even if they didn't execute the scan and thus store the
data themselves.  And it would mean that as long as we save the xml
format version of our scans, we can always produce the normal style
output with a trivial Perl script or the like.

A disadvantage is that we'd have to implement the feature.  Or I
suppose we could just ensure the format supports that in case we
implement it later.

Cheers,
-F

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org