Re: The (eventual) unification of Nmap and Zenmap XML output

[Fyodor <fyodor () insecure org>]

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