How could I protect my delphi app from being decompiled? I know there are some software like themida that I think will do that but then the protected exe trigger the antivirus.
+10
A:
It depends what your goal is.
If it's really just protecting the source, it's already done! Provided you don't include debug and symbols information and add some heavy inlining, good luck to reconstruct some usable Pascal code from disassembling the exe.
If it's preventing people from seeing how it functions and hack it, then you have to include some anti-disassemble protection. It's harder but doable. Often done as a collateral to anti-piracy protection.
François
2009-12-18 05:13:09
Really, is hard to decompile and read pascal code? I tought it was easy like c#, I even saw a few decompilers out there.
Sebastian
2009-12-18 05:29:44
It's hard. All decompilers I know about can reconstruct the interface section of the units. The implementation section cannot be decompiled - all people would get are asm statements, and for the vast majority of people it would be easier to just write everything from scratch than to figure out what's going on.
Mihai Limbășan
2009-12-18 06:28:47
Sebastian have you actualy tried that decompilers? You would see that they give you no actual code. There is nothing to compare in terms of decompilation between C# and Pascal. C# assembly is firstly stored in a CIL form. That is why it is so easy to "decompile" it. It is not compiled to the processor language until you run the assembly.
Wodzu
2009-12-18 07:41:14
@Mihai: The interface section usually does not produce code, so that does not make sense. Anyway, you always need to pick a protection level. For many purposes, assembler statements are good enough.
Lars D
2009-12-18 07:41:49
+1 to Wodzu. It is the fact that .NET is stored in an IL, more than that it is C#. NGENed C# might be badly decompilable too
Marco van de Voort
2009-12-18 15:24:13
@Lars: That actually makes a lot of sense - have you tried a Delphi decompiler? The output binary from the Delphi linker contains enough artifacts to reconstruct the units used. Each of the decompiled units will contain an interface section with the declaration of all types compiled in the {$M+} state (either explicitely or by deriving from a type compiled int hat state - and many types derive from TPersistent which has RTTI on). Depending on other compiler switches and on knowledge of the RTL internals, you can get almost all definitions. The implementation section will contain ASM routines.
Mihai Limbășan
2009-12-21 18:46:24
@Lars: It may be difficult to get across what exactly a Delphi decompiler produces. The easiest way would be to try it :) The DeDe decompiler is the best I know of (doesn't work for recent Delphi versions but you can get a good idea about what's going on.) I'll avoid linking it here to avoid potential legal exposure for StackOverflow, but a Google search for "dede decompiler" will yield the proper result in the first couple of links.
Mihai Limbășan
2009-12-21 18:50:13
+3
A:
Everything that a CPU can read, can also be "decompiled", so there is no ultimate security. But usually it is quite hard to decompile compiled Delphi code, and almost all identifiers and all comments are gone, of course.
The published parts of classes, DFM file information and constants (including string constants) are present in the exe file, in an easily readable way. You can reduce this problem by encrypting your strings and not using published and not use DFM files. However, all the information will still be present in your exe file, so often this will just be hard work that gives no real security.
If you just want parts of your source code to be difficult to read, make your algorithms difficult...
In the end, everything can be hacked. The only real way to avoid your app from being decompiled, is to keep the exe file away from those that can do it, like when you deploy it on your own server but not on the customer's server.
Lars D
2009-12-18 06:45:06
"If you just want parts of your source code to be difficult to read, make your algorithms difficult..." That sentence made me laugh. Now that's the best excuse for people writing unreadable and bad code...for sake of security :D
Smasher
2009-12-18 09:40:30
@Smasher: I couldn't stop smiling when I wrote it! But unfortunately, it's true.
Lars D
2009-12-18 11:44:11
A:
Only applications protected with stolen Themida keys should trigger an antivirus (Win32.Black detected by Kaspersky for example).
FractalizeR
2009-12-18 08:13:09
+3
A:
If you're using Delphi Prism then one of the many .Net decompilation tools will make it a trivial task to get access to (a form) of your source code.
The only solution is to use one of the numerous .Net obfuscation tools. Unfortunately I can't make a recommendation as I've never had to use one, but Google should show you the way...
If you're compiling to native Win32 then any form of obfuscation, or even anti-debugging mechanism, is pretty much a waste of time. There are people out there who can read assembly as easily as you or I read our native language. These things only slow the reverse engineering process down somewhat (and only barely at that).
davea
2009-12-18 08:40:53
A:
In general, you cannot really protect your code from decompilation. However, by using a tool such as Code Virtualizer you can protect key areas, such as your install code decoder. Code that is virtualised is much slower, and has certain restrictions, but it adds a suitable hurdle to the casual hackers trouble. This is best done in a build script so that it is consistently added for release - that way you ensure proper protection every time.
I recommend separating the install code from the protection BTW, so that you can switch protection at any time without worrying about existing users.
Finally, Delphi forms are easily accessed, but they are generally not useful to change.
mj2008
2009-12-18 09:12:12
A:
A complete disassembly is never achieved I think for native Win platform. If you don't include debug symbols etc during compile time or hide these using some tool, it's very unlikely your exe could be decoded. No idea about .NET thing.
http://stackoverflow.com/questions/1606548/decompiling-code-language-independent/1606940#1606940 gives an impressive list about how far decompilation goes with a free tool already
mjustin
2009-12-18 13:23:56
A:
Few years ago, I've had to rewrite an application, what abandoned by its developer.
I can recover all things from DFM-s, Forms (with components) Query strings stored in TxyzQueries, bitmaps from image lists, some strings with decompiler, but application logic can not be recovered, only method names with asm source inside.
There are loaders (like UPX http://upx.sourceforge.net), what extracts crypted, compressed application to memory and loads it on start, but the AV's often marks such applications as infected. :(
You can write a small app like that, some tips:
www.codeproject.com/KB/cs/LoadExeIntoAssembly.aspx (.net) www.joachim-bauch.de/tutorials/load_dll_memory.html (for dll-s)
zschopper
2009-12-18 11:07:10
I've had a lot of antivirusses trigger on UPX too. Mostly notably a version of the GNU linker. (something encrypted that poops out binaries? Must be a virus). The correct way is probably turn off all heuristics checks. These are responsible for the bulk of the false positives.
Marco van de Voort
2009-12-18 15:25:25
A:
An easy way to protect the executable is to run it as a web application on an Internet server. With Delphi and an Ajax library (for example ExtJS over extpascal, or IntraWeb/VCL for the Web), it is possible to convert desktop and client/server applications to web applications. (Examples) - this also makes the application available for other operating systems and mobile devices.
mjustin
2009-12-20 09:35:32