The Nmap GUI after a user that has performed his first scan. All advanced features are strip away to make it less confusing to new users
The result browser has to display all information that nmap supports, Where possible icons should be used. Different colors for open, closed and filtered ports and an entry that tells the state of ports that is not listed might be a good idea.
Adding support for searchable comments is a good idea. Using the new interview framework in QT4 and splitting comments up in a separate column. An example of how the widget can look can be found her (the image in the middle)
I believe there are many cases where people would want to run multiple scans simultaneously. A good example is scanning a big network with low timings and finding something of interest. In this case you can just start a new scan to check it out.
A saved configuration of all Nmap options. The GUI will come with some predefined.For advanced users it will be possible to change these or make new ones.
I really liked the way treeviews were used in Languard. Se example screens shot. Treeviews take less space than other views. I makes it easier to get an overview of the results and it makes it easier to compare scans manually side by side.
The first time you open the result manager there will only be the history entry. For more advanced use it will be possible to divide the network in to segments and make appropriate names for the segments. A segment will be a range or list of ip addresses.
There will be different ways to sort the results. The default will be to sort by date. Another option will be to sort by the scan template used to perform the scan. Sorting by scan template is a good idea because it makes the most sense to compare results done with the same nmap options.
By right clicking you should get a repeat scan option
Here you can change all the options nmap supports. This will propably not be the final arrangement of the options. It is just a sketch to demonstrate how I want the GUI to look. Adding icons to the menu migth be a good idea
I believe that the ability to search and analyze results is what is going to make the nmap GUI really useful. Using databases to store the results will greatly improve search speeds and make it easier to implement the search functions. This is the main reason why I have chosen to exclusively store the results in databases.
This will be the most complex GUI widget because it needs to combine two view widgets.
First you choose a result. Then you choose one or more results to compare it to.
Hidden by default to avoid confusing new users. By checking the checkbox oldschool nmap users can enter nmap commands manually.
After careful consideration I have found Qt4 and C++ to be the best tools to build the GUI. Some of the reasons for choosing QT/C++:
NOTE: Trolltech has decided that QT4 shall be released under the GPL license for the following operating systems: Windows, Linux and Mac
My opinion is that if you want the GUI to have advanced search, sort and compare functons the best solution will be to save results in a database.
After some discussion on namp-dev I have come to the conclusion that adding db support to nmap is not a good idea. Therefore the db code has to be included in the GUI Fronted. Having the GUI Frontend read xml output from nmap and saving it in a db is a good solution, except when you want to run regular scans from cron.d. This problem can be solved by making a small nmap2db command line tool, using the xml to db code from the GUI Fronted
You could then run nmap commands like this:A proposal to the database layout
NOTE: SQLite operator parser has support for REGEXP. There is no function to back up this operator in the standard build but users can add their own using sqlite3_create_function(). There are working REGEXP functions for SQLite but I believe it might be a good idea to build our own using libpcre. MySQL has built inn support for REGEXP.
