mailing list archives
Re: Nmap GUI
From: Fyodor <fyodor () insecure org>
Date: Sun, 5 Jun 2005 13:34:28 -0700
On Sun, Jun 05, 2005 at 12:20:05PM +0200, "Grodås, Ole Morten" wrote:
There is a chance that one of the summer of code projects
(code.google.com) is going to be the creation of a new nmap GUI.
Excellent point! The next-generation Nmap GUI project has been by far
the most popular, with well over half of the applicants choosing it.
So now is our chance to decide what sort of GUI we really want.
Keep in mind that it is not too late to apply for Google sponsorship
if you are a student at some university and available for the summer.
The details are at:
The goal of a new GUI, IMHO, is not just to help the newbies and
casual users who have trouble remembering Nmap's (literally) hundreds
of command-line options. NmapFE already does a decent job of that. I
believe a graphical interface can be extremely powerful in a different
way than command-line. In particular, it can make real-time sorting and
browsing of results easier. The new GUI will probably take Nmap XML
input, so you'll have the option of scanning with the GUI, or using
the command line and then importing the results. Maybe the GUI can
store results in a DB, compare different runs, etc. Perhaps it could
have a history function so that you could look back and view previous
Here are some ideas and questions. I would be interested in hearing
other users' input:
o Portability - I believe that the frontend should work on UNIX,
Windows, and MAC OS X. I just don't think we have the
resources to maintain multiple top-notch GUIs. I
believe that a Windows GUI is especially important
because cmd.exe just sucks. I use bash on Cygwin
instead, but it is still hobbled by Windows
o Machine code or interpreter? People have applied to do the new
GUI in C/C++ with various libraries (Qt, GTK2, etc.), Java, Python,
and even .Net/Mono. I tend to favor C/C++ because the distributed
application wouldn't require users to download a large interpreter.
But perhaps some interpreters (Python?) may be small enough to
distribute in the installer.
o Installer -- Supporting an executable installer on Windows sounds
like a good idea to me. Windows users seem to expect that.
o Nmap XML Output -- The GUI should read at least this format, IMHO,
and possibly others. The GUI should offer to run Nmap for you
(supporting all of the major options in a well-organized serious of
tabs/dialogs), or allow you to simply import your own results.
o 3rd party libraries should be kept to a minimum for portability and
maintenance reasons. A graphical library such as GTK or Qt makes
perfect sense, but don't overdo it with tons of libraries that can
cause dependency hell.
o Searching, sorting, and drilling-down into results. It
would sort of features people would value here. Maybe I should
solicit mock-ups from the applicants to see what they have in mind.
Or maybe provide a list of tasks that should be made easy ("Find all
systems running OpenSSH", "Find all systems with port 80 open",
"Find all Solaris boxes", etc.) Anyone want to take a stab at such
o Comparing results. An option to show the differences between last
weeks scan and the one I did today would be quite valuable.
o Show the command line. One feature I like about NmapFE is that it
shows the exact Nmap command-line that will be executed as you
construct it through the options dialogue. This may help teach people
to use the command line and I feel that it should be supported unless
there is a great reason not to.
o Eye candy -- One (potential) advantage of a GUI is that it can
support pretty pictures and icons. I'm not talking about going
overboard with dancing pigs here, but unobtrusive icons can be
helpful. For example, the host list could have icons next to the
host name with a linux penguin, BSD daemon, or other
platform-specific icon. Perhaps even the services could be
deliniated in a similar way so that you easily recognize (say) ssh
daemons or mail servers in the results.
o Extensible -- the interface must be designed so that it leaves room
for growing new features later.
o Stability, security -- these go without saying.
Does anyone have other suggestions?
Also, what graphical libraries (or scripting interpreters, i suppose)
do you guys like? Anyone have examples of good cross-platform open
source GUIs we can use as a model to look at what they did right?
Sent through the nmap-dev mailing list
Re: Nmap GUI Fyodor (Jun 05)
Re: Nmap GUI digmet (Jun 06)
Re: Nmap GUI Luke Triantafyllidis (Jun 06)
Re: Nmap GUI Joshua T. Corbin (Jun 05)
Re: Nmap GUI jonathan roeder (Jun 05)
RE: Nmap GUI Víctor Chapela (Jun 05)