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