We help IT Professionals succeed at work.

Are you an expert?

winuser2000 asked

What i want to know is if it is possible to decompile a delphi program and if so to what extent - ie: can it be decompiled back to readable code?

I don't really need to know how to do it, just the background and ways that a delphi program can be "hacked" by someone.

Any information on protection against such things will also be welcome.

A grade "A" and points goes to the person that gives me the information.
Watch Question

winuser2000, yes it is possible for you to decompile a Delphi executable but not into fully readable source code. Once decompiled, you are given, the procedures & functions used, the units used, a lot of ASM code which replaces the original code, and possible string matches from the code. No one has ever decompiled a Delphi executable back to it's original source code but there are a few programs that do what I explained above. One such example is DeDe (Delphi Decompiler) by DaFixer. If you wish to take a look at DeDe and other utilities like it please visit:
http://www.balbaro.com/dafixer/index.html and http://www.protools.cjb.net

Let me just add that in order for you to successfully decompile a Delphi execuatble with DeDe, you must be sure that it hasn't been compressed by any exe compressor (e.g. UPX, AsPack). Also, you might like to read the papers on DaFixer's website which could help you understand more on reverse engineering Delphi executables.


Thanks SenDog.  Do you know of any techniques that can be used to give anyone a headache when trying to decompile.  I know about the exe compressors but i have heard that there are programs available to undo the compression.

A usual Delphi program is so big, that disassembling always makes headaches. In the end you can't really protect your program, disassembling will always be possible somehow. But disassembling is a pain in the ass, the more the bigger the program is.

Maybe this DeDe program can split the code into functions and units, but not more. Basically you only get a bunch of assembler calls.

Regards, Madshi.
The RTTI stores many names in the EXE. The forms are simply text resources which contain all property values you entered in the IDE including the names of the events you assigned.

you can use softice software to hack any program

One way to make decompiling VERY hard is to declare your procedure names and variable names in a non-descriptive manner.  This makes debugging harder but

TForm1.SortTheUserList(Sender: TObject);
is easier to figure out than the same routine named
TForm1.Chicago(Sender: TObject);

Instead of
Var FileSizeInBytes: Integer;
Var Wolfhound: Integer;

C++ programmers love to play with Obfuscated (confusing) code like this.  

Just my opinion.

about DeDe, it can extract the code from a running process
I've used it .. it's really cool :)
so no crypter can encrypt the code to the extent that DeDe can't get it :)
but with no help cause I know squat about ASM :)
the code can't be recompiled
btw, Delphi's Optimize option in the Compiler makes it impossible to get the real code

aynway ... I suggest you use DeDe for Delphi applications
and ofcourse a good ASM book :)
ahh .. about protection ? umm .. kinda sensless
but still you can use any packer like ASPack or UPX ...

I think it might be easier to just look at how a program works and then duplicate it in delphi from scratch than to try and decompile it to asm and work from that :-)

If you are trying to find a way to keep people from playing with your exe... like altering button captions, label text, etc etc then there are ways to do that easily by encoding such data inside the exe and reading it from ram at runtime.

You could write an exe encryptor and add it to the dos stub section of the PE.... this might confuse a geek for 5 minutes or so ;-)

As best I can figure any scheme that would really add protection for an exe would have to somehow make it impossible to see the exe's image in ram as it runs... because you can reconstitute the unencrypted exe from this data.... and any software method that could protect the ram image of the exe from being read would not protect agains a hardware method of reading it.... maybe what you want to do is just not possible and the best you can do is protect your exe from easy alteration by the clueless :-/

remember that no matter how brilliant a coder you are there is probably a 'hacker' out there that will be able to crack any scheme you can devise.... that's just the way things are.

I think the basic premise here is that you can't make your code _completely_ uncrackable, but you can try to make it more trouble then it's worth.


"make it more trouble then it's worth"

Yes yes..exactly.. that sums it all up nicely :-)

That is what Micro$oft is trying to do by using that online registration for win XP.   easier to pay 99$ than to make a career out of trying to bootleg the thing.


Thanks everyone for your input on this.  I am not really trying to protect any delphi program i write against every known (and future) decompile attempt.  I am just interested in seeing to what extent a person could decompile (and thus steal code) and any ways by which to put "slow down" obstacles in their way.

Has anyone got anything to add or expand their input before i close the question and award the points?

As I mentioned before, make your variable and functions difficult to trace, this forces them to rely entirely on the ASM code to figure out what does what.  Just not worth it (as Gwena said).

I think your question has been answered. Please close the question and award the points. Thank you!


Thanks to everyone that gave input - sorry for the delay in awarding the points, i've been having problems getting back into EE for a while.

Thank you winuser2000! I hope the information I gave helped you. Good luck!

Explore More ContentExplore courses, solutions, and other research materials related to this topic.