Nmap Development mailing list archives

Re: nmap in GSoC - student idea


From: David Fifield <david () bamsoftware com>
Date: Thu, 24 Mar 2011 12:28:08 -0700

On Wed, Mar 23, 2011 at 08:11:01AM +0530, Hiemanshu Sharma wrote:
So after looking completely in the way the GUI works, I have come with
a few ideas and they are listed below.

Thanks for these ideas! It's good to see that you're putting a lot of
thought into it.

1) Updating everything to current python and Qt (and also lay
foundation for a python 3 port)

What do you mean by "current Python"? We use the most recent Python 2.6
and PyGTK as far as I know. We don't use Qt at all. If we move to Python
3, we would abandon the Python 2 code completely (unless we can make the
same code work on both)--we don't want to maintain two copies of the
program.

2) Adding a new save as option to save as HTML (fancy reports are cool) 

This is a nice idea. We have documentation on making HTML reports from
XML:
http://nmap.org/book/output-formats-output-to-html.html#output-formats-html-permanent
What do you think would be the best way to do this? Fork and call
xsltproc? Or is there a convenient XSLT processor in Python?

3) Checking for targets in the GUI before even sending it to the
backend (http://i.imgur.com/TOrRQ.png shouldn't happen, it should tell
you even before it starts that its illegal)

This is a good idea. It can warn you (though color or whatever), but it
must still allow you to run any command you want. Otherwise we have to
duplicate all of Nmap's target parsing exactly in Python.

4) Also check for the options being sent to the console (this is
something that can keep changing every version but the GUI should be
patched to support the new options as well)
http://i.imgur.com/eOHam.png

This is another one where it can warn you, but it must still run exactly
the command you type. It should be possible to upgrade Nmap
independently of Zenmap. We take extraordinary measures to handle
unknown options intelligently in Zenmap: see zenmapCore/NmapOptions.py.

5) The tabs that are empty shouldn't be displayed

I'm not so sure. If I only see three tabs, for example, how will I know
how to make the others appear? How will I know when all available tabs
are displayed?

Which tabs can be empty, anyway? Sometime Topology, while not exactly
empty, shows only a single unhelpful dot if you don't enable traceroute.
But the others always display something after running a single scan,
correct?

6) Show the console output the current way but when scan is complete
show the output in a new fancy window (with the current tabs and other
stuff)

Can you make a mockup of this? It sounds like an interesting idea but I
can't picture what you're describing.

7) Add options to show new scans in a new window or the current way
(Preferences? )

Whether scans are shown in the same window indicates whether they are
part of the same aggregation.
http://nmap.org/book/zenmap-scanning.html#aggregation
I admit this probably isn't very intuitive for people. Currently, the
way to do what you describe is 1) New Window and 2) Scan. But I can see
there being an option for where you want the scan to appear, like we
have menu items "Open Scan" and "Open Scan in This Window".

8) "Where is my documentationz?" Currently there is no help that can
be seen from the GUI (This is fine for *most* linux users, but imagine
a windows user with no internet connection[doing a test on a internal
network in his basement] will have no access to the documentation, the
current man page can be put up in the help section, but it should be
there)

I agree with you. We have a Help menu option, but it just shows a short
HTML page directing you to online documentation.

It's not completely true that there is no help inside the program. In
the profile editor we have mouseover help for all the Nmap options. That
help is stored in share/zenmap/misc/profile_editor.xml.

This is just a few changes that I think the GUI needs right now, I am
sure there are a lot more stuff to be changed, but not all ideas don't
occur instantly.
Looking forward to hearing from you.

For more ideas, look in the file todo/nmap.txt for items tagged
[Zenmap]. Two that I consider high-priority, that would be great to do
this summer, are

o [Zenmap] should actually parse and use script results. See
  http://seclists.org/nmap-dev/2010/q1/1108
o Make Zenmap settings get upgraded when the Zenmap executable is
  upgraded. The per-user configuration files such as scan_profile.usp
  and zenmap.conf are never overwritten once installed by Zenmap, so
  changes and fixes to those files don't reach anyone who has
  installed Zenmap already. This is most noticeable with changes to
  profiles and highlight definitions are notably affected. This fix
  may involve hard-coding settings that are not normally configured by
  users (like highlighting) or updating the per-user files at startup
  (only those parts that haven't been changed by the user).

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


Current thread: