Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output Conversion Flag #1784

Open
0xdade opened this issue Oct 14, 2019 · 4 comments

Comments

@0xdade
Copy link

@0xdade 0xdade commented Oct 14, 2019

I'm not familiar enough with the nmap code base to estimate the difficulty of this request, but it would be very handy to be able to retroactively convert an xml file to the normal, greppable, and s|<rIpt kIddi3 formats. So instead of running an actual scan, the call would look something like this:

nmap --convert inputscan.xml -oA outputscans

From my research, I have not been able to find a way to reliably do this right now, and it seems like having it in base nmap functionality would provide the greatest likelihood of producing accurate outputs that other tools might be expecting.

@dmiller-nmap

This comment has been minimized.

Copy link

@dmiller-nmap dmiller-nmap commented Oct 23, 2019

Thanks for the suggestion. Unfortunately, Nmap's output routines do not currently directly map internal objects to output, but instead act like a bunch of printf()-style statements sprinkled throughout the code. This means that even given a correctly-populated class object like Target from Target.h, we can't produce the same output for that object without knowing stuff about the global state like verbosity, scan options, etc.

Additionally, we would need to write an input parser for the XML, which we currently only have in Python.

@0xdade

This comment has been minimized.

Copy link
Author

@0xdade 0xdade commented Oct 23, 2019

There's an officially maintained xml parser for nmap xml output? Can you link me to that? I've been looking for that sort of thing, an authoritative parser, and could be updated. It doesn't have to be integrated directly into nmap as a feature, I just wondered if that was the path of least resistance for the project. Thanks!

@fyodor

This comment has been minimized.

Copy link

@fyodor fyodor commented Oct 31, 2019

Another thing to note is that you can ask Nmap to produce the output in multiple formats at once. Either with the explicit -oA flag or by specifying multiple options like -oX and -oN with different filenames. You can then store the other output types IN the XML so they are easy to retrieve when needed. For example, Zenmap does this when you save a scan. If you then open the XML file, you will see the normal output verbatim in an [output type="interactive"] tag. With this approach you could pass around one XML file but easily extract whichever formats you want from the file.

@0xdade

This comment has been minimized.

Copy link
Author

@0xdade 0xdade commented Oct 31, 2019

Cool, right now I'm saving XML, gnmap, and nmap files all as separate fields in my elasticsearch mapping for natlas, but was wondering if it would be more space-efficient to only render gnmap/nmap when asked for as a conversion from the XML data. Part of my goal with this is to be able to parse a bunch of host scan results from an xml document and recreate individual nmap/gnmap files as if you'd only scanned that host (which basically just means including the header and footer, I think?). I want to store per-host results as individual documents but the way the nmap and gnmap outputs are produced right now means that you lose the context of what the command run was, so I guess I'd have to copy/paste that line into each individual host nmap/gnmap data if I wanted to retain that level of information.

Then again maybe my schema could just use some work 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.