Delphi Application Protection

Amir · 2010-08-23 21:14:24

Hi All,

Delphi forms are accessible after compiling, through a resource viewer program (e.g. Resource Hacker, Resource Builder, Restorator, etc.). this may reveal the program logic. My question is how to protect delphi application from this risk ...

some components (e.g. Bellinium Effects Citadel) provide this facility or some applications like "WTM EXE Stealth Protector", "Logic Protect EXE Creator", "Private exe Protector", "Exe Protect" and many more, help us have much secure applications, but with a heavy overhead, ofcourse Citadel works more efficiently ...

Is there any solution with the least penalty ?

Thanks.

yogiyang · 2010-08-24 10:35:38

There are many third party options available for this but unfortunately most of them are commercial offerings.

I still use SoftLox SME where needed. I still find it effective. But unfortunately executables processed in it do not work under Win7 32/64.

I am currently evaluating Enigma Protector, a software locking tool which seem to be good and it also Obfuscates code so it would not be easily possible for someone to extract data from compiled EXE.

There is a very good Open Source tool called Yoda Protector. Find it on Source Forge. It is a bit dated and is targeted especially for C/C++ coders so may not be that useful for you.

Hope this helps.

ab · 2010-08-24 11:11:03

IMHO, I don't believe it's worth investing in these tools.

For most users, using a packer (like upx, or another that you may compile by yourself) will be enough to avoid them looking inside the files.

All these "Stealth" techniques have their inverse technology. You can't count on it. Even billion dollars companies (like Blizzard) are not good enough to fight against patches and reverse engineering.

You can take a look at http://sourceforge.net/projects/tponguard if you need to make demos.

But I prefer spend time in coding some open source components...

Nowadays, the best protection system is the know-how and the support, no the code.

Amir · 2010-08-26 09:16:16

Dear Yogiyang..

Thanks..

Yoda Protector is a good and fast resource packer and protector which could be operative for most exe, dll, ocx files. it also can pack and protect delphi executables and libraries.

Please consider this article

-- Note the newer version (1.03.3), included some bug fix and improvements which had covered some issues noted in the article.

I also recommend evaluating SoftwarePassport Armadillo

Last edited by Amir (2010-08-26 09:18:57)

Amir · 2010-08-26 10:21:57

Dear Arnaud,

As you know, Delphi visual forms are encoded as DFM files and included into the executables as resources (RT_RCDATA). This implementation causes that DFMs could be simply exposed to the public, and this resource leak might be harmful in some situations.

my main question, concerns about how we can prevent this... and I prefer to do it in a delphi way, not using third parties.

I searched the web and I found many utilities designed to provide secure executables and libraries, but all of them are going to protect and compress whole of executable (or libraries) that is earned with heavy overhead. then I asked this question to find a solution with the least overhead and speed penalty.

and I made a guss it could be possible if I use a compression library (something using LZO algorithms for online decompression with no memory overhead) like "SynLZO.pas" and compress only forms and data modules with password protection, and also decomress it while initializing the forms, this causes to have a smaller executable and also provides a good security.

And I agree with you about the previous topic. but I am a novice programmer and computer studet who encountered lots of problems and questions while challenging the programming languages and utilities, and I try to find the best answer to them. so I look up the answer in some related books in hand or search the web and also post my questions to good forums. and I am not producing a software so I need no protection mechanism, I just wanted to learn and practice.

Thanks.

Last edited by Amir (2010-08-26 10:48:09)

ab · 2010-08-26 13:32:17

Could the following works?

1. create a normal exe;
2. run a tool which extract all Delphi resources from this exe, and create a dll containing them;
3. this external dll can be compressed then appended to the exe as some compressed data (LZO, but ZIP could be fast enough, and LZMA even faster - BZ2 could be used, we have a pascal bz2 uncompressor in our source code repository) - and some encryption could be added;
3. the exe has got some code which find the compressed data, create a temporary dll, then load it;
4. when the main exe search for the resource, it will also search for resources in the associated dll

You can also patch the resource loading feature of the VCL, so that these DFM will be uncompressed directly from the appended data to the exe. Then you won't have any external dll.

But any decent hacker, with any debugger, would be able to get the DFM content. It's enough putting a breakpoint after the decompression routine...

ab · 2010-08-26 14:11:42

In order to patch the resource loading feature, you'll have to overwrite this function from Classes.pas:

function InternalReadComponentRes(const ResName: string; HInst: THandle; var Instance: TComponent): Boolean;
var
  HRsrc: THandle;
begin                   { avoid possible EResNotFound exception }
  if HInst = 0 then HInst := HInstance;
  HRsrc := FindResource(HInst, PChar(ResName), RT_RCDATA);
  Result := HRsrc <> 0;
  if not Result then Exit;
  with TResourceStream.Create(HInst, ResName, RT_RCDATA) do
  try
    Instance := ReadComponent(Instance);
  finally
    Free;
  end;
  Result := True;
end;

But this function is not available from the outside.

You can get the address to patch from this code:

function InitComponentRes(const ResName: string; Instance: TComponent): Boolean;
begin
  Result := InternalReadComponentRes(ResName, FindResourceHInstance(
    FindClassHInstance(Instance.ClassType)), Instance);
end;

Which can be disassembled like this:

00420B78 53               push ebx
00420B79 51               push ecx
00420B7A 891424           mov [esp],edx
00420B7D 8BD8             mov ebx,eax
00420B7F 8B0424           mov eax,[esp]
00420B82 E8D522FEFF       call TObject.ClassType
00420B87 E8684DFEFF       call FindClassHInstance
00420B8C E8B34DFEFF       call FindResourceHInstance
00420B91 8BD0             mov edx,eax
00420B93 8BCC             mov ecx,esp
00420B95 8BC3             mov eax,ebx
00420B97 E808FDFFFF       call InternalReadComponentRes
00420B9C 5A               pop edx
00420B9D 5B               pop ebx
00420B9E C3               ret

You can get the InternalReadComponentRes address from here.

To make the patch, use the method as in LoadResStringPatch procedure of SQLite3i18n.pas unit.

mORMot Open Source

#1 2010-08-23 21:14:24

Delphi Application Protection

#2 2010-08-24 10:35:38

Re: Delphi Application Protection

#3 2010-08-24 11:11:03

Re: Delphi Application Protection

#4 2010-08-26 09:16:16

Re: Delphi Application Protection

#5 2010-08-26 10:21:57

Re: Delphi Application Protection

#6 2010-08-26 13:32:17

Re: Delphi Application Protection

#7 2010-08-26 14:11:42

Re: Delphi Application Protection

Board footer