Dear Fravia,

I enjoy visiting and exploring your web pages, and thus I have to start
this message by expressing my gratitude for your efforts. 

A few years back I used to "crack" software games so that I could play
them and impress my friends (lame, I know). My favourite technique for
bypassing protection and adding functionality would be to write a
program loader that would rewrite sections of code in memory and/or
redirect calls to ones of my own design. As a very inquisitive teenager
I always wanted to improve my knowledge of how things work. Cracking
was one of my first steps into reverse engineering (something I
inherited from both my parents - reversing for knowledge and REALITY),
and it provided impetus for learning Assembly, source level debugging
(still VERY useful) high level languages, and many other disciplines I
will not bore you with - for I am sure you know what I mean.

What I am trying to get at is that software cracking has a place in the
global scope of reverse engineering; although I would prefer to see
protection essays in the line of:

<essay>

Introduction to the type of protection.

Reason why this protection is insecure (e.g. Old style Doc checks -
setting si=di defeats the protection)

Reference sample protection code - Not real apps

/* this could be in Asm, HLL, Pseudo code etc. Showing that the cracker
has reversed the protection - not only found a way past it (*1) */

Tips and tricks on spotting this type of protection, and common ways of
defeating it, thus the aim moves from bypassing protection to actually
understanding them.

Some reference samples e.g.

This type of protection can be found in "Appname1, Appname2, etc.

<\essay>

If the person reading the essay really wants to crack a specific
application, they can spend the time learning how it works as opposed
to how to make it not work.

*1 - Most protected applications are very silly in their assumptions,
for instance years back I encountered a game (Dark queen of krynn or
Lands of lore, I can't recall which one) that encrypted the doc
checking code with a silly XOR cipher or something similarly stupid.
Now I could have analyzed the cipher and worked on cracking the key and
algorithm. OR I could have (and I did :-) trace to a point in the code
where the checking code was deciphered and THEN patch the checking
code. Therefore even if the programmers employed the toughest
encryption and used the longest random key possible (very long :-) and
it took 10^10^80 years (VERY, VERY long time) to brute force the key,
the protection would still be weak and I think people should know why a
protection fails even when built with tried and tested methods,
analogy: A house built from the toughest bricks will not outlast the
storm when the mortar consists of sand and spit. 

I love the reality cracking sections (including Auntie Annie's) and
hope to write a reality cracking essay one of these days.

What I am trying to convey is that we should crack ideas, schemes and
protocols. Not apps.

Andre

Nom de plume withheld; because it's silly %-].

Andre at oas point co point za