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 CRACKING
9802 = MAIN *.DLL's "PASSWORD VERIFY" & "TIMECHECK" FUNCTIONS
9803 = "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 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.
(c) Mark 1997. All rights reversed
You are deep inside fravia's page of reverse engineering, choose your way out:

redhomepage redlinks redanonymity +ORC redstudents' essays redacademy database
redtools redcocktails redantismut CGI-scripts redsearch_forms redmail_fravia
redIs reverse engineering legal?