How to
protect better, by Fravia+
project start: may 1997
~ last
update: October 1998
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 :-)
HOW TO PROTECT BETTER
(The long road to defeat lamers)
PHASE 1 ~
First attempt, by +Rcg
PHASE 2 ~
Second attempt, by +Sync
PHASE 3 ~
The "Prefetch Instruction Queue" idea, by Camel Eater, 13 Aug 1997
PHASE 4 ~
+Sync's second attempt solution, by +Sync, 14 Aug 1997
PHASE 5 ~
Prefetch Instruction
Queue considerations, by Heres, 16 Sep 1997
PHASE 6 ~
PIQ + 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! __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:
CRYPTOGRAPHY AND MATHEMATICS OF CHAOS! __NEW__
and
A FIRST INTRODUCTION TO VxD! __NEW__
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 thisBTW, 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?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
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!
12 November 1998
jn_essay.zip: 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
please!
see ya,
madmax!
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.
sanity_sync__
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:
rcg__@latinmail.com
homepage
links
anonymity
+ORC
students' essays
academy database
antismut
tools
cocktails
search_forms
mail_Fravia
Is reverse engineering illegal?
(c)
Fravia & +RCG 1997, 1998. All rights reserved