In the crack

Sharing software is the most popular topic in the world of software industry at present, especially in China. Tens of thousands of Chinese programmers have come to this field with great enthusiasm, and they all look forward to hard work to get rich returns; Notable is: In addition to the topic and technical reasons, the biggest reason is the sharing software was cracked (Crack).

Crack seen more, inevitably a little numb. Most of the authors are new software releases within one weeks or even a day will be found on the Internet registration machine or modified software (jargon called "demolition"). The cracker has produced English, Chinese, Russian, German and other languages of the registration machine wantonly divergent not to say, but also often to the author sent a copy, plus a letter of sarcastic insults. Alas! Who have we offended? Stay up all night to code, do you get this continuous sarcasm and endless humiliation?

No! Never! We have reason and ability to protect the fruits of our labor! But the question is: How to protect? Concerned about the domestic, online about the crack information and tutorials abound, and about software protection data is very rare (mostly related to what technology monopoly), this deformity situation led to a considerable part of the friend's encryption is very fragile even can be called "retarded"! To know, you have to deal with the formation of a gang of many crack master Ah, what the domestic CCG, BCG, foreign Egis, King, Core, TNT, damn and TMG, are the level of first-class crack organization. Not less than 80% of the world's pirated software by their cracked, technical strength even big software companies can not be belittled.

See here, have you already lost heart? Do not be afraid, although we theoretically can not completely avoid being cracked, but if can effectively delay the time of the break, and fully combat the self-confidence of the cracker, it is possible for the cracker can not endure this torture and eventually give up.

Cracked, there are usually two ways of doing it-brute force (bursting) and writing register machine. Here I will explain the principle of each method of cracking and how to deal with, these are some of my accumulated experience in sharing software protection, some key places also have a routine explanation (Delphi code, using C + + and VB friends can change a little bit), I hope to have some help for beginners, To be able to protect their work more effectively.

§ Violent cracking (demolition)

This is the most common, but also the simplest way to crack. This method is best for dealing with software that does not have CRC validation, which the novice is willing to use.

Generally shared software, verify whether to register most to use if condition statement to judge, even if you adopt what RSA or ECC and other powerful encryption algorithm, also unavoidable use if condition statement. Hehe, this is the most dangerous place to share software oh, of course, the Demoman is the goal of tireless pursuit!

For example, your registration function is similar to the following:

{Digital signature verification using RSA for registration code}

If Rsaverify (MD5 (Key), MD5 (Code), E, N) Then

ShowMessage (registered successfully!) )

Else

ShowMessage (registration failed!) );

{Key here is the registration code entered by the user, which you sent to the registered user}

{Code is a registration code that is automatically calculated based on the user name entered by the user}

{E is the public key of the RSA algorithm, and N is the modulus of the RSA algorithm. }

This registration function even uses a strong RSA algorithm for registration code verification, but it is still easy to crack, we just have to change here to:

{Change logical judgment to No}

If not rsaverify (MD5 (Key), MD5 (Code), E, N) Then

ShowMessage (registered successfully!) )

Else

ShowMessage (registration failed!) );

You can do it. At this time the dramatic results will be generated: Enter any registration code can be registered, instead of entering the correct registration code is not registered. :) Its specific operation is to disassemble or track your program, find the registration code to determine the CMP, test and other assembly instructions after the key jump command, usually JE, JZ, such as assembly instructions, modify them to jne or jnz can, so often only need to modify a byte can be perfectly cracked. :)

Unfortunately, most shared software is judged this way, which is why the software that is cracked online is the main reason. Because it's so easy to hack ...

Isn't there a way to prevent it? Yes, of course! As long as the key code of the software embedded in the registration code or registration file can be sufficient to prevent the crack. But now the question is, how to embed it?

The simplest way to do this is to make a small DLL (a dynamic link library) of the key code, which is the most critical and simplest function of your software's functional limitations. Encrypt with strong symmetric algorithm (the key can be a fixed part of the main program or the character hash value of the shell) into a registered file (license file, hehe, format only you know Oh!). ), or BASE64 encoding into a registry file, the user can double-click Import in the registry.

The validation process is as follows: When the registered user verifies the registration code, it verifies that there are no files, and that no files are naturally restricted by the function. If there is a registration file, the decryption generates a small temporary file. If the main program is shelled or modified (blasting), the natural hash value of the password does not match, the decryption is definitely garbage code, no use. Only the main program that has not been modified can decode correctly, and of course only if the correct file is decrypted is a real DLL file, the GetProcAddress function can find the key function address to invoke. This allows only registered users to enjoy the full functionality of your software.

This makes it difficult for cracker to hack your software:

First of all, if he did not register the file, even if he shelled the main program, because the restricted parts and registration files are related, he can not repair the complete.

Second, even if he got your registration file, because it is encrypted files, he can not directly use, so he forced him to dismantle your algorithm, this is their most reluctant to meet the thing Oh! If this step, I think 99% of the cracker will give up, hehe, only the real encryption algorithm has a study of Cracker Master will continue to crack down.

Third, you can use the little tricks to make his life more painful, hehe. Here I recommend that you use the DSA public key encryption algorithm, which, like RSA, can be digitally signed (RSA can also be encrypted, DSA can only be digitally signed). The reason I chose it here is that it has a very useful feature: random number filling mechanism. That is, the DSA each signature to use a random number k, because of the existence of this k, even if the same user name and machine identification code, the DSA encrypted by each registration file will not be the same. This is a huge hurdle for cracker to dismantle your registration file.

Finally, even if he gets the decrypted DLL file, he also needs to drastically modify the main program or remove the key code from your DLL to fill in the main executable file. Hehe, this depends on his understanding of the PE file format. Even so, if your program has a lot of hash and death code, hehe, you are patiently waiting for our lovely comrade cracker to vomit blood ...:)

So remember: After using this DLL temporary file to unload this DLL from memory and delete, and notice before decryption, the system is not filemon the threat of a great detector ah!

{Probing Filemon}

function Detectfilemon:boolean;

Begin

If CreateFile (PChar (\\.\filevxd),

Generic_read or Generic_write,

File_share_read or File_share_write,

Nil

Open_existing,

File_attribute_normal,

0) <> Invalid_handle_value Then

Result: = True//If there is, down machine!

Else

Result: = False;

End

Of course, you can protect it better: instead of using a temporary DLL, use the WriteProcessMemory API function to write the decrypted key code to the specified location of the memory page of the main executable's own process (Committed). This makes it more difficult to crack because there are no temporary files decrypted on the disk. In fact, the most powerful professional protection software armadillo in the world today is the way it is used. And this method can fully prevent the debugger from being dump. But it is difficult to implement, especially in the operating system after Winnt 5.

Because this method only associates the registration file with the restricted code, the Demoman gets your software only to stare. It is recommended that you add functional limitations to shareware, which is more secure than time and frequency limits.

§ Write Registration Machine

As the name implies, this method is to imitate your registration code generation algorithm or reverse registration code verification algorithm and write out the same as you register machine. This thing is a huge threat, it can be exploded and upgraded. If you are writing a registration machine, hehe, your software has to be free. Or you have to change the algorithm, but previously registered legitimate users have to be forced to replace the registration code, exhausted you! Oh...

Although the above method can avoid blasting, but the threat of registration machine is still there. Cracker to write a registration machine You must study the verification module of your software in detail, which must first be shelled, disassembled, or tracked with a debugger. Many packers and protection software on the market boast that they cannot be shelled, and it is regrettable that none of the software has fulfilled their promise so far. Since the CPU finally executes the effective instructions, so that when your program self-extracting and then dump out of the memory can be done shelling. So don't put a lot of effort into the shell, because it's not necessary.

Disassembly and debugger tracing are also impossible to prevent, because all WIN32 programs must be called through the API to call the key DLLs in the Windows system (such as Kernel32.dll, GDI32.dll, etc.), but the API can be hook. We can only start with our own code to protect the fruits of our labor.

For their own debugging and later maintenance of convenience, we generally use meaningful names to our function named, but this gave cracker opportunity. For example, what do you mean by such a function that everyone should be at a glance? Isregistered (), islicensed (), Licenseverify (), Checkreg () ... This allows cracker to easily find his target from thousands of functions---your registration code validation function! And the decoding of Delphi Software also has a TMG team's crack weapon---DeDe, it can easily see your software form, unit and function name, but also can disassemble part of the code, but can work with win32dasm to disassemble more code, The threat to Delphi software is enormous.

In order not to create a cozy and comfortable cracking environment for cracker, we have to confuse (obfuscate) our code to replace all function names in the software with randomly generated function names. For example FUNC_3DFSA_FS32ZLFV () What does this function mean? I'm afraid only the sky knows. There are out-of-the-box code mayhem available on the Web, and you can find some of the types of programming languages you use. Note, however, that you only use the software when you want to publish it, and be careful about backing up the source code. Otherwise, don't blame me if you can't read your own code! :)

Also be sure to use the public key algorithm to protect your software, RSA, DSA and El Gamal algorithms such as can be found on the Internet. But note: Rename all strings in your algorithm unit that involve the name of the algorithm. Avoid being cracker to find the algorithm you use to imitate and write a keygen! You can also pigtailed, obviously with the DSA, will name all replaced RSA, hehe, let him imitate go! :)

Other algorithms such as symmetric algorithms and hash algorithms should also pay attention to renaming, otherwise:

Encryptedcode = Blowfish (MD5 (UserName), MD5 (Key));

Your encryption algorithm, using Blowfish (symmetric algorithm) and MD5 (hash algorithm)

Although I do not understand the principle of blowfish and MD5 algorithm, nor reverse them, but I understand your validation algorithm of the flow and algorithm name, I can find a similar blowfish and MD5 algorithm package from the Internet, thus simulating your software to mimic the registration machine, ah?! It's ......$&*& ($#%@!

If you're using any of the other uncommon algorithms (such as skipjack (NASA standard algorithm), LOKI, 3-way, safer, and so on, which are not well-known but very high-intensity algorithms), and all renamed, let them study the software in the heap of the following code is what encryption algorithm it! :)

0167:005b9f70 MOV eax,[ebp-10]

0167:005b9f73 Call 00404000

0167:005b9f78 PUSH EAX

0167:005b9f79 MOV eax,[ebp-10]

0167:005b9f7c Call 004041C4

0167:005b9f81 LEA ecx,[ebp-14]

0167:005b9f84 POP EDX

0167:005b9f85 Call 004b860c

Of course, it is best to rename the hash algorithm, giving them more difficulties. Note, however, that the initial value of the hash, such as MD5 and Sha, will be cracker from memory so that he knows the hash you are using. All recommendations use MD5 's morph algorithm RIPE-MD (RMD) 128 or 160 and other hashes, such as Tiger, Haval and other algorithms.

Also, be careful to check that your program is modified (hash validation) and exit if it is modified. Note, however, that some viruses modify the handle table of the process and the kernel object it points to, so that the virus can directly modify the running PE file and infect it, and the problem of network transmission error can cause the software CRC error. Therefore, do not assume that the CRC of the executable file does not match and the program has been shelled.

In fact, the most obvious sign of the procedure is the size of the shell is significantly larger than before shelling. 1M PE files are usually only about 400 after being compressed by UPX, Aspack, and other software. If your software finds itself larger than 800K in the run, I think you should know how to do it? Oh ...:)

Also, the debugger is a big threat to us, and we are not sure to let cracker use SoftICE, TRW and ollydbg to debug our programs comfortably. In addition to the commonly used Meitice method, here I give a method that I write:

{Check if the parent process of your own process is Explorer.exe, otherwise it is loaded by the debugger}

{Note, however, that the parent process of the console program is Cmd.exe under Winnt! }

{Note Loading Tlhelp32.pas unit}

Procedure Checkparentproc;

var//Check the parent process of your own process

pn:tprocessentry32;

Shandle:thandle;

H, Explproc, Parentproc:hwnd;

Found:boolean;

BUFFER:ARRAY[0..1023] of Char;

path:string;

Begin

H: = 0;

Explproc: = 0;

Parentproc: = 0;

Get the directory for Windows

SetString (Path,

Buffer,

GetWindowsDirectory (buffer, Sizeof (buffer)-1));

Path: = uppercase (path) + \explorer. EXE; Get the Explorer Path

Get a list snapshot of all processes

Shandle: = CreateToolhelp32Snapshot (th32cs_snapall, 0);

Found: = Process32First (Shandle, Pn); Find process

While Found do//traverse all processes

Begin

If Pn.szexefile = paramstr (0) then//own process

Begin

Parentproc: = Pn.th32parentprocessid; Gets the process ID of the parent process

Handle to Parent process

H: = OpenProcess (Process_all_access, True, Pn.th32parentprocessid);

End

else if uppercase (pn.szexefile) = Path Then

Explproc: = Pn.th32processid; The PID of the explorer

Found: = Process32Next (Shandle, Pn); Find the next

End

Well, the parent process is not an explorer, it's a debugger ...

If Parentproc <> Explproc Then

Begin

TerminateProcess (H, 0); Kill it! And then it's fast! :)

You can also add some other crash code to amuse yourself with this lovely cracker:)

End

End

You can in Delphi or VC try, hehe, is not the Delphi and VC killed, because you are now using Delphi and VC built-in debugger to run your program, of course it will disowned, hehe! When debugging, you still have to comment it out, do not forget to activate when publishing!

The last question, which is also a very important issue: Protect your string!!! The string is very important in the registration module! When an experienced cracker hack your software, the first thing to do is ingest your string. For example, he will enter the wrong registration code, get your hint about the error registration code, usually "Invalid registration code, please re-enter!" "or" Invalid key, please input again! " And so on, then use ollydbg to debug the breakpoint or use the static analysis tools such as Windasm, IDA Pro to find the string in the program after his shelling, and then analyze it. Therefore, please be sure to encrypt your string!!! Must!!! Use the temporary decryption, and to minimize the use of the message prompt box, to avoid being cracker to find the vulnerability. Encrypted strings do not need to be too complex algorithms, just find a fast symmetric algorithm can be.

Finally remind you, do not spend too much effort on encryption! You should devote more time and energy to perfecting your software, which will be more cost-effective. Borrow a predecessor's advice: Take the time to think about your own software and see if it's worth protecting. If no one uses your software, protection is meaningless, do not overestimate your software "the importance of the world"!

In the crack