mailing list archives
From: Ulisses Castro <ucastro () conviso com br>
Date: Fri, 14 May 2010 13:47:28 -0300
On Fri, May 14, 2010 at 3:29 AM, HD Moore <hdm () metasploit com> wrote:
On 5/13/2010 11:59 PM, scriptjunkie wrote:
Has anyone come forward to maintain msfgui? What issues are
unresolved? I have some ideas for improvements but wonder what the
A few folks have said they were going to work on msfgui, but we haven't
seen any code come in yet. The major issues right now:
1) Its horribly out of date. Some of the newer modules may crash the GUI
when loaded, some of the new fields (ranks) are not displayed. The
input/output drivers were tweaked a bit in the framework, and this may
have had a bad effect on the WebPipe code. It would need to be tested
and brought back into spec.
2) The Ruby-Gnome2 libraries are poorly supported via most Linux
distributions. Installing all of the required dependencies on Linux
requires a build from source on most systems, and due to the number of
requirements, this can be a huge pain.
3) The Ruby-Gnome2 libraries had some significant bugs on the Windows
platform. Notably they crashed and burned with Ruby 1.9 and the Glib
wrapper would spew assertions when an invalid file handle was passed to
the Glib "wait" methods. Additionally, any write to stdout/stderr would
crash the library when rubyw.exe was used (vs ruby.exe). There are a
pile of dirty hacks in msfgui for working around most of these, but we
never solved the file handle asserts (chased it down to a bad file
handle from the Ruby interpreter for a thread wait), nor issues with
unicode install paths, icon image support that is not XDM, or a handful
of other bugs.
4) Metasploit has moved to Cygwin 1.7 as a base platform for Windows
support, this solves a ton of problems and includes RXVT, which lets
msfconsole run natively. Any Ruby-Gnome2 support would have to compiled
against Cygwin to ship with the current installer; which has its own
issues when it comes to X11-libraries on Cygwin. The packaging process
for Ruby-Gnome2 is no fun either; post-install a bunch of batch scripts
have to be run that fix the GTK load paths. We had some old code for
this, but it would likely need an overhaul.
5) The GUI is terrible. The workflow is not there, it is basically a
giant exploit launcher with really limited options for session
interaction. We ended up punting on most of the functionality and
dropping back to a GTK console to get any work done. Very few folks
actually used the GUI in the first place; after we swapped the Windows
users to RXVT; we rarely heard requests to use the GUI.
In summary; salvaging what we have today may not be worth doing -
putting effort into a new msfweb might have better results, or at least
investigating another windowing toolkit with less issues. Since QT is
more or less free for Windows these days, a port to Ruby-QT might be a
nice change. Any new GUI work should probably start from scratch.
Ok many problems and dependencies, like you said is very dificult to mantain
it in this way, but, how about use any language to build new GUI interface
and use behind the scene XMLRPC to comunicate?
This is reliable? Is metasploit XMLRPC mature to interact with all
- msfgui scriptjunkie (May 14)
- Re: msfgui HD Moore (May 14)
- Re: msfgui Ulisses Castro (May 14)