Articles   Members Online:
-Article/Tip Search
-News Group Search over 21 Million news group articles.
-Delphi/Pascal
-CBuilder/C++
-C#Builder/C#
-JBuilder/Java
-Kylix
Member Area
-Home
-Account Center
-Top 10 NEW!!
-Submit Article/Tip
-Forums Upgraded!!
-My Articles
-Edit Information
-Login/Logout
-Become a Member
-Why sign up!
-Newsletter
-Chat Online!
-Indexes NEW!!
Employment
-Build your resume
-Find a job
-Post a job
-Resume Search
Contacts
-Contacts
-Feedbacks
-Link to us
-Privacy/Disclaimer
Embarcadero
Visit Embarcadero
Embarcadero Community
JEDI
Links
New approach to software protection Turn on/off line numbers in source code. Switch to Orginial background IDE or DSP color Comment or reply to this aritlce/tip for discussion. Bookmark this article to my favorite article(s). Print this article
29-Dec-05
Category
Security
Language
Delphi All Versions
Views
284
User Rating
10
# Votes
1
Replies
0
Publisher:
Sergeev, Alex
Reference URL:
StrongBit
			Most of the available protection schemes use a so called ‘mounted scheme’ (the 
protection program adds code to your program that makes it encrypted, compressed 
and debugger protected). When your program is started this code unpacks, decrypts 
and adjusts your application back to its original state.

In such a case a cracker's actions are obvious: he suppresses the anti-debugging 
tricks and dumps the unpacked and decrypted application code. Then after having 
disassembled and analyzed the code, he simply needs a little patching and he gets a 
fully functional unprotected copy.

What are the weak points of such protection?

• Protection code added to an applications is usually more or less standard and 
soon or later it becomes the subject of detailed analysis. Once the security code 
is analyzed, reverse engineering of the protected application becomes a snap. In 
addition there are many automatic deprotectors that crackers can use for most 
popular protection solutions. 
• Protected code of your application is encrypted. But before it can be executed 
the protector has to decrypt it and pass the control to it. This moment can be 
intercepted by an intruder so he can get the access to the original code for 
analyzing/modification. 

EXECryptor uses a conceptually new approach to protect software applications. The 
core of the protection technology is a brand new concept of the code transformation 
called "Code Morphing". This technology protects the code on the CPU-command level. 
It is known the x86 processors command system is redundant and allows the execution 
of the same ‘code’ using various different system commands. It breaks up the 
protected code into several processor commands or small command snippets and 
replace them by others, while maintaining the same end result. Thus the protector 
obfuscates the code not on the source level but on the level of the CPU commands. 

The Code Morphing is multilevel technology containing hundreds of unique code 
transformation patterns. In addition this technology includes the special layer 
that transforms some commands into Virtual Machine commands (like P-Code). Code 
Morphing turns binary code into an undecipherable mess that is not similar to 
normal compiled code, and completely hides execution logic of the protected code.

Unlike other code protectors, there is no concept of code decryption with this 
system  Protected code blocks are always in the executable state, and they are 
executed as a transformed code. The original code is completely lost and code 
restoration is an NP-hard problem.

In addition you do not have to worry about the size or speed of your program 
because you don't need to transform its entire code. You have to protect only 
critical parts of your code, responsible for serial number verification, trial 
expiration date, and other evaluation restrictions. The rest of application code 
remains intact and software execution speed remains the same.


Below is a code sample generated by Delphi and a partial (the full listing contains 
over 500 instructions) listing of the transformed code.

Source code :
1   
2   writeln('Test OK');
3   
4   After compilation
5   
6   mov eax, [$ 004092ec]
7   mov edx, $00408db4
8   call  @WriteOLString
9   call  @WriteLn
10  call  @_IOTest
11  
12  After the code transformation (partial):
13  
14  db 3
15  add al, $30
16  xlat
17  call +$000025b2
18  jmp +$00000eec
19  call +$00000941
20  or al, $4a
21  scasd
22  call -$304ffbe9
23  rol eax, $14
24  mov edi, [ebx]
25  jmp +$00001738
26  mov ebx, eax
27  shr ebx, $03
28  push ebx
29  jmp +$0001b5e
30  call -$000001eb
31  jmp +$00003203
32  jmp +$00005df8
33  call +$00000910
34  adc dh, ah
35  fmul st(7)
36  adc [eax], al
37  les eax, [ecx+$0118bfc0]
38  stosb

http://www.strongbit.com

			
Vote: How useful do you find this Article/Tip?
Bad Excellent
1 2 3 4 5 6 7 8 9 10

 

Advertisement
Share this page
Advertisement
Download from Google

Copyright © Mendozi Enterprises LLC