How to protect better, by fravia+

project start: may 1997 ~ last update: October 1998

This section is now partly obsolete
go to the HOW TO PROTECT BETTER section.

How to protect better

13 January 1998
Well, dear shareware programmers, if you feel you are advanced enough, and you understand now enough this whole cracking stuff (that is, if you have duly studied a lot of essays) you may now learn and discuss some nice tricks to block any lamer from cracking your code: +RCG has sent for instance a completely new "vxd-cryptological" approach to protecting windoze! (You'll find it inside the Self32 saga) and there is a new heavy protection -ready for you to crack and to learn from- as well :-)

14 January 1998, the day after
Well, Quine has already cracked +RCG's 'heavy' protection... :-(

18 January 1998
Well, here are +RCG's new protection ideas, among other things how to take softice on a boat ride and eventually how to punish stupid crackers... :-)
Old intro (May 1997)
Well, here we go... This whole section is a (very clever) idea from +Rcg
+Rcg's is not a native English speaker (nor am I), and therefore bear with us some language imperfections, as usual only content matters (read knowledge), form and frills may wait. This section could develop and be VERY IMPORTANT for our work, provided many of you will send contributions...

This "protection schemes" section should be very useful for shareware programmers too, in their fight against "moron-pirates" (against real crackers they have of course no chance). The survival of the shareware programmers, strange as it may seem, is OUR CONCERN, as +Rcg explains in his approach... the only enemy of humanity is Micro$oft!
This is the reason we ask SPECIALLY shareware programmers to help in this section... strange isn't it? Crackers and Shareware programmers fighting together... when the crocodile comes, cats and dogs form alliances.

Need new ideas about future protection schemes? Feel free to check our programmers' corner page as well!

(Of course the more than 200 students' essays will also offer you mighty unvaluable information in order to protect better your programs :-)

(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 :-), 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! __NEW__
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:


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) __NEW__

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 __NEW__

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?

	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.


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": 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 Jack of Shadows Answer: a modified 'Aesculapius_type' advanced protection
Is getting hot interesting for protectors and crackers alike!

12 November 1998 NiKoDeMoS' The New Chaos Protection
'Welcome to a new era of protection, via the route of chaos'

A letter by Madmax!
Not everybody agrees with "higher language" protections... here a letter I have received from Madmax! on 18 Sep 97... (I'm sure that most readers of my site know that Madmax! is NOT 'a nobody' :-)

heya fravia+,

its madmax here...i just wanted to comment on the Protecti project, many
of us crackers are a little discouraged about the format involved
here..To have such protectionists that crackers are to write a scheme in
a high level language is rather unfair i'd think...After briefly viewing
over +sync's test, i was afraid to see call after call of manipulating
code..So, i just think that any test for crackers should be written in
Assembly...To further prove my point, I could simply load up Visual
Basic 5(dont hate me for saying that =) and make a simple routine that
would be near impossible to trace...Think about it please...BTW: I
represent some cracker's from IRC also that have agreed, so consider it

see ya,
Well, what do YOU say about this matter? Any questions/advices/propositions?
Madmax! is right, as much as an assembly 'pure' good protection is much more difficult to hyde inside calls after calls of overbloated code. Yet I believe that for instance +RCG's 'heavy' protection proves that you can write a (fairly) good protection scheme in windoze, using an exe and a vxd that together sum to less than 15.000 bytes (OK, OK, I know, 15.000 bytes are quite a lot already). Besides, like it or not, most "programmers" out there would not know how to program in assembly anyway, and are lobotomized by the overbloated programming 'languages' of to-days 'frilly' trends, so they need some protection too, don't they?
Well, what do YOU say about this matter? Any questions/advices/propositions?

Here is sanity_sync's answer (15 January 1998):

I say:

your point is well stated. it makes sense not to program cracker
protections in assembly because that is not the kind of experience 
crackers need at this time (unless they are cracking dos apps).
can i make some recommendations for your protecti.htm page? 
Here's what i would like to see:

   stages of protection- ie; easy, medium, difficult, expert
   we need stages in courses like these, and we need to show
   not only HOW to write good protections, but give good SOLUTIONS,
   so a beginner can see how it was cracked, and so crackers
   can practice at whatever skill level they choose. In other
   words, not only improving the quality of the protection but
   also the quality of the cracker! a step by step will make the
   learning curve MUCH easier. 


You are deep inside fravia's page of reverse engineering, choose your way out:

The shareware programmer's corner
Our own tools
How to protect better

You may contact now +RCG using the following address:
redhomepage red links red anonymity +ORC redstudents' essays redacademy database
redantismut redtools redcocktails redsearch_forms redmail_fravia
redIs reverse engineering illegal?

red(c) Fravia & +RCG 1997, 1998. All rights reserved