Re: [GSOC] ncat gui ideaa

[Shinnok <admin () shinnok com>]

-----BEGIN PGP SIGNED MESSAGE-----
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.
>
>   --Toni

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
> > and Qt.
> > ...
>
> Hello Shinnok. Thanks for writing and for explaining your ideas in
> detail.
>
> 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
> http://nmap.org/ncat/guide/ncat-file-transfer.html.

Here is a list of current feature TODO's that i have planned for NetcatGUI:
https://github.com/shinnok/netcatgui/blob/master/TODO
I'll paste the relevant ones here since they perfectly apply to my Ncat
proposal:
* 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
languages
  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
suggestions:
* 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.
>
> 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,

Shinnok
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJNkNnSAAoJEAzuYPBIYMpXyRYH/RYp5tFJ345sHm3i3KfWX3o6
bxSIe3Br7DTelXu1EsVfH/sdWPLc51VqBSPUH8HH23sVHJZZhiHb+dpiQTyP2fnv
3cyrMEarGdSe7ZB13jpFIJGoiKZCksFXDTlcKVteAnyd5Hc4XzKArrFuqIc1t46A
g+/yAhjHqMN69pVEEJJ66SJvcI+fyiMdEWmbNrL36MwoVgfUOZyKx6YVFZzYmdnh
xVSUFjPzZvlENAwY0nHhpPqh46+ifdKtv+vqHCoFA8xDAXyjkVQ7iUT72DIXDeU8
CtPFbFbSTsVCJjVkwHUbNQKDfpzM9fJV3RaCY8jhzoBsi/M3OvpubnLDNyY0MG8=
=AsCJ
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/