My 2 cents on code style I would like to avoid

While working on the assignment, I came across some code that took me a while to decipher. For example:

        for result in results:
            if results[result][1].is_unsaved():
                for i in range(self.scan_notebook.get_n_pages()):
                    if results[result][0] == "Unsaved " + \
                    self.scan_notebook.get_nth_page(i).get_tab_label():
                        self.scan_notebook.set_current_page(i)
            else:
                page = self._load(parsed_result=results[result][1],
                              title=results[result][1].scan_name)
                page.status.set_search_loaded()

or

        selection = self.result_view.get_selection()
        rows = selection.get_selected_rows()
        list_store = rows[0]

        results = {}
        for row in rows[1]:
            r = row[0]
            results[list_store[r][2]] = self.parsed_results[list_store[r][2]]

        return results

This stuff makes perfect sense, but only after a couple of minutes of deciphering (with possible documentation lookups). Also, it has no comments whatsoever. If we are to make Zenmap a better Nmap frontend, we need to start by improving code readability - it makes maintenance easier and allows new developers (like myself) to dig right into the code.

Zenmapper #2

Hi -- I will be working with Vladimir over the summer to improve the Zenmap interface and design for the Google Summer of Code 2008 program. I go to the University of Illinois at Urbana-Champaign, going to start my third year for B.S. in Computer Science soon. This summer should certainly be quite interesting!

Getting ready for Summer of Code 2008

Hi everyone.

I've started this blog in order to provide a centralized place for information on Zenmap development that will take place during this year's Google Summer Of Code. I will be working on various usability improvements, as well as coding the new Network Mapping mode. I will not be alone - Jurand Nogiec will also be working on improving Zenmap and making it the coolest Nmap frontend ever. :) Our efforts will be coordinated by David Fifield.

I'm currently familiarizing myself with Zenmap code and working on improving the comments on the two source files that David gave me as a small pre-SoC assignment. (I have two exams coming up, so I won't be doing anything big or interesting until after May 18.)

Here's a snapshot of my SoC application, just so you have a picture of what ideas I proposed. (My actual SoC schedule will probably include a lot of work on usability, so these ideas will probably have to wait at least a couple of weeks after coding starts.)

I am planning to integrate RadialNet into Zenmap, and implement the ideas I brought out on the nmap-dev mailing list [http://seclists.org/nmap-dev/2008/q1/0409.html]. The folks from Umit have already done some work on merging RadialNet and Umit, but the only place where it can be seen in action is the YouTube video they posted. It cannot even be checked out from SVN. However, I won't try to redo their work, as my approach as different.

I think a "Network Mapping" mode (working title) should be created. It should be accessible from the toolbar, or from the "Scan" menu. When it is invoked, a new "Network Mapping" window will open, presenting a user with an empty RadialNet workspace, and a command line at the bottom. The command line can be used to run a regular Nmap sweep (or select an existing scan profile from the list), or it can be used to invoke a "network discovery" command.

Both the idea and the mechanism behind the "network discovery" command is explained in my post to the nmap-dev mailing list [http://seclists.org/nmap-dev/2008/q1/0409.html], along with a proof-of-concept code and some ugly screenshots. Of course, it will be modified to utilize Nmap's traceroute functionality.

Now, having browsed through the RadialNet code, it lacks some key features, which I intend to add:

1. Selection tool - currently, nodes cannot be selected on the topology, so that a new scan can be run on them. By adding a new "Select Nodes" tool, it will be possible to *expand* a scan, adding information to the topology, without the need of running a new scan. Without the ability to append scan data to an already existing topology, one would have to create two separate topology graphs, which basically represent the same network but with different scan types / targets.

From the GUI point of view, I think a "Scan further..." button should become available as soon as one or more hosts are selected, presenting a user with a scan profile list, or the option of running a Command Wizard to construct the scan. As for 1337 guys, they can type something like "nmap [options] $selected" into the command line.

2. Two-way communication between the "host application" (Zenmap) and RadialNet - RadialNet currently loads its topology from an .xml file, which is only good if you want to statically interpret the scan results. You cannot do any active interaction with the topology after it's loaded (I don't count zooming and rotating as "active interaction").

A thorough two-way communication must be designed and implemented. I say "two-way", because I think we want to keep the existing Zenmap functionality useful even when running scans from the "Network Mapping" (NM) window. For example, when a first scan is run from the NM window, the Zenmap window should open a new tab which will present regular on-the-fly information. Now, let's say a user selects a few nodes on the topology graph and runs (appends) a new scan from within the NM window - a new tab opens in Zenmap window, presenting us with this scan's progress and results, and so on. Thus, we keep the original Zenmap functionality, but we empower it with RadialNet's goodness.