Mark's 14 protector's commandments
(And other useful tricks of a programmer-cracker)

by Mark

(13 November 1997)

---

Courtesy of fravia's page of reverse engineering

Well, Oh may. Living prokers sighted on fravia's site. Mark, a programmer-cracker, condenses in a single email quite a lot of useful knowledge and sound advices. A pity that Authors of this kind "certainly do not have the patience for an essay", let's hope they will find some patience asap, because I would rather like to get a lot of essays from such a clever proker!
Mark is of course completely right:

"the reason so much software is so poorly protected is 
because so many programmers don't know how to crack:  
If you can't crack you can't protect"

Fravia:

For the last year I have found your page a wonderful 
source of enjoyment, not to mention a great service 
not only to crackers but to programmers such as myself.  
If I have learned anything from your site, it is that 
the reason so much software is so poorly protected is 
because so many programmers don't know how to crack:  
If you can't crack you can't protect.

Having been programming for fifteen years, I have become 
very annoyed with the crap that is sold to us consumers 
as working software.  Even worse, I have become annoyed 
with the crappy programmers who are working for these 
companies making this crappy software for pretty good 
money.

So, I crack.  That's how I win. My assembly knowledge 
is read-only.  Many of my cracks are quick and dirty 
and never documented.  
I don't drink "wodka" but I find a good Slurpee helps 
my Zen.  In fact, I may just be getting Zen confused 
with brain freeze.  Who knows.

I wanted to share some thing I have learned along the way.  
I certainly do not have the patience for an essay so if 
this stuff is useless to you, just trash it. 

First, I wanted to comment on Chown's essay on object-oriented 
cracking.  I think he is on the right track of a very safe 
and rarely used method of cracking.  I have used object-oriented 
cracking on many projects.  I find it much cleaner and many of 
my cracks are version (and many times product) independent.  
Anyway, the concept is simple:  the target calls a password 
verify function and it just wants a yes or no answer.  It doesn't 
care how the answer is determined.  That is what makes 
object-oriented software so "object-oriented".

Chown in his essay created an application that called MYDLL.DLL 
to generate a valid serial number.  Although that works, I find 
it kind of brute-forcish.  Brute force cracks work but I always 
feel empty after cracking in this manner.  I prefer to be on the 
other side and imitate the server.  To do this I need to introduce 
Videosoft's VSDocx (www.videosoft.com), a tool that I very 
frequently use but I have never seen mentioned in any of your 
collection of essays.  

VSDocx takes an OCX or DLL and creates documentation, including 
function syntax and descriptions, if available!  In Chown's case, 
all he had to do was run VSDocx on MYDLL.DLL and create a new DLL 
to that specification.  This new DLL would only produce successful 
return codes when functions were called.  Incidentally, VB5 is a 
much easier way to quickly create these imposter DLLs.  Remember 
to make the new DLL binary compatible with the old one so that 
the same GUID will be used.

To crack VSDocx, just run Regmon and look for references to the 
license keys.  VSDocx (and all Videosoft software) just looks 
for the existence of these keys, not values.  Just find the keys 
in Regmon and create them in HKCR\Licenses in the registry.  
It is sad to see such good software so poorly protected.  
When a crack is this easy, sometimes I feel cheated.  
How dare them deny me the thrill of the hunt...

Add-on by Kevin lee (25 July 1998) begin
Fravia,

     on the page at http://fravia.org/mark1.htm Mark said:
    "...To crack VSDocx, just run Regmon and look for references to the
     license keys.  VSDocx (and all Videosoft software) just looks 
     for the existence of these keys, not values.  Just find the keys 
     in Regmon and create them in HKCR\Licenses in the registry.  
     It is sad to see such good software so poorly protected.  
     When a crack is this easy, sometimes I feel cheated.  
     How dare them deny me the thrill of the hunt...."
     He could have still hunted. The registration numbers are there for
     all to see. Here is a list of some:
     0206-B07E1AA0    (this will register the VSDOCX program).
     0206-C10E8580    (this is the MASTER number that will register ALL
     of the VideoSoft programs)
     Note: I found these and many others using softice, in approximately 15
     minutes.
Add-on by Kevin lee (25 July 1998) end

...Anyway, here are some other things I have found useful:

WISE INSTALL
Wise install is very commonly used to install applications.  
Many times serial numbers are entered right in the installation.  
There are about 30 functions in the Wise executable.  
These are good targets to crack because you will use them over and 
over.  
Once a wise install is started, the executable is found in 
the Windows directory named ~glc000x.tmp or ~glh000x.tmp.  

When running a Wise install, try these command line options that 
are always enabled:
/T   Test Mode.  The installation runs but no changes are 
     made to your system.  Useful for playing around.
/M   Manual Mode.  This option gives you total control of 
     the installation.
/X   Extract Mode.  Allows you to select individual files to 
     extract.  Very useful.  Sometimes there is a full version 
     right there with the demo version!

PEEK (http://members.ping.at/mlubich/peek11.zip)
A useful tool that extracts all readable text from a binary file 
and pops it up in notepad.  I always run this on a target (along 
with QuickView and Properties) to find any clues or just 
interesting stuff.  Every once in a while I find a command line 
switch that the programmer put in for testing (i.e., /TESTMODE).  

REGMON and FILEMON (and VXDmon)
Needless to say, it is usually useful to see what a program is 
doing, or even better, what it is looking for.  I was watching 
an early version of the Micrsoft Internet News reader that was 
looking for a "God Mode" setting in the registry.  I never did 
find out what "God Mode" was for but sometimes it is useful to 
see what a program is looking for.
Mark Russinovich's register monitor
Mark Russinovich's File system monitor
Mark Russinovich's vxd monitor

WINDOWS SDK
Sure, there's lots of crap, but there is also some good information 
and a few useful utilities.
Mark's 14 protector's commandments

Here are some of my tips for protecting software:
1 Never use meaningful file or procedure names such as 
  IsValidSerialNum (duh.)
2 Don't warn the user right after a violation is made.  
  Wait later, maybe until the next day or two (crackers hate that).
3 Use checksums in DLL's and in the EXE.  Have them check each other.  
  Not perfect but it just makes it harder to crack.
4 Pause a second or two after a password entry to make brute 
  force cracking unfeasible.  Simple to do, but rarely done.
5 Self-heal your software.  You know, error correction like modems 
  and hard drives use.  The technology has been around for years, 
  and no one uses it on their software?  The best thing about this 
  is that if the cracker used a decompiler, they may be looking at 
  a listing that is no longer valid.
6 Patch your own software.  Change your code to call different 
  validation routines each time.  Beat us at our own game.
7 Store serial numbers in unlikely places, like as a property 
  of a database field.
8 Store serial numbers in several places
9 Don't rely on the system date.  Get the date of  several files, 
  like SYSTEM.DAT, SYSTEM,DA0 and BOOTLOG.TXT and compare them to 
  the system date.  Require that the time be greater than the last 
  run.
A Don't use literal strings that tell the user that their time is 
  expired.  These are the first things to look for.  Build strings 
  dynamically or use encryption.
B Flood the cracker with bogus calls and hard-coded strings.  Decoys 
  are fun.
C Don't use a validation function.  Every time you validate the user, 
  write your validation code inline with the current process.  That 
  just makes more cracking for the cracker.
D When using hard-coded keys or passwords, make them look like program 
  code or function calls (i.e., "73AF" or "GetWindowText").  This 
  actually works very well and confuses some decompilers.
E Finally, never reveal your best protection secrets :-)


I recently ran across a very weak protection in Microsoft Outlook 
applications.  Microsoft has been pushing Outlook and Exchange server 
for workgroup applications.  Many developers have begun to create 
commercial (and very expensive) application extensions for Outlook.  
Outlook forms can be password protected but the password is in 
cleartext just a few bytes away in memory from the string being 
validated. A quick jump to Winice will reveal the password.  
And since Outlook forms aren't compiled, you get the original source 
code and everything.  Oops!


Mark.

homepage links anonymity +ORC students' essays academy database
tools cocktails antismut CGI-scripts search_forms mail_fravia
Is reverse engineering legal?