6

I am working in a protection schema for a software created with Delphi 7, and wondering if I need to worry about names used in functions/procedures, variables, etc. Can a "hacker" get access to these names inside a compiled exe VCL application created with Delphi without any third-party protection (ie. obfuscation)?

Jerry Dodge
  • 26,858
  • 31
  • 155
  • 327
Guybrush
  • 1,575
  • 2
  • 27
  • 51
  • 1
    Depending on how much debug information you included in (or with) your executable, they can or can't. You don't need obfuscation to hide this information, but rather need to flip the right compiler switches if you want to add it. And even then you won't get the original code back easily. That's way harder than with JavaScript for example. And then again, what is the problem if they know the names of your variables? – GolezTrol Nov 15 '19 at 17:29
  • 1
    @GolezTrol, thank you for your comment. I will research about these debug information included in the application. I don't want hackers to track down the protection schema of the software... I know there isn't a bullet proof protection, only don't want to make things easy for them... – Guybrush Nov 15 '19 at 17:42
  • 1
    I would say this is a kind of X/Y problem because only hiding function names should not make you feel your application is protected much better. Attacker can still step through the code using disassembler debugger. – TLama Nov 15 '19 at 19:10
  • 3
    I wouldn't have thought many attacks would be based on knowledge of names. If it is important to protect yourself against malicious actors then you really need to seek expert assistance. – David Heffernan Nov 15 '19 at 19:29
  • I'm kinda surprised nobody voted to close this as a duplicate - I've seen many questions asking about this on SO in the past. I guess it's a matter of searching and sifting through the results... – Jerry Dodge Nov 16 '19 at 01:40
  • @JerryDodge I think it is time to hear a new updated view on the subject. It is been a while since any one spoke about this with Delphi mentioned. – Nasreddine Galfout Nov 16 '19 at 13:51
  • @JerryDodge I found nothing specific to Delphi (7)... much of other questions are related with .NET and C++... – Guybrush Nov 16 '19 at 17:53
  • @GolezTrol, Knowing the names of functions or variables indeed helps a lot. Anyway, a cracker shouldn't rely on this, and has to assume that there is no such information available. Still, if it is there, it is a bonus. :) – Devolus Feb 14 '20 at 15:31

2 Answers2

6

Delphi compiles its source code into raw binary - in constract e.g. to Java or C#/.Net which compiles into some intermediate language, which could be easily un-compiled, and often require obfuscation. Decompilation tools for Delphi are very rough and ineffective - even the most sophisticated ones.

By default, there is no debug information added to the Delphi executable. And Delphi 7 has a limited set of RTTI - it has been enhanced a lot in Delphi 2010. Human readable RTTI information is only about enumerates text, published properties of classes, interface inheriting from IInvokable. So very little information.

So there is almost no way to retrieve the variable names and function names, from a typical Delphi 7 executable. Unless you join the .map file to the executable (only function names and global variables, not local variables).

Note that this is about the source code - as you asked. For a GUI/VCL application, .dfm content (i.e. the TForm layout) are serialized into the executable, and could be recovered.

Arnaud Bouchez
  • 42,305
  • 3
  • 71
  • 159
  • @Guybrush Long story short, figure out ways to be clever. Removing debugging info is the first step. Then there's other concepts, such as splitting an encryption key into multiple fragments defined in different places, and multiple levels of encryption, if needed. And variable encryption keys. Meaning, ones that rely on unique and permanent data. There's a whole science behind this. Your best bet is learning numerous ways of encryption and enforcing at least 3 different mechanisms of your choice. – Jerry Dodge Nov 16 '19 at 01:43
  • @Guybrush I've even used proprietary byte shifting as a level of protection - but just one layer isn't good enough when it comes to reverse-engineering. Break your mechanism into completely separate pieces. Seemingly unrelated. Tie down some unique identifier that the user cannot simply modify. Use that as part of your mechanism. – Jerry Dodge Nov 16 '19 at 01:53
  • Or consider your app at more strategic level...would hackers be interested in cracking your software? Perhaps you do not need to worry about it much especially if you offer some other benefits to registered users. But, again, all depends on the app and the user base – John Kouraklis Nov 16 '19 at 16:33
  • @JerryDodge Thank you for your comments! The price is low (~$30), so I do not think hackers would waste much time trying to break the protection...anyway, I already encrypted all the strings, used a commercial software for protecting exe against disassemblers, debuggers, memory patching, etc., also it validate the hardware where software is installed in a online database periodically. It's a very complex schema (for me), and if I need to change variable names, function names, etc., would become harder for me to manage the code... – Guybrush Nov 16 '19 at 17:49
0

As with virtually every EXE you can see which functions are imported (i.e. CreateWindowA(), SendMessageA() and such) from which libraries (i.e. SHELL32.DLL and such). Just drag your EXE into a text editor and search for .dll - around that you can see readible text.

Linking thru function names can be avoided by linking thru function indices; one approach malware does (to not let scanners recognize "bad" function names) is to enumerate all exported function names of a library, hash each name and then compare that hash with previously hashed text.

AmigoJack
  • 5,234
  • 1
  • 15
  • 31