Question

Why decompiling a delphi exe, is so easy, compared to others executables built with other programming languages/compilers?

Answer 1

There are a few things that help with reversing delphi programs:

• You get the full form data including the name of event handler methods
• All members with published visibility have metadata used with RTTI
• The compiler is pretty bad at optimizing. It does no whole program optimization and the assembly is usually a straight forward translation of the original source with only minor optimizations. (At least it was in the versions I used, might have improved since then)
• All classes, even those compiled with RTTI off have some level of metadata available. In particular it’s possible to get the name and inheritance structure of classes. And for any instance of a class you happen to see in the debugger you can get its VMT and thus its class name.

Delphi uses textfiles describing the content of your form and hooks up event handlers by name. This approach obviously needs enough metadata to deserialize that textual representation of a from and hook up the eventhandlers by name.

An alternative some other GUI toolkits use is auto-generating code that initializes the form and hooks up the event handler with code. Since this code directly uses pointers to the eventhandlers and directly assigns to properties/calls setters it doesn’t need any metadata. Which has the side-effect that reversing becomes a bit harder.

It shouldn’t be too hard to create a program that transforms a dfm file into a series of hardcoded instructions that creates the form instead. So a tool like DeDe won’t work that well anymore. But that doesn’t gain you much in practice.

But figuring out which evenhandler corresponds to which control/event is still rather easy. Especially since stuff like FLIRT identifies most library functions. So you just need to breakpoint the one you’re interested in and then step into the user code.