New concept in software protection

New concept in software protection
Secure Home | Search | About
Login Password
Register Now! Lost Password?
 General Computer Security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
New concept in software protection SoftComplete 10-07-2005
Posted by SoftComplete on October 7, 2005, 1:43 am
If you were  Registered and logged in, you could reply and use other advanced thread options
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 :

writeln('Test OK');

After compilation

mov eax, [$ 004092ec]
mov edx, $00408db4
call @WriteOLString
call @WriteLn
call @_IOTest

After the code transformation (partial):

db 3
add al, $30
xlat
call +$000025b2
jmp +$00000eec
call +$00000941
or al, $4a
scasd
call -$304ffbe9
rol eax, $14
mov edi, [ebx]
jmp +$00001738
mov ebx, eax
shr ebx, $03
push ebx
jmp +$0001b5e
call -$000001eb
jmp +$00003203
jmp +$00005df8
call +$00000910
adc dh, ah
fmul st(7)
adc [eax], al
les eax, [ecx+$0118bfc0]
stosb

http://www.strongbit.com



Posted by Volker Birk on October 7, 2005, 12:16 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
> (the protection program adds code to your program that makes
> it encrypted, compressed and debugger protected).

I'm casting doubt on the latter. And a greeting from SoftICE to you ;-)

> What are the weak points of such protection?

What are the advantages of such "protection"?

> 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.

With all disadvantages self modifying code has. But first: please proof,
that the problem is NP hard - I cannot see that yet. Beside that code
restauration maybe is not possible at all (is the relation bijective?),
usually, it's not needed anyway.

> 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.

This is wrong. If you're "protecting" only this parts, then ignoring them
by slightly modifying the rest is very easy (as usual).

> 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 :
> writeln('Test OK');
> After compilation
> mov eax, [$ 004092ec]
> mov edx, $00408db4
> call @WriteOLString
> call @WriteLn
> call @_IOTest
> After the code transformation (partial):
> db 3
> add al, $30
> xlat
> call +$000025b2
> jmp +$00000eec
> call +$00000941
> or al, $4a
> scasd
> call -$304ffbe9
> rol eax, $14
> mov edi, [ebx]
> jmp +$00001738
> mov ebx, eax
> shr ebx, $03
> push ebx
> jmp +$0001b5e
> call -$000001eb
> jmp +$00003203
> jmp +$00005df8
> call +$00000910
> adc dh, ah
> fmul st(7)
> adc [eax], al
> les eax, [ecx+$0118bfc0]
> stosb

The classical obfuscation.

Yours,
VB.
--
If class libraries are compared to animals, MFC is the slime-warts toad.


Posted by Michael Brown on October 7, 2005, 8:56 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
[snip spam]

Too bad your crackme got cracked, hmm?

--
Michael Brown
Add michael@ to emboss.co.nz ---+--- My inbox is always open




Similar ThreadsPosted
software protection techniques February 11, 2006, 6:14 am
Software copy protection March 1, 2006, 5:00 am
Total protection for your software against crack June 15, 2005, 3:15 am
Make stronger protection for your software products May 4, 2005, 2:32 am
confidentiality concept !!! April 16, 2007, 8:56 am
Concept of Route Once, Switch Many October 3, 2006, 4:30 pm
classification shceme of security concept April 2, 2007, 6:13 am
FreeMove Quantum Exchange Proof-of-Concept December 19, 2006, 7:08 am
OpenOffice proof-of-concept macro virus May 25, 2007, 5:57 pm
Forensics Software Company, Guidance Software, Hacked December 20, 2005, 10:05 pm

The site map in XML format XML site map

Contact Us | Privacy Policy