mailing list archives
Re: [GSOC] ncat gui ideaa
From: Shinnok <admin () shinnok com>
Date: Mon, 28 Mar 2011 21:56:28 +0300
-----BEGIN PGP SIGNED MESSAGE-----
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.
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
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 NetcatGUI:
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 the
kind of fragmentation that keeps open source *secure* and diverse.
Thus, what do you think about the same ideas written above, but applied
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.
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,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
-----END PGP SIGNATURE-----
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/