3

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; 
var
  x3mat: string;
  hhiTms: Interger;
begin
  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
end;

And for the messages dialog box:

procedure Tfrm_MainWindow.mxProtectorExpiration( Sender: TObject );
begin
  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;
end;

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.

PersonalNexus
  • 2,989
  • 5
  • 27
  • 42
PresleyDias
  • 364
  • 2
  • 11
  • 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 – PresleyDias Jan 09 '12 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 09 '12 at 17:07
  • @maple_shaft ,i have removed all the comments from the code, since they may be availble to decompiler, like the registry path, the big problem is when finding test cases, when they find a bug/error, tracing becomes diffcult becauase of the names, so wanted to know how should is go about the documenting such code parts like security – PresleyDias Jan 09 '12 at 17:26
  • 1
    I suggest you read [this](http://programmers.stackexchange.com/questions/89761/fellow-programmer-used-worst-programming-practices) question since it involves similar circumstances to your own. – Bernard Jan 09 '12 at 17:28
  • 2
    @Bernard - I agree, especially as obfuscation is [Doomed to failure](http://stackoverflow.com/a/6018904/42473). – Mark Booth Jan 09 '12 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 09 '12 at 20:08

2 Answers2

5

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.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
  • "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 – PresleyDias Jan 10 '12 at 09:45
5

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.

mattnz
  • 21,315
  • 5
  • 54
  • 83
  • "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 – PresleyDias Jan 10 '12 at 09:47