|
Programs that use registration-number protection require the user to enter a registration number to register the program. The registration number depends on specific criteria.
Programmers use different types of registration-number protection, including the following:
• Registration number is always the same.
• Registration number changes in accordance with entered information (company, name, and so on).
• Registration number changes in accordance with the user's computer.
• Registration-number protection in Visual Basic or Delphi programs.
• Registration number is checked online.
Registration Number Is Always the Same
A program protected with this method requires the user to enter a registration number. However, because the registration number is always the same, the cracker only has to find the correct registration number, post it online, and the program can then be registered by anyone.
One advantage of this method of protection, when compared with other registration-number protection techniques, is that the correct registration number doesn't have to be saved in memory to be compared with the entered number, which will often be XORed or recalculated in some other way. The correct registration number will then also be recalculated and both results compared. Naturally you can use more complicated calculations that are not easy for the cracker to understand, making it difficult to get from the result back to the correct registration number.
You can make excellent use of this protection method by encoding several program sections, such as a Save function, with the correct registration number value. If a cracker uses the patch method (directly adjusting conditions in the program code) and the correct registration number hasn't been entered, the originally blocked functions will still not work correctly.
It isn't a good idea to decode the blocked sections right after the correct registration number has been entered. It is safer to decode these sections only when the program has been started, or better still, only after the blocked function has been called. If the function is encoded again after use, and the program contains many encoded sections, the program will never be decoded in the memory as a whole, which means that a dump from memory will not help the cracker very much.
This software protection should be combined with other types that will be described later on.
Registration Number Changes in Accordance with Entered Information
This is the most frequently used type of protection. In this case, before you enter the registration number, you have to enter a user name, company, or other information, and the correct registration number changes according to the information you enter. If you enter a registration number that doesn't match the information entered, the registration won't succeed. The more skilled the programmer, the more difficult he can make it for the cracker to break this protection. However, even though the calculation algorithm may be very complex, once the user has entered the registration number, it is compared with the calculated one, and the cracker only has to trace the program to find the correct registration number.
When an incorrect registration number is entered, the registration is unsuccessful To buttress this protection , it is a good idea to design the algorithm so that the entered name and registration number must produce a certain result . Most programs don't institute this control —the registration number doesn't have to be checked, and it can offer a range of results. The attacker may exploit this range and generate a registration number in accordance with his own wishes.
When this sort of protection is used, the program should contain another hidden algorithm to check whether the entered registration number was really the correct one. It shouldn't tell the user, though, if it finds any inconsistencies. It will be enough if the user is somehow punished. (I will leave this up to the programmer's imagination.)
You can also encode some parts of the program (as mentioned previously) so that they cannot be used in an unregistered version. Then, once you've verified part of the registration number, you can use the unverified part for decoding the parts of the program. If you use good scrambling and a sufficiently long code, it will be almost impossible for the cracker to find the correct value for decoding . ASProtect works in this way.
Registration Number Changes in Accordance with the User's Computer
This is an unpleasant type of protection for an attacker, and it may even fool an inattentive cracker because, although he will register the program at his computer, it will not be possible to register the pirate version anywhere else. The registration number may change, for example, in response to the hard drive serial number or according to some random sequence. (It is important to hide this registration number carefully, because if it is found, it could easily be changed into a uniform number and the program could be registered at any computer with the same registration number.) Naturally, the registration number should also change in accordance with other data (such as user name, company, and so on) so that it works for only one user
When using this type of protection, it is very important to hide both the code that detects the computer number and the checking code that assesses the correctness of the entered registration number. It is good to combine this method with other types of protection.
Registration-Number Protection in Visual Basic Programs
Protecting a program in Visual Basic (VB) isn't easy, since the programming language itself is a high-level language (the higher the language level, the further the compilation is from assembler). With high-level languages it is difficult to influence the compiled source code.
VB programs fall into the following groups:
• VB4
• VB5 and higher
• VB5 and higher, compiled in p-code
We'll look at each of these in turn.
VB4
Although it may not be obvious to most users, the VB4 family of programs has very inadequate protection, and the experienced cracker will find most registration numbers within five minutes. The trouble is that VB4 programs mostly use the same VB40016.dll (VB40032.dll) library call for comparing the entered registration number to the correct registration number.
Even when a VB4 program uses some other comparison method, it is usually possible to find the correct registration number easily in memory. The registration number is usually placed close to the entered number, so all you need to do is search the memory for the entered registration number to find the correct one.
One advantage of VB4 programs is that they are hard to trace in SoftICE because their code isn't compiled into a machine code but only into pseudoinstructions that will be performed after the program is started. There are decompilers for VB4, but they are rarely used.
How VB4 Programs Are Cracked
How are VB4 programs cracked then? Even though VB4 is only rarely used for programming these days, it is good to know about it to avoid the mistakes in its use.
For a 16-bit VB4 program, the cracker has to find something like the following in memory and in the VB40016.dll code:
8BF88EC21EC5760E33C0F3A674051BC01DFFFF
He then sets a breakpoint to the address where the code was found, and he is able to see the following program instructions in the debugger:
Prefix Instruction
8BF8 8EC2 1E C5760E 33C0 F3A6 7405 1BC0 1DFFFF mov di,ax mov es,dx push ds
lds si,[bp+0E] xor ax,ax
repz cmpsb jz 2667
sbb ax,ax sbb ax,ffff
Now all the cracker needs to do is to see what he finds at the address where the repz cmpsb instruction compares the entered registration with the correct one. (You have only to look at the addresses es:di and ds:si to find the correct one.) This very simple tactic usually works, which probably isn't good news for most 16-bit VB4 programmers. Fortunately, 16-bit VB4 is used less and less. When it is, I recommend using a good DOS compressor or some other EXE protector for the program itself.
Most 32-bit VB4 programs use the MultiByteToWideChar function in the VB40032.dll library to compare two strings. During registration, all the cracker needs to do is set a breakpoint to the hmemcpy function before clicking OK, and then trace the program until he gets into VB40032.dll and finds the following bytes in the memory:
56578B7C24108B74240C8B4C2414
Then, he sets a breakpoint to the address found, and after repeatedly clicking OK, he will see the following code:
Prefix Instruction Explanation
56 push esi
57 push edi
8B7C2410 mov edi, [esp + 10] ;es:edi --> registration number should be here
8B74240C mov esi, [esp + 0C] ;esi --> correct registration number
813F70006300 cmp dword ptr [edi], 00630070
7527 jne 0F79B381
803E00 cmp byte ptr [esi], 00
VB5 and Higher
The software protection in VB5 and higher is slightly more difficult for crackers to tackle than that found in VB4. Many crackers are rather disappointed when they find out that they have a VB5 program in their hands, and they often leave it alone, but the experienced ones aren't scared off that easily.
Crackers aren't keen on cracking VB programs (or those written in Delphi) because the code is hard to read and understand, and it takes a lot of time to trace. To crack VB5, they usually use methods for generating a registration number for just one user, or modifying the program code to allow for any registration number. Only rarely does someone create a registrationnumber generator for a VB5 program, and then only the best crackers are able to do so because the code is so difficult to understand. (They may use SmartCheck, since it helps them understand the code.)
The fact that VB 5 programs are so unpopular among crackers , and that it's difficult to create registration-number generators for them, is one advantage of using VB5. When a good compression program or protector is used, VB5 programs can be a challenge for any cracker.
It is a good idea to use a registration number that changes on different computers. This involves heavy interference with the program code, but the result is that it is almost impossible to use anti-debugging tricks.
VB5 and Higher, Compiled in P-Code
Programs compiled in p-code (short for packed code) are probably the VB programs least liked by crackers. Unlike VB4 programs, p-code programs are translated into pseudo-instructions, not machine code, and these instructions are performed when the program runs. Programs in p-code can be traced in SmartCheck, but not easily. The most experienced crackers will try to trace such programs in SoftICE, but only a small group of them will be able to do so.
VB programs compiled in p-code combine well with other software protection, and when they are used with a good compression program or protector, they are a challenge for any cracker. As a programmer, you should use registration numbers that change with different computers. Doing so will heavily interfere with the program code, but it will make it nearly impossible to use anti-debugging tricks.
Registration Number Is Checked Online
Some newer programs use the latest in modern technology for testing the correctness of a registration number. Once the registration number is entered, the program sends it via the Internet for verification. A server then tests the number and returns a report which tells the program whether the number is correct. The program processes this report to determine whether the program was properly registered. Despite this online exchange, though, most of these protection programs are very simple, and an experienced cracker can get rid of them quickly and reliably.
The program displays an error message if an error occurs while connecting to the server Several of these programs do have slightly better protection because they contain random checking routines in their code. When such a program finds out that it was illegally registered, it will send a message to the producer via the Internet containing information about the user . I don't think this is a good approach—a better approach would be to have the program cause some trouble, or to simply delete itself, or something along these lines. Again, I'll leave that up to the programmer's imagination.
Online verification of registration numbers is done more and more often, but it's not appropriate for all software. Before deciding to use it, consider the audience for your program. For example, if your program always uses an Internet connection, the user will have to be connected to the Internet to use the program, and online verification is a reasonable option.
Most current software protection based on the principle of online verification isn't very good and is easy to remove, though there are several very good exceptions. For example, online verification is ideal for sending data to a program that is necessary for the program to function correctly.
Consider a program that has the Save function disabled in the unregistered version. When a user enters a registration number, that number is sent to a checking server. If the registration number is correct, the server will send a report confirming program registration, together with a short data bundle that could unblock the Save function. The server might, for example, send a parameter to decode a previously encoded function.
With this protection scheme in use, it would not be enough for a cracker to fool the program into thinking that the server confirmed a registration number. Even if the cracker were to succeed at fooling the server, the Save function would not function.
For this protection to work properly, the decoding key must be rather long so that it can withstand an attack. Also, the problem of a cracker using a correct registration number from a legally registered copy still remains, since with a correct registration number in hand, a cracker could decode the Save function correctly. Therefore, when using this protection scheme, it's very important to make the registration number different for each computer, thus making its illegal use difficult.
Note It is also possible to allow only one use of the registration number, or to limit its future use to the IP address of the computer where the program was originally registered.
| 
Disclaimer
