But that doesn't gain you much in practice.īut figuring out which evenhandler corresponds to which control/event is still rather easy. So a tool like DeDe won't work that well anymore. 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. Which has the side-effect that reversing becomes a bit harder. Since this code directly uses pointers to the eventhandlers and directly assigns to properties/calls setters it doesn't need any metadata. This approach obviously needs enough metadata to deserialize that textual representation of a from and hook up the eventhandlers by name.Īn alternative some other GUI toolkits use is auto-generating code that initializes the form and hooks up the event handler with code. And for any instance of a class you happen to see in the debugger you can get its VMT and thus its class name.ĭelphi uses textfiles describing the content of your form and hooks up event handlers by name. In particular it's possible to get the name and inheritance structure of classes. All classes, even those compiled with RTTI off have some level of metadata available.(At least it was in the versions I used, might have improved since then) It does no whole program optimization and the assembly is usually a straight forward translation of the original source with only minor optimizations. The compiler is pretty bad at optimizing.

All members with published visibility have metadata used with RTTI.

You get the full form data including the name of event handler methods.

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

Decompiler delphi .exe to source code