How to protect better, Essays

protec
Back to protec

project start: may 1997 ~ last update: July 1999

Courtesy of reverser's pages of reverse engineering

HOW TO PROTECT BETTER
(The long road to defeat lamers)


PHASE 1 ~ redFirst attempt, by +Rcg

PHASE 2 ~ redSecond attempt, by +Sync

PHASE 3 ~ redThe "Prefetch Instruction Queue" idea, by Camel Eater, 13 Aug 1997

PHASE 4 ~ red+Sync's second attempt solution, by +Sync, 14 Aug 1997

PHASE 5 ~ redPrefetch Instruction Queue considerations, by Heres, 16 Sep 1997

PHASE 6 ~ redPIQ + Pentium, + some general protection thoughts for the HCU, by g(ar), 21 Nov 1997

PHASE 7 ~ +RCG's Self32 saga and beyond
('course only for advanced crackers and advanced protectors :-)

self32.zip, by +RCG, 29 Nov 1997... download icname.dat AND self32.exe and crack it!
A first answer, by Zer0+ (26 December 1997)
Enjoy +RCG's self32 solution!
Here you have some tasty snippets out of it:
- Create a Self-Modificable code on the fly 
- modify VxD without restrictions
- if destination is a code segment then it is forbidden to write into it 
  and an exception is generated (and trapped... giving us the error code)

The "self32 solution" link above is at the same time the road to +RCG's new protection approach and his two splendid essays:

CRYPTOGRAPHY AND MATHEMATICS OF CHAOS!
and
A FIRST INTRODUCTION TO VxD!

In fact +RCG has opened a COMPLETELY NEW AND ADVANCED path with his two essays and with the accompaning programs and source code. Therefore I have decided to link them in an 'unusual' way, to filter lamers and newbyes a little and awaiting +RCG's updates and new promised goodies. He writes: "Soon more (but you must work on your own)" and he's right, of course. This is a WORK IN PROGRESS new section, that will -for obvious reasons- get along our new 1998 +HCU's project 'Our tool' (API monitoring and vxd magic), which starts in these days on the ristrected maillist. So you better contribute (and I mean contribute with some interesting stuff) if you want to remain on this bandwagon... to cite +RCG's words:
you must know that a VxD can do everything
we want, no more Ring3 restrictions, you can
stop completely the system, read or write any
memory address, hook all interrupts or exceptions,
take control of the IO ports

PHASE 8 ~ Flipper's Visual Basic 5 tough protection, by +flipper, 06 Dec 1997
(as the name says... tough Visual Basic 5 protection!)

You'll find inside this same protection tutorial a couple of solutions as well:
-----------------------------------------------------------------------------------
The first solution, by r0ketman (December 1997)
and an answer by flipper (December 1997)
and another solution, by +Rcg (December 1997)
and another answer by flipper (26 December 1997)

Average +HCU "deep" cracking time: three to five days :-)
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

C'mon, everyone: crack the vxd based protection scheme of this official HCU protector program!
Here is what +RCG himself writes about all this
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).
See above the Self32 saga in order to read +RCG's new CRYPTOGRAPHY AND MATHEMATICS OF CHAOS and A FIRST INTRODUCTION TO VxD essays!

Quine's Quick Qrack
And on 15 January 1998 -a day after having released +RCG's heavy protection- I have already received a quick solution by nothing less than Quine. +RCG, my friend, I believe we will have to start to prepare "specific" protections against +HCUkers... the only question is: how?
reverser,

	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

18 January 1998
Of course things do NOT finish here... and +RCG has sent some new (and very interesting) protection ideas... I'm sure that you'll find the short essay by +RCG: HOW TO PROTECT SOFTWARE BETTER - Part II very instructive. It deals, among other things, with the following questions: Purpose of the "Our protection" section; The "delayed" protection scheme of the future; The Port 70/71 trick; How to take Softice on a boat ride; Softice breakpoint magic explained and defeated.

25 February 1998
A tough assembly protection: crack_me.htm
by +Aesculapius
A beautiful, great contribution by +Aesculapius, who gathers some ideas from Madmax's letters (see below) and has prepared for you a real "cake": aescul.zip ready? steady? Go!


28 February 1998
jackrev.htm: Reversing +Aesculapius, A complete explanation of a very good assembler protection
by Jack of Shadows
A beautiful, great solution by Jack of Shadows!


01 March 1998
aescures.htm: +Aesculapius' Answer to Jack of Shadows and +Seniors
Lotta important things for protectors and crackers alike!


10 March 1998
zelazny.zip: Jack of Shadows Answer: a modified 'Aesculapius_type' advanced protection
Is getting hot interesting for protectors and crackers alike!


25 July 98 Miguel Neto ~ neto_01.htm How to crack another commercial "ready made" protection timelock protec ~ fra_0143
12 Nov 98 NiKoDeMoS ~ jn_essay.htm The New Chaos Protection protec ~ fra_0168
12 Dec 98 Tomboy ~ everlock.htm Everlock by Az-Tech: Reversing a Commercial Copy Protection Scheme - Part 1 advanced protec ~ fra_0176
09 Jan 99 Svd ~ svdcd1.htm "offline" debugging and other little marvels protec ~ fra_017C
09 Jan 99 Pilgrim ~ pilgrim2.htm Further FlexCrypt analysis protec ~ fra_017E
09 Jan 99 Indian1998+ ~ india_r1.htm Cracking a Commercial Time Trial Protection using Wdasm32 as debugger protec ~ fra_017F
20 Jan 99 +puarc ~ probet_1.htm Protection Techniques (1): How to protect your C programs protec ~ fra_0180
20 Jan 99 McLallo ~ cdromcla.htm CD-Cops ~ Another ready-made protection annihilated advanced
proj 4 protec
~ fra_0183
July 99 Black Check ~ C-Dilla Safedisc Another comercial Protection defeated advanced ~ ****


1 June 1999
antiwa1.htm: Rob's views on software protection: a game of lesser and lesser returns for time invested.
There are always going to be those with more time on their hands than you have, who crack it



protec
Back to protec

Visit the experimental message board for all people hanging around at reverser's
Ourprotections
Our Protections
OURTOOLS
Our own tools
academy
Students' essays
projunpa
Packers & Unp
dongles
Dongles lab
red_ballhomepage red_balllinks red_ball+ORC red_ballmost recent essays red_ball+HCU database
red_ballanonymity red_ballcounter measures red_ballCGI antismut red_ballcocktails
red_ballsearch_forms red_balljavascript wars red_ballAntiMicro$oft red_ballmail_fravia
red_ballIs reverse engineering legal?

red (c) Reverser, 1995, 1996, 1997, 1998, 1999. All rights reserved