Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: [GSOC] ncat gui ideaa
From: Shinnok <admin () shinnok com>
Date: Tue, 29 Mar 2011 09:24:06 +0300

On Mon, 28 Mar 2011 21:56:28 +0300, Shinnok <admin () shinnok com> wrote:
Hash: SHA1

Hi again,

I'll try to answer both Toni's and David's e-mail in a single one.

On 03/28/2011 12:26 AM, Toni Ruottu wrote:
The basic idea is really good. An Ncat gui could have many convenience
features for discussing with the service. Maybe you could define some
binary sequences as hex on forehand, and then send them at the
appropriate moment by clicking on a button. There are probably other
input related improvements that could be done in a gui. Maybe the GUI
could ship with a database of typical commands for different services.

Yes that is the point, now that I have a cool list of features that
I thought carefully about and taking in consideration your suggestions I
will share them with you guys later in this e-mail. Keep reading.

However, it would probably make sense for the ncat gui to be part of
zenmap, so you could select a port from the port scanning results, do
right click and select "interact" to open an ncat window for the
service. On the command line it is useful to have multiple commands
for different parts of nmap suite, but on the GUI side it might make
more sense to have one application for the whole suite. This would
mean using python and gtk instead of qt and c++. I am no one to decide
this. I just describe how I feel.


While this is not a bad idea, it will add to the *bulkiness* of zenmap
in my opinion. On the other hand I am well prepared to work with C++
and Qt, rebasing the idea around GTK and Python would basically rule
me out of the implementation part of the idea since I don't want to
switch bases right now. While I could of course pick up Python and GTK
in a couple of weeks that would create a little bit of implementation
overhead and eat up some of my resources that I could use with the
existing skills to work and be efficient in something that uses my
already available skills. Thus I have nothing to object against if
somebody takes this idea and implements it with Python and GTK if that
is what is best for the Nmap suite it's great, though I don't think that
would be me. :-)
On the other hand, I think this fresh C++ and Qt implementation for Ncat
will generate new horizons for Nmap, such as that if this implementation
of Ncat GUI turns out right and pleases people, then maybe the Nmap team
will be willing to consider a shot at a new GUI for Nmap written in C++
and Qt which I am happily and eager to give it a shot with or without
GSOC after the current GSOC iteration.

However, if I think better, we can still interface with Zenmap in that
pretty easily, by adding the necessary command line options to the Ncat
frontend. This way, Zenmap can call it using the appropriate argument
to initiate a Ncat window connected to an open port found during a scan.
Thus it is not really a necessity to to write the Ncat GUI using the same 
programming language and gui framework as Zenmap.

On 03/28/2011 01:44 AM, David Fifield wrote:
On Sun, Mar 27, 2011 at 01:45:33PM +0300, Shinnok wrote:
I would like to probe my idea for this GSOC iteration
for nmap against the nmap-dev list. What I am thinking
about is a GUI for Ncat, written in native C++ code
and Qt.

Hello Shinnok. Thanks for writing and for explaining your ideas in

Will the GUI support some advanced uses that use features of the shell?
To me, one of the best features of Netcat is that it behaves well as a
shell program. For example, "Chain Ncats Together" from
http://nmap.org/ncat/guide/ncat-tricks.html, and "Transfer a disk image
with compression" from

Here is a list of current feature TODO's that i have planned for
I'll paste the relevant ones here since they perfectly apply to my Ncat
* add udp support
* add pipes between sessions (tabs)
* add ssl support
* add file pipes
* run connections in a separate thread?
* add clear log
* make all strings translatable (i18n support, at least left to right
  for a start)
* add rename tab(title)
* add right click context menu on tab area and tab handles
* add sent messages history in the input text box (like a combobox)

All of them would apply to the interface for Ncat and some of them would
already be taken care of by Ncat itself like ssl or udp.

Here goes a list of Ncat specific ideas, some of them out of your
* add hexdump view for received messages
* add syntax coloring for several well known  protocols like smtp, http
  and ftp in both input and output.
* add transfer statistics (bytes sent/received, transfer speed)
  somewhere in the footer
* add customizable predefined messages(based on protocol or not)
  and message templates that can be sent with one click in the
  first case and with editing for the latter.

To me these features are enough of a justification for such a GUI for a
tool like Ncat.

Another reason that i am sending this e-mail is to probe the nmap's
team and community need for a new GUI for nmap. The ideas pointed
in this e-mail for Ncat were originally devised by me for a brand new
interface for Nmap that I would want and need. While I do realize
that Yet Another Gui(YAG) for Nmap would create fragmentation, it's
kind of fragmentation that keeps open source *secure* and diverse.
Thus, what do you think about the same ideas written above, but
for Nmap(add the mobile and embedded advantages of Qt on top)?

A Summer of Code project to make a new GUI is very unlikely. I think
people underestimate the amount of effort that goes into it.

David Fifield

That's why I think it would be great to give a GUI for Ncat a shot and
if all goes well, maybe you guys are willing to reconsider that.

All the best,

Version: GnuPG v1.4.10 (GNU/Linux)

Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/

Shinnok <http://shinnok.com>
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]