Log in

View Full Version : Debuggers, user experience

cli.iface
July 1st, 2009, 16:16
Hi everybody.

I have one question, that one is not related to "Where i can..." or "How to use...", i want hear what are the experience of the reversers here with some tools.Some that i couldn't find much information about who are really using it.

No, im not refering to well known tools like: IDA Pro, Ollydbg or immunity dbg.

So here the question ...

Template for the question ...
Who have been using the <stuff>, what is your experience with it, what you have done, your opinion about it?

The ERESI
eresi-project.org ("http://eresi-project.com")

The EDB ...
codef00.com ("http://codef00.com")

The radare ...
radare.org ("http://radare.org")

The rock debugger ...
rockdbg.com ("http://www.rockdbg.com")

The Rasta ring 0 debugger ...
rr0.droids-corp.org ("http://rr0d.droids-corp.org/")

Other questions

Why so many isolated projects?

Nobody likes to work together in this world? ^^

Thanks for make such community that i can find here in the woodmann forum :]
arc_
July 1st, 2009, 16:49
I have used EDB, and while it's not nearly as full-featured/polished as OllyDbg, it's still very usable. I had little trouble compiling it, and after that I could use it straight away (interface is almost identical to Olly). I don't think there's a better GUI ring3 debugger to find for Linux.

I successfully used it to do some exploit development/testing in a Linux application
cli.iface
July 1st, 2009, 17:10
Good to hear about EDB, thanks for you reply.

I would like to know your experience developing plugins, does it is easy like we do in ollydbg?
arc_
July 1st, 2009, 17:15
I haven't written plugins for Olly nor EDB, sorry.
dELTA
July 2nd, 2009, 04:51
The main developer of EDB (proxy), is a member here, so I just asked him to come around to answer your questions. Hopefully he's not on vacation at the moment, otherwise I guess you'll just have to wait a little...
proxy
July 2nd, 2009, 13:01
Yup, I'm around and more than happy to answer an questions you guys may have :-).

@arc_: I'm glad that you found EDB useful, I hope to continue to improve it so that one day is is *better* than OllyDbg ;-).

@cli.iface: developing plugins is a faily painless experience, the API has changed a little throughout the versions (since it is pre-1.0, I've toyed with a few different techniques).

Here is an example of a stubbed out plugin, it is all done using c++ and is dependant on Qt (as the rest of EDB is). There is also a little magic you'll need in the build files, nothing crazy, you can likely just mimic one of the simpler example (DumpState is about as simple as it gets).

Code:


class MyPlugin : public QObject, public DebuggerPluginInterface {

	Q_OBJECT

	Q_INTERFACES(DebuggerPluginInterface)

	Q_CLASSINFO("author", "Evan Teran"

	Q_CLASSINFO("url", "http://www.codef00.com"



public:

	MyPlugin();

	virtual ~MyPlugin();

	

public:

        // returns a menu to get added to the plugins menu 

        // (may return NULL if non is desired)

	virtual QMenu *menu(QWidget *parent = 0);



	// optional, overload these to have there contents added to a 

        // view's context menu. The return is a list of QAction objects 

        // which represent menu items

	virtual QList<QAction *> cpuViewContextMenu()		{ return QList<QAction *>(); }

	virtual QList<QAction *> registerViewContextMenu()	{ return QList<QAction *>(); }

	virtual QList<QAction *> stackViewContextMenu()		{ return QList<QAction *>(); }

	virtual QList<QAction *> dataViewContextMenu()		{ return QList<QAction *>(); }



	// optional init, overload this to have EDB run it after 

        // loading the plugin

	virtual void privateInit() {}

};


You will almost certainly want to add a "slot" to this example which is connected to one of the menu items (the only reason not to is if your plugin is "passive" and simply responds to debug events).

Finally, in the .cpp file, you will almost certainly want to include "Debugger.h" (found in debugger/include). This is because that header exposes the primary plugin API in the edb namespace. Currently all functions and objects are in the edb::v1 namespace, one 1.0 is out, that will never change again and any new functionality will be found in edb::v2 (and so on).

I've tried my best to provide a function for just about anything a plugin might need. Certainly if there is something that a new plugin will want to hook or do, I'll add a function to that (so we can avoid the binary patching that many OllyDbg plugins do).

If anyone here does make a plugin, please if possible send me the code and if I like it, it'll get added to the official tree.

Eventually all of this will be extensively documented. But for now my primary focus is the code :-D.

PS: Eventually, I'll also have tracing and "Run Until <condition>" functionality setup. Once this is done, I'll probably start to expose a Python scripting API as well since this has proven to be a very powerful tool in other debuggers. This is likely a post-1.0 feature, but just wanted to let you guys know it is in the plans...

Hope this helps,
proxy
cli.iface
July 2nd, 2009, 15:34
Thanks so much for the reply: @dELTA and @proxy

I'm talking with the masters, omg !

@proxy: From what you have said and from the experience of some edb users, i think im gonna be a edb user :]

You wrote a good thing to remember "...so we can avoid the binary patching that many ollydbg plugins do", i heard and i saw a lot of things such that when we came with the word "ollydbg".

BTW, im not a KDE user(qt library), for a long time im gnome(gtk) hehe, but for me its not a problem, seems that i'll enjoy testing a new environment while i become using the edb.

Thanks again, and sure proxy, "so that one day its better than ollydbg", if you keep going i think you will sure be in the scene.

proxy
July 2nd, 2009, 15:40
@cli.iface: keep in mind that there is no need to install KDE at all. Just Qt >= 4.2 and boost >= 1.35. As long as those are installed, it should work just fine with any desktop environment.