Ivan Bilibin:

A good protection is NOT an impossible dream!

How to (try to) protect software effectively

[Mark's] ~ [Tidbit's]
[Stone's] ~ [More tips]
[To shrink?]
[tricks] ~ [links]

(Last update: October 1999)

Software Protection, an impossible dream?
An introduction


I would like to start, with this section of my site, a good "special" reversing laboratory for software protection. As my readers know, we have already tried this some time ago with the Our Protections section. Yet that section didn't seem to florish, so I'm now re-organizing various 'threads' into a coeherent "software protection" project. I hope that this will help reversers and protectors alike... no cracker should underestimate the difficulty (and the beauty) of writing a good protection, exactly as no protector should underestimate the difficulty (and the beauty) of reversing a difficult snippet of software. Cracking and protecting are two very important sciences in their own right, but I have noticed that the development of good protections suffers a 'psychological' penalty. "There's no point in protecting or overprotecting: a determined cracker can crack any protection!"; "nothing can guarantee absolute security"; "Any protection scheme can be defeated"; "protection measures can be easily worked around", and so on and so on... stalk the protectors on usenet and you'll see this kind of typical whining.
Well, any protection scheme can be cracked... may be. Yet let's devise schemes that will make things a lot HARDER for the typical cracker to mess with... and who better than some good +crackers can teach protectors how to protect?
It's almost winter, snow is in the air! C'mon: let's push another snowball down the Webhill!

Software Protection, an impossible dream?
All the advices you may need


protec Mark's famous 14 protector's commandments

protec Tidbit's 'common sense' rules

protec More tips you might take into consideration


Software Protection, an impossible dream?
The Shrinkers discussion

On Richard Fellner's page I found this snippet:
Don't rely on "EXE-packers". For almost any tool which compresses EXE files
(Shrinker, WWPack32, NeoLite - to list the most popular ones) there's an
uncompressor around, so compressors capable for software-protection
should at least support configurable encryption. Unpackers for the above (and
other) tools are not very wide-spreaded, however, don't rely on them as your
program's one and only "protection"!
Now the question is: is this true?

A shrinker, like the one from Blinkinc should be seen as a 'first line of defense' for a protector. The application will be uncompressed when it is loaded and cannot therefore be decompiled from disk. This makes the possibility to mess with it a little more complicated for the cracker, especially if, after having compressed the application with Shrinker or with WWpack32 you checksum (twice) the compressed EXE.

The standard binary post-processors seem at the moment to be:
and WWrap32
And for these shrinker there are corresponding unshrinkers in the scene... where are they?
Well, a first good tool (yet not for beginners) is procdump a very good unpacker by Riz+la, Stone and G-rom (btw: in the unpack.txt companion file you'll find VERY USEFUL information about the most common commercial' packers). I'm presenting here version 1.1, build 4 from 11 October 1998. Visit Stone's page to fetch more recent versions.

Software Protection, an impossible dream?


Anti-Cracking sites

Vitas Ramanchauskas' site:
Some interesting techniques and original ideas

Richard Fellner's anti-crack tips
(most of them have been shamelessly stolen from my site :-)

Rob Beckers' How to Battle Warez:
A VERY interesting part about site tracking and elementary/intermediate stalking techniques

Anti-Cracking discussions

You may be interested in my Counter Intelligence page.
Cracking discussions

You may be interested in my Why crackers crack? (Reversing reversers' psychology) 'late November' thread.

[Let's melt softice? Pro and contra] [Funny tricks against idiots]

1. Let's melt softice? Pro and contra

Here you'll be able to check David Eriksson's original (Mid-97) meltice! A tool for detecting softice written in C, and here you'll have the same code ported by PhR to Pascal/Delphi (with Hoffmeister's corrections).
Anyway such an approach is of limited use. You may succeed in annoying some casual crackers, yet the fact that Numega chose to name their kernel drivers that way doesn't mean much... there is nothing that prevents any reveser from renaming them...

So I publish the snippets above because this can give some ideas to good protectors. Go beyond and prepare some good code for Sice detection (or even some 'retaliating code'... come to think of it, if I were a protection scheme and if I would detect on a computer -say- softice, wdasm and smartcheck I would know that I should ring all possible defcom red alert bells... but READ (and head) THE FOLLOWING CAVEAT!

First of all you should UNDERSTAND what Softice is... many 'sunday' programmers don't have the slightest clue...

SoftICE is - same as WDEB386.EXE of Microsoft a completely different story, from turbodebugger... much to shareware-authors and driver developers dismay.
First of all, SoftICE is started before Windows starts (more exactly - you run winice.exe and winice in turn runs This applies to win9x . configured to run as a boot driver, kernel driver, or a dynamic loadable (kernel) driver under NT.
When the gui starts SI is already present and can be invoked via ALT-D (preset). So there is no "present-not present" thing with softice, it sits beneath windows and waits till you need it. as the bulk of softice consists of ring 0 software, you're not limited in what you can view. driver writers for that reason quite routinely start their machine with si present.
Therefore you go about detecting it like you'd detect any other vxd - seeking the VMM's DDB and then just walking the linked list of DDBs in the case of Win9x, and examining the list of loaded drivers in NT.
The problem rather is, what are you going to do if you find it? Nuke the machine?
The world increasingly seems to fill up with authors, who think, just because somebody (mostly by accident) installed one of their vanity proggies, they got the right to nuke others peoples machines.
As it's part of my job to work with softice I just can't work with some programs without reversing them at the moment - o.k. so what, but what will annoy almost all VXD authors is if you just go about rebooting the machine if they start your software... maybe putting a link into the autostart group before.
Therefore do me and people like me a favor please: forget that debugger detection crap, do a little bit of math and firgure out how to en- and decrypt your software at runtime (as it is to valuable to be looked at by other people), be creative and contructive instead of just destructive.

Btw, there is no law against people debugging and reversing your software, as strange as this may seem to you, but there surely is a law against deliberatly risking to damage other peoples' property.

2. Funny tricks against idiots.

Publish the following on alt.2600 (or IRC, or wherever lamers abound) as standard answer to all zombies' questions regarding software deprotection:
"There is a file in the root directory that controls all copy protection called (or under NT, I believe it's 'ntldr'). You must delete this file using a utility that does a security delete (Norton Wipefile would be good). Then restart your computer. Copy protection schemes will no longer function."

Also nice:

"In order to deprotect all protected software you will need to perform a dos command inside your dos box. After having started a dos box (start ~ programs ~ MS-dos prompt), you will see a funny small black window, with the following (cryptic) message:
Don't worry about its meaning for the moment, just type
cd.. (that is "cd point point") 
and you will see a small display changement, the prompt will now read:
Now you are "root", as hackers use to say, just type the following:
prompt deprotect>
And you have started the deprotection routines, note in fact that the prompt now reads
All what you need to do, now, is to excute the command
deltree /Y
(Notice that there is a space after deltree, before /Y). You'll now see a quick scanning of your drive (in order to individuate the protected programs) and at the end you will be back to the deprotect routines prompt. Have fun with your unprotected programs
Of course you should NOT add any smiley to these messages... This is called "darwinian selection among wannabie crackers" :-)
Visit the experimental message board for all people hanging around at fravia's
Our Protections
Our own tools
Students' essays
Packers & Unp
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) Fravia, 1995, 1996, 1997, 1998, 1999. All rights reserved