PHASE 9 ~ Fooling Disassemblers (Protecting Applications Against Disassembly), by Snatch, 07 Dec 1997
(The "non-conditional" conditional jump and other tricks)

---

PHASE A ~ Advanced protection schemes, by tibit, 13 Dec 1997
(How to defeat us crackers at our own game :-)

---

PHASE B ~ +RCG's heavy protection, by +RCG, 13 Jan 1998 __NEW__

BTW, this doc will teach you to protect, and I will also

attach "the official HCU protector program" and then we

will wait for someone able to reverse it.

Don't worry: I will explain you how it works (I will attach 

the source as well, yet this won't help you too much from

a cracking point of view).

fravia+,



	In taking a break from putting the finishing touches on my HASP

essay (!), I took a look at +RCG's heavy.exe.  It was quite interesting

because his method has weaknesses that are similar to those I found

with the hasp encryption.  The solution, by the way, is to create a

10h byte long file called key.dat which contains 00h through 0Fh.  The

key, as +RCG tells us is too easy, but even with a completely random

key of 10h bytes it would have taken about 2 minutes to find it.  I'm

not going to explain how I figured out that it was a 10h byte string

xor'd with the code from 4012B9h to 401300h because it's fairly easy

to figure that out.  Here's how to find the key.  Isolate the

encrypted bytes in their own file, load that file in HexWorkshop, and

print it out.  You Should have something that looks like this:



00000000 6A31 6A51 2545 066D 08E1 A30A 0C0D 66F7

00000010 2041 02FC 710D EEFD 0809 0AB5 B51F 4E0F

00000020 8934 5223 4405 B906 1B49 0A20 F284 3343

00000030 2041 02BD 6025 4607 813C 422B 4C0D C90A

00000040 4421 4203 0B05 0607



Isn't it convenient how it's lined up so that the first byte of the

key is xor'd with the first byte in each of the rows, and so on with

the second, third, ....  I will refer to bytes in the grid above by

their row and column using hexadecimal and starting with 0.  So, (0,0)

is the first byte and (4,7) is the last.  Ok, here's the weakness of

+RCG's method:  he left the relocation table untouched and there are 9

relocations within the encrypted code.  A relocation entails a four

byte absolute address, usually into the data section.  IDA, to make

things convenient, tells us where these relocations are after we make

the encrypted code undefined.  We know that these addresses will start

with at least 0040 and most of them with 004020 (since that's where

the data section is).  The addresses are at: (0,0), (0,f), (1,c),

(2,2), (2,7), (2,f), (3,4), (3,a), (4,0).  Even if we assume only that

they all start with 0040, that means that we can deduce all but bytes

0, 3, 8, and b of the key right off the bat.  Working on the 004020

assumption (which is correct in all but one case) we can deduce

everything except for byte 8 (needless to say, I had seen the pattern

way before this, but I wanted to explain how it would work for any

key).  However, since we know everything else at this point it would

be fairly simple work to deduce byte 8.  I address a lot of issues

related to this in the hasp essay (they use a 1000h byte long string

for xor'ing) and suggest a more airtight protection method.



P.S.  A further consequence of +RCG's neglect of relocations is that

the program will crash if it is ever relocated by the operating

system.  This is not bound to happen to an exe, but it is extremely

likely with a dll, in which case the operating system will start

adding values to bytes within the encrypted code and that will lead to

an inevitable crash.



Later,

Quine