I am working on an application that I developed a security layer for. It uses the hardware ID of the hard drive, MAC address and another hardware serial key, to lock the software a particular piece of hardware.

I came across sites online, that said I should use fairly weird names for the procedures/functions/variables in the the security layer. For instance

function XtDmat: Boolean; 
  x3mat: string;
  hhiTms: Interger;
  Result := False;
  x3mat := GWindosColr;  //this returns the HD ID
  hhiTms := GalilDriverID; //this gets a controller ID
  if (t5gFx=x3mat) and (hhiTms=f4teXX) then Result := True; //match IDs with those saved in the registry

And for the messages dialog box:

procedure Tfrm_MainWindow.mxProtectorExpiration( Sender: TObject );
  lbl_Remaining.Caption := GetClassPath('xsedfers34;;''kd'); // encrypted value  decryted and shown       '0 days remained'
  lbl_Message.Caption := GetClassPath('qwe23vftTxxx ii gtr');   //decryt and show       'This license has expired'
  btn_Go.Enabled := False;

I did this because I used Delphi DEDE to decompile my code and found even the registry key 'HCKU\software\myapplication' to be in plain sight.

Now, however, it has become difficult to

  1. explain to my fellow team mates, why I did this (meaning the names),
  2. document as the names do not make sense,
  3. debug which gives me headaches.

Can anyone suggest a good way to document this type of code in this type of situation. So the code becomes easier to, but is still diffcult to decompile. Alternatively, could one suggest a obfuscator for Delphi.

  • PS : i asked this here, as i was not sure if its suitable for stackoverflow or pragrammers, but i posted it here, so i can get advice regarding interacting with teams mates in the documenting of the code Jan 9, 2012 at 17:01
  • You seemed to have done a good job of explaining it here... how is that any different than explaining it to your peers? Just explain what you did and include it in a technical specification.
    – maple_shaft
    Jan 9, 2012 at 17:07
  • 1
    I suggest you read this question since it involves similar circumstances to your own.
    – Bernard
    Jan 9, 2012 at 17:28
  • 2
    @Bernard - I agree, especially as obfuscation is Doomed to failure.
    – Mark Booth
    Jan 9, 2012 at 18:12
  • 1
    Can you clean up your spelling, punctuation and use of capital letters to make this more readable? For example, "I" is spelled "I". And sentences generally begin with Capital Letters. It's hard to get past the poor English.
    – S.Lott
    Jan 9, 2012 at 20:08

2 Answers 2


Code comments aren't available to any decompiler I'm aware of. Those are dropped on the floor either by your preprocessor or your lexer. The parser never sees comments, let alone the compiler. If you want to document bizarre code constructs, the comments are the place to do it. That way you will see them in a debugger, but not in decompiled code, and they travel with the code.

That being said, my recommendation is to just use names that make sense. People who want to defeat such measures mostly fall into two groups: those who have no idea where to start, and those for whom obfuscated names are only a minor obstacle. People in the latter group can crack most software protection in an hour or two. Obfuscation like you're talking about is going to slow them down by maybe another hour. After all, decompiled software is already obtuse.

I tell you this to encourage you to ask yourself if all this extra ongoing effort for your team is worth slowing down a cracker one time by an hour or two.

  • "The parser never sees comments, let alone the compiler" i had no idea about this ,thanks...."slowing down a cracker one time by an hour or two"..i knew that there is no ultimate security layer for the software, so i did atleast try to slow down the cracker by atleast one hour, but i ended up cracking my head over documenting it Jan 10, 2012 at 9:45

The reason you have the three problems described is that you have broken the fundamental rules for writing maintainable code. The code you have written is therefore largely unmaintainable, and rather than attempting to document yourself out of the problem (a task doomed to fail), the code should be repaired.

I came across sites online, that said I should use fairly weird names for the procedures/functions/variables in the the security layer

I hope you don't believe everything you read on the internet. Have a read of work by Bruce Schneier, particularly "Secrets and Lies" before doing anything more that makes any claims regarding security. If your security model relies on obscurity, it's fatally flawed, and if it does not need obscurity to work, then why make it impossible to maintain. If you really must have obscurity in the final, shipped code, use a pre-processor to modify the maintainable source and build the obscure program.

  • "I hope you don't believe everything you read on the internet", i think i did believe evrything, thanks for the book link,....like Karl Bielefeldt (below answer) , i originally set out to slow down the cracker or atleast give him a touch time Jan 10, 2012 at 9:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.