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"

There are quite
a lot of little diamonds inside this tract (it is indeed NOT an
essay), the one I enjoy most is pointing out that application extensions for
Micro$oft Outlook are as naked as a baby :-) Once more greedy commercial programmers fall on their Micro$oft noses :-)

You'll enjoy everything, the main point being that we
should indeed now enter the age of object-oriented cracking. The
+HCU will start three 'object-oriented' seminars (projects and courses) in January 1998:9801 = DELPHI CRACKING9802 = MAIN *.DLL's "PASSWORD VERIFY" & "TIMECHECK" FUNCTIONS9803 = "INSTALLATION WIZARDS" CRACKING
yet some published essays already point in this direction. Therefore all +HCUkers that
have some time left should try to work along these lines... studying for a start all
'main' installation procedures (and 'wizards')...
Enjoy!

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 monitorMark Russinovich's File system monitorMark 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.

(c) Mark 1997. All rights reversed

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