Disassemble automagically the graphical interface of any Gtk+2 program. Given a gtk+2 program, edalg should be able to create a glade2 file that mimics the GUI of this gtk+2 program.


Sometimes you use glade to prototipe an application, and then you just use the generated sources to build your application instead of using libglade to create the GUI. Some time after, you lost your original .glade file, and then you can not change anymore your interface from glade without redoing all the work from scratch.

Sometimes you just start doing a project without using glade, and when your project growns you want to switch to libglade. You have then to recreate all your GUI through glade.

Edlag is here to remove this burden from the programmer's back.


Let's assume that we can change the code of your program to build a glade file with your GUI. How can we build this glade file independently of your program internals?

The easiest way is just to use glib/Gtk+ introspection methods to query information about each and every GtkWidget on your application.

First, we should get the list of toplevel windows of your application. We can get them using gdk_window_get_toplevels. We should then pick the GtkWidgets associated to these GdkWindows, and we get them through gdk_window_get_user_data.

Once we have the list of toplevel GtkWindows, it's just a matter of getting the properties of these widgets, dump them, dump the children of these widgets (if any, and in a recursive manner), and if we have a parent, dump the packing options that were used to pack the widget. (Functions gtk_container_class_list_child_properties and gtk_container_child_get_property)

So, if you agree with me that we can build a glade file of your GUI if we're able to change the code of your application, the next step is to build this glade file without changing your application (more exactly, without changing the source code of your application).

The trick is to attach edalg to your application (as a debugger), to kidnap everything that describes the current state of the process (notably, the register values), to locate the _dl_open function in the foreign application, and to carefully place in the stack/register the values passed as arguments to this function. Once you're done, you change the EIP (or pc, npc, ...) to simulate a call to _dl_open and voila! You will make the foreign application load your favourite .so file. The .so file that interest us is one that dumps the GUI of the application (the dump will be done in the _init function, that will be called automatically by dlopen).

Once _dl_open finishes you have to reput everything as it was before. That's the tricky part, and in function of your particular architecture/unix system it may range from difficult to nearly impossible.

That will be so hard as it sounds if Shaun Clowes had not solved this problem before us (thank you!). Its injectso program contains everything we need, so I just changed it slightly to load my .so in the target process without user intervention, and that's all.


Here: http://e98cuenc.free.fr/edalg/edalg.tar.gz


N.B.: edalg will dump the GUI in the standard output of the selected application. So if you want to see anything, don't start the application from the panel, but directly from a terminal. In the future I will give the user the possibility of choice a filename to store the GUI.

Joaquin Cuenca Abela (e98cuenc at free dot fr)