view this document with Notepad 800*600 L ZZZZZZ RRRRR SSSSS L Z R R S L aaa Z aaa R R u u S L a Z a RRRRR u u SSSSS XX L aaaa Z aaaa R R u u S XXXX L a a Z a a R R u u S XXXXXX LLLLLLL aaaaa ZZZZZZZ aaaaa R R uuuuu SSSSSS XXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXX XXXXXX XXXX proudly presents his 5.Cracking Tutorial (29.03.1999) XX What the programmers can do to protect their work better This tutorial is (nearly) the translation of another one I've written for a national shareware organization. I just got rid of the leading chapters "Intentions of this tutorial", "Think like a cracker" and the word explaination. Some parts of this turorial were influenced by the tutorials I found on Fravia's page (www.fravia.org is currently down: find a mirror at www.proweb.co.uk/~greenway) 1.Things you can do fast and easy 2.The application Win-Dummy as an example what a programmer can do wrong 3.Things that are harder to code/things I wasn't able to include in my Win-Dummy story and things I invented writing this tutorial (I don't know if they work). 1.Things you can do fast and easy The first thing I want to say is that every shareware program that can be upgraded to the full version can be cracked. You cannot hide anything in a debugger or disassembler. If you search long enough you WILL find the crack. So you cannot prevent your program from being cracked, but you can try to bore the cracker that he doesn't keep on trying to crack the target. The following tips are useful to reach this. At first a warning: Don't use any commercial protection scheme, because they are damn bad and all cracked, anyway. The same with EXE packers. While you unpack the files you get something to eat so they don't really disturb. Let's start with the smaller, easier things, you can do with a minimum of programming work. At first you should never use functions where the name of the function reveals what they do. For example the company Ulead that calls their functions often something like IsFullVersion. Guess what this function does. I like IsValidSerial, too. ;-) The same for the entries in INI files or the windows registry. For example BCM Diagnostics. This tool manages a value in the registry IsRegistered (or something like that). If this value is 0 the program starts as shareware, is the value 1 the program is the full version. One-minute crack with Registry Monitor. The coders of Pixel3D coded without using their brain, too. At first I thought they have done everything right, to make my life harder, but then I tried something I never read anywhere before. I deleted all registry values, Pixel3D manages and restarted it. Now I cracked away all "Cannot read data from registry" messages and Pixel3D started as full version. This should show you: Whenever something unpredictable happens, your program must start as shareware. The honest user can register it again. Another way to react if anything unpredictable happened, is to delete important values or files. The program should have to be reinstalled. Another way is to reboot the computer. This actions you should only use, if you are 100% sure that the part of the program that checks if something strange happened works absolutely correct, or you could make honest buyers angry. If you write a helpfile you should in no way mention anything about the registration code. The worst thing I ever saw was a helpfile where the structure of the code was mentioned: XXXXX-XXXX-XXX. But the programmer was silly enough to make another heavy mistake. If you enter 0 as name the valid code is 00000-0000-000. Seems the programmer uses only multiplication to calculate the valid serial. Best thing to do is to make wrong statements about the serial in the helpfile. Example: Once I had a target that said in is helpfile something like "If you register ??? you get a keyfile called keyfile.dat that upgrades your shareware version to the full version. Later I found out that the name of the keyfile was completely different. Don't "hardcode" important strings. They are always the first waypoint for a cracker. You better use something like char(65)+char(66)... Especially deadly are MessageBoxes and textareas in nag-screens. But you as a programmer can turn this thing around. Hide the important strings and declare somewhere in the program real strings with the same value as the hidden strings. Or use strings that could be from your compiler like GetWindowText/EnableMenuItem... This can confuse some disassemblers and they will produce confused code. 2.The application Win-Dummy as an example what a programmer can do wrong So far to the easy things. This chapter is about the imaginary application Win-Dummy. I create an application that behaves like the average shareware program: nag-screen/reg-code/time limit/ restrictions... Let's start the program. *BANG* a nag-screen pops up. This is no too good idea. If the program can be updated to the full version with a serial or keyfile or whatever there must be a check if the serial/keyfile... is valid. Crackers start usually by looking at the strings that appear in the nag-screen, so it would be better to use BMP pictures as nagscreen, but only if you program your own functions to show them. If you use the API functions there are no security improvements, because they can easily be located. Back to the nag-screen. To check if the program is shareware it has to read a value from a file or the windows-registry. This value can be something like: IsRegistered=0/1 or Name: XXX Code: YYY If the programmer used the first solution it is easy to get rid of the nag-screen. Did he choose the second one the code must be calculated in front of the nag-screen. So the cracker can easily find the calculation function that is perfectly hidden in the other parts of the program. Normally a nag-screen is useful for showing the user how much time he has left in his evaluation period. Using something like GetSystemDate is not the best solution for the time calculation. The user can easily turn back the windows clock and the program will never expire. At least you programmers should check if something strange happened (time jumps or something like that). A much more effective way to get the current date is the file SYSTEM.DA0. This file is updated every reboot and has always the correct date (if the user does have the correct date when he starts his computer). Another example: To make some programs never expire, you must do this: Add 10 years to your system date, install the application and switch back the date. Start the application and you have more than 3600 days left for testing. (Until the expiration there should be a never version of the target ;-)) OK, click away the nag-screen. Like in most programs you see UNREGISTERED in the window caption. One more chance for the cracker. If you calculate the code you shouldn't change the window caption and other restrictions at once, because the calculation can be easily found in this way. Better change the caption some hundred lines later. (Note: Are there any programs that check if they are full versions by checking the window title? If there are some, the programmer has chosen the wrong job,) Looking around in Win-Dummy you we recognize that some functions are not available in the share- ware version. Some buttons and menus are gray or a messagebox pops up saying "Only in full version". At first define all menus during runtime, because predefined menus that are stored in the EXE file can easily be changed with a ressource workshop. Anyway, the "graying" of menus is a mistake. Somewhere in the program must be the function EnableMenuItem. This function doesn't appear to often, so it can easily be located. It is better to create the menus at runtime, so the cracker doesn't know the name of them (watch at the help- file). Now we start to figure out the serial: The first thing a cracker should say is: HELL, WHERE IS THE INPUT BOX ??? The best thing is a hidden Register window that can be enabled with a key combination. This can be something like [CTRL]+[ALT]+[DEL] or better [CTRL]+[D]. Now two of my beloved tricks I use in some crackmes. At first call the code-box "Enter name here" and the name box "Enter code here". The cracker has to figure this out, first. The second trick is: Create two inputareas. A name-area and a code-area. One "Check code" button below them. The code is checked, if the values of the two are changed. If you hit the OK-Button, the "Wrong Code" message always appears. Calculating the code: At first you have to declare some variables. The program allocates memory where it can store the value of the variables and so on for the next variables. OK you should declare the variable for name, entered code and correct code should be declared far away from each other so the cracker can't get the code by memory dumping. You should never calculate the hole serial. Better calculate a part of the serial and compare it with the entered serial. Then calculate the next one and compare it... To calculate the serial you should use some KB of mathemathical instructions to confuse the cracker comletely. The risk of a keygen is nearly 0 then. Using giant loops where the cracker cannot get that he is in one are good to bore the cracker to hell. This loop 1000 times and the cracker wastes hours of time just tracing through a loop. I like fake serial calculations, too. Just code 15 different calculation schemes, where only one scheme gives you a valid serial. Calculating not with variables, but with pointers is hard to get, too and the values are nowhere stored in the RAM. After the calculation set the variables that contained the valid code to 0 or "" that the cracker can't find the correct code by memory dumping. If you show a "Wrong code" message, then check the code twice. One time with the message and one time without it. Silly is when you write the valid serial to the file instead of the entered serial. Just jump over the IsValid check and the correct serial is written to the file (Goldwave) or a valid keyfile is created (HexWorkshop). 3.Things that are harder to code/things I wasn't able to include in my Win-Dummy story and things I invented writing this tutorial (I don't know if they work). Then following things are hard to code. Sometimes to hard for a shareware program. 1.A single CRC check is most time easily cracked. Better make one in the EXE file that checks if a DLL file is valid and the other way. 2.Make the name of the keyfile depend on the serial and point to that keyfile from the windows registry if the valid serial is entered. 3.Make the input box look like the window so that nobody can see it who doesn't know that it exists. 4.Let the last char of the valid serial be a "." - They are hard to see in a serial. Example: OFFSET HEX-CODE DES PASSWORTS PWD IN ASCII XXXX:XXXX 00 00 00 00 00 00 00 00 ........ XXXX:XXXX 65 66 67 68 69 70 71 19(?) ABCDEFG. XXXX:XXXX 00 00 00 00 00 00 00 00 ........ The last point in line two is part of the serial, not of the ASCII 00. 5.Use "-" in your password, but not regularly, but like X-XXXX-XXX-XX. And calculate the serial without the "-", but check if they exist. 6.Use control variables to check if a CALL was executed correctly. 7.If you code with Delphi or C++ Builder you can choose the predefined components like Label to hide important string, because they are saved encrypted. 8.Make the serial depend on the hardware configuration. 9.Check if the name can be valid: ][ce, LaZaRuS [hf], ED!SON, +wAj., _mammon can never be real names. BTW Hope my tutorial was helpful for you and see you again in my next tutorial. Greets to: Fravia+, tKC, ED!SON, Moral Insanity, The Sandman, Eternal Bliss, DaVinci and all [hf] members All Tutorials by LaZaRuS [hf] #| date | name |version|W32Dasm|Soft-Ice|kind of crack | -|--------|------------------|-------|-------|--------|-------------------------| 1|20.01.99|Jaylock |1,0,0,1| (X) | (X) |serial# | 2|31.01.99|Goldwave |4.02 | (X) | (X) |serial#,nag-screens | 3|28.03.99|AxMan |3.00 | (X) | (X) |serial#,remove date-limit| 4|29.03.99|C++Builder Strings| | (X) | (X) |how to find strings in | | | | | | |C++ Builder that are not | | | | | | |hardcoded | 5|29.03.99|Better Protection | | | |How to protect shareware | | | | | | |better against crackers | LaZaRuS [hf] Visit Hellforge at http://members.xoom.com/hell_crack for more tutorials and high quality cracking links. If you want to mail me: lazarus666@gnwmail.com