|
In addition to the freeware and shareware programs, there are a number of commercial programs for software protection. These, too, vary in quality.
When writing this article, I intended to write about all the commercial software protection that I could find. I quickly learned, though, that there were far too many commercial packages to cover in a reasonable space, so I whittled my initial list down to about forty packages (perhaps one-third of what's available). I then selected what seemed to be not only the best-known, but also, in my view, the best packages, and studied each in detail. I focused both on the design of each package as well as the code itself.
Most of the current commercial software works like Armadillo, SVKP, Vbox, and ASProtect. However, only a few commercial software packages manage their protection well, and most of these programs aren't even protected against changes in the code, which I find to be very unprofessional.
There is quite a range of software protection available, and most of it has its weaknesses. As a software developer, you should understand the weaknesses in the programs you choose, and develop a good strategy for employing software protection. There are good solutions out there, and when used intelligently, one is sure to work for you, but don't expect any one solution to last forever.
ASProtect
ASProtect, from ASPack Software (http://www.aspack.com), isn't just another commercial anti-cracking program; it is a truly revolutionary advance in software protection. It may be the prepackaged solution to software protection for those who don't want to spend long hours studying and programming custom protection for their own software.
ASProtect's creator Alexey Solodovnikov learned a lot from his work on ASPack and applied that experience to ASProtect. He claims that because all anti-cracking defenses can be defeated, the only important thing is under what circumstances they can be broken.
While it was created especially for shareware developers, ASProtect can be used for professional software as well. While it's not as versatile as FLEXlm, and it works only under Windows, I daresay that it is currently the most difficult commercial software protection to break. Its only weakness is that it doesn't have the best anti-debugging tricks.
Compared to other commercial software protection, ASProtect is simple and well-programmed, reflecting the simple but wonderful idea behind it. Like similar programs, the original program is compressed and then uncompressed by ASProtect before it is run.
ASProtect's compression is based on the ASPack algorithm, which is among the best. While it adds about 60KB of code to the original program, this additional code doesn't matter at all, since the resulting compressed program is much smaller then the original one.
ASProtect's decompression routine checks to see whether there have been attempts to change the file, and it tries to prevent changes in memory. Naturally, without decompression, the original program can't be disassembled, and it isn't easy to decompress ASProtect because it tries to prevent memory dumps by programs like ProcDump. Once the import section has been dumped from memory, the PE file will not be correct. Still, there is a way to decompress ASProtect (not by just dumping), but ASProtect is still not defeated even after successful decompression.
Like FLEXlm, ASProtect tries to prevent the use of certain functions in the protected program when it is unregistered, and it does so beautifully compared with other software. For example, if a programmer wants to disable Preview in the unregistered version, he need only encode this function with ASProtect. After registration, the disabled part is decoded using a constant from the registration key, and it is not possible to decode it without this registration key. ASProtect's exceptionally strong encoding prevents even direct (brute-force) attacks.
There are three ways to secure an application with ASProtect. The first way uses classic compression and is not recommended because it's relatively easy to decode.
The second possibility is much more interesting, though still not the best. With this method, the original protection is first authenticated after the ASProtect API is called with a constant for decoding the encoded part of the program. You might use this method if, for example, the program you want to protect already has its own registration control and you don't want to change it. This method would be a poor choice if the original protection is weak, since it would not prevent the cracker from getting the correct constant.
The third and best possibility doesn't add any protection to your program (although additional protections are possible). Basically, when using this third method, you specify in the Registration Keys tab in ASProtect that you want your project to contain a registration key. The program then creates a basic constant that will serve as a base for other keys, and that will also be used to encode the protected part of the program. You can generate the keys according to user names, and you can also save them. Finally, you determine where the registration key will be saved in the registry following registration.
Note ASProtect's key files have KEY endings but are essentially REG files that are imported into registers once they have been double-clicked. This is an advantage, because ASProtect's registration keys are rather long, and it would be tedious for users to enter them by hand.
The next step is to verify the registration. If you have only a registration key, the program will print the name of the registered user. You can also specify keys that have been illegally made public if you don't want them to function in future versions of the program. Subsequent versions of ASProtect will probably be able to generate keys for only one computer, which will prevent the illegal distribution of registration keys.
Finally, in the program code you specify the parts of the program that you want to encode—this is a simple procedure that can be performed by almost any programmer. Currently ASProtect contains code examples for Delphi, Visual C++, and Visual Basic. For instance, here's a short example in Visual C++:
include <windows.h>
#include "include\asprotect.h" char *message;
void RegisterAction() {
REG_CRYPT_BEGIN
message = "Registered version !"; REG_CRYPT_END
}
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
{
message = "Unregistered version !"; RegisterAction();
MessageBox (0,message,"",0); return 0;
}
You must add REG_CRYPT_BEGIN to the beginning of the encoded program and REG_CRYPT_END to the end.
At the beginning of the encoded part of the program, you must add the following data:
0EBh, 04h, 0EBh, 05h, 89h, 89h, 0E9h, 0, 0, 0, 0
And the following data is added at the end:
0EBh, 04h, 0EBh, 05h, 99h, 99h
This data enables ASProtect to find the areas that you want to encode.
Next, you need only call the procedure and the rest will be done for you. If a program isn't registered, the encoded part will be skipped, or else an error will occur. If the program is registered, this part will be decoded at the start of the program, and it will be used later when it is called.
You can get the user's name with the apiGetRegInfo() API function.
Should you need to create many registration keys at once, ASProtect makes it easy by supplying the library keygen.dll. You can generate registration keys with its two functions. The GenerateKeyAsRegFile() function creates a registration file based on user information. Alternatively, the GenerateKeyAsString() function returns the memory pointer to where the registration key was created.
ASProtect allows you to set the number of times that a program can be run or the number of days it will be useable. Unlike similar commercial programs, all protection is placed in the PE file, and not in added DLL or OCX files.
As of this writing, it is impossible for a cracker to correctly remove ASProtect's protection. To do so, he would need to use the correct registration key to decode the program and then dump it from memory. Of course, should the program's creators consider this attack, they may prevent it too by adding additional protections.
· Test file original: 1,691,648 bytes
· Test file encoding: 693,760 bytes
· Decoder: AspackDie
FLEXlm
FLEXlm, from Globetrotter Software (http://www.globetrotter.com) is one of the most frequently used protection programs for pricier commercial software. While originally used mostly with Unix software, in the last few years it has been used with other systems as well, especially Windows. FLEXlm is used by the largest software producers, including Adobe Systems, Sun Microsystems, Texas Instruments, Sybase, and SGI.
FLEXlm supports most operating systems and many network protocols, and it offers many ways to protect a product. I will briefly describe the most important ones. The Enable/Disable product features option is the most frequently used.
Demo (Time-Limited License) Demo or time-limited programs may disable certain features found in the full product. The time limit may be determined by a date when the license expires, by a number of days, or by a number of program starts.
Enable/Disable Product Features This option lets you disable some program features and use various types of licenses. For example, in the "lite" version of a program, some functions might be disabled and then enabled once a user registers for the "pro" version.
Floating Over a Network This option lets you determine the maximum number of users who may use a particular program over a network at one time.
Named-User This setting specifies that the program may be used only on computers that have their network names specified in a list of users.
Node-Locked This option locks the product to one particular computer.
Node-Locked Counted This option locks the program to one computer and only for a limited number of starts.
Time-Limited This option sets a date after which the license for the product will expire and the program will no longer be usable.
Domain Only This option restricts use of the product to computers in a specific Internet domain.
Protected products call FLEXlm's protection using API functions, and this protection then checks the license in a file, usually license.dat. Before the program uses a protected function, it checks to see whether a particular user has a right to use the function.
FLEXlm's protection isn't unbreakable though. At this writing, there is a generator that capitalizes on failures in FLEXlm to produce correct license files. Naturally, the existence of this generator diminishes FLEXlm's effectiveness. On the other hand, though, when used correctly and combined with other protections, FLEXlm may still offer a very good solution. For example, if another program is used to test the license again in some other way once a protected function has been used, that program will often reveal an illegally created license file.
It is sometimes difficult to find all of FLEXlm's protected functions, and it is absolutely essential to avoid placing their names directly in the EXE file in readable form. Because crackers often set a breakpoint on the lc_checkout call when searching for FLEXlm function calls, it's better to check the protected functions only when they are used, rather than to check them all as soon as the program has started. Be sure, too, to check the breakpoints set to this call, and to use other protections in the program.
While FLEXlm is breakable, it is easy to use. Its wide range of options and support for a variety of operating systems make it an attractive software protection option.
InstallShield
The InstallShield software is designed for creating installation packages. Probably anyone who works in Windows has already seen it, and it is most likely the best application in the field for doing so. Many programs have attempted to compete with InstallShield, but none have beaten it (though a few come close).
Because a faulty installation package can cause huge problems for product distribution, you should use the best installation product you can find, even if it is a bit more expensive. InstallShield has been extensively tested and has been used for several years without problems, which itself is a good test for errors.
InstallShield can perform simple as well as highly complicated installations. It can even call the API calls of external libraries, which is good for protection. And, it can check for various registration conditions during installation. The hardware key is often tested during installation, and the installation is halted if the correct hardware key is missing. The difficulty of removing this protection depends only on the quality of the DLL library.
InstallShield uses its own simple scripting language, which is probably most like C, and once the installation package has been created, the files are compressed into special files. When installing, all of the files necessary for installation are decompressed into the temp directory and then run only from there. This has the advantage that even when the protection can be removed, it is still not easy to change the files within the installation package. (At this writing, a decompressor for version 5 of InstallShield could update its compressed files, but there was still nothing like it for version 6.)
The most difficult part of cracking InstallShield-protected files lies in breaking the protection programmed in the InstallShield script language. Debugging the language is difficult because it is very similar to Visual Basic in the p-code. The attacker will encounter a problem when trying to change the file containing the script—the file is protected by a CRC check, and it is very difficult to perform the change correctly because the file's structure is rather confusing and complicated. Still, the protection can be broken.
Install Shield is clearly the best program for creating installation packages. It has been used not only with games but also with the most expensive applications.
ShareLock
ShareLock from Nesbitt Software (http://www.nesbitt.com) is commercial protection that uses DLL API calls. While it has been discontinued by Nesbitt, it is still used today, so let's have a look at it.
ShareLock's protection is more complex than a program like Vbox, requiring you to insert an API call into the code to test the protected application. You can test either for the expiration of a time limit or for the correctness of the entered registration number. The entire protection is secured by one DLL library called ShareLk20.dll, which must be located either in the directory with the protected application or in the Windows system directory.
ShareLock's weakest point lies in the protection of the DLL library itself, which is very easy to modify because it has no CRC checks. On the other hand, the registration number calculation is very good, and it is hard to find; to find it, an attacker would have to debug ShareLk20.dll and find a location for the change in the program code, at which point the program would behave as if registered.
Unfortunately, if the protection can be broken this easily, there is no way to protect the application against attack. (Perhaps the protected application could perform the checksum of the DLL library to detect an attack.) Still, the worst news is that once the ShareLk20.dll protection is broken, it is possible to use (illegally) all applications that use this commercial protection, which may well be why this product has been discontinued.
The Armadillo Software Protection System
The Armadillo Software Protection System is commercial protection from Silicon Realms Toolworks (www.siliconrealms.com/armadillo.htm). Programs are encoded and compressed by means of a randomly generated encoding key.
Armadillo contains one particularly interesting function that allows developers to enter illegal registration numbers found by crackers into a database so that such numbers will be non-functional in subsequent versions. Armadillo also contains anti-debugging tricks that protect against SoftICE.
It's easy to manage Armadillo, and we'll look at a few of its more interesting features in the following list. Armadillo has a very good help system too; to learn more about a particular option, simply select it to read its description or access the help system.
Hardware Locking Options (Pro) With hardware locking, the registration number changes for each computer, according to the various parameters that you set here.
Don't Report Clock-Back Protection checking will be disabled if the time wasn't turned back on the user's system. This protection should be disabled only if your program has problems with it.
Certificates Box Defines Keys for Product Protection When certificates are used, the program can be registered only with these certificates. You can set various options for these certificates in sub-menus.
Create FixClock Key If a user breaks the time protection and changes the date, the program protected by Armadillo will cease to function. When the user runs the program in this format: program_name fixclock, he will be asked to enter the so-called "fixclock" key. If he enters the correct key, the program will start working normally.
Armadillo is a very good program, but it's too easy to remove from a protected product. For example, all the cracker needs to do is wait until the program loads into memory and decodes itself, at which point he can dump the program from memory to disc and make some small changes for the program to be fully functional. Armadillo itself makes the cracker's job easier because it creates a process in memory with the same name as the protected program, except for the suffix, TMPO. This process is fully decoded after loading into memory, and all the cracker needs to do is dump it to the hard drive.
Armadillo may be a good choice for shareware programmers who have less experience with protection programming. This application looks really professional, and I hope that its creators will find a way to improve it in newer versions. Currently, though, I cannot recommend Armadillo because it is so easy to remove, even though less experienced crackers will probably fail to do so — unless, of course, they use a decoder found on the Internet.
· Test file compression: 1,007,806 bytes
· Decompressor: Un-Armadillo and Armadillo Killer
Vbox
Vbox from Aladdin Knowledge Systems (http://www.ealaddin.com) is one of the oldest and most frequently used commercial protection programs for Windows. While it is used mostly for shareware, demo versions of expensive programs are sometimes protected with it as well.
The Vbox protection is based on time limits. A window appears every time a Vbox-protected program is launched, and from this window you can run the program itself until the time limit expires.
The first versions of Vbox were called TimeLock and were very popular. For protection, TimeLock 2 uses API calls from the tl32v20.dll library, called from the protected program. The protected application tests the return values and decides whether it will continue to run or not. It looks like this in the program:
call CallTimeLock
After this returns, the EAX register should contain a return value that will vary depending on whether the test was successful or not.
TimeLock 3.03 Through 3.10
Improvements in these versions of TimeLock include the encoding of certain parts of the program and a preview that sets the entry point (beginning) of the program. This preview contains a lot of the Vbox code that makes debugging difficult.
An API call at the beginning of the program has a rather unusual name:
call tl303inj.PleaseTraceIntoMe_MrCracker
The encoded part of the application is decoded in this function, and the return value is the entry point of the protected program (or in case of an error, the address for the ExitProcess API call). The return value is in the EAX register again, and the last instruction is to call eax, which jumps on this real entry point of the program (or on the ExitProcess API call in case of an error).
TimeLock 3.13 Through 3.15
These versions brought several innovations:
·Encoding of all program code
· Encoding of section .idata
· Calculation of the CRC of the protection's DLL library in memory
Program decoding with these versions isn't as easy as with previous ones. For one thing, encoding information is saved in an encoded .idata part. Also, the CRC control of the tl315inj.dll is in memory, which secures the protection against breakpoints (of course, not debug breakpoints), as well as against changes in the code. (You can find Weijun Li's initials in the code; he is probably the lead programmer.)
Vbox 4.0 Through 4.03
In this version, Vbox first appeared as we know it today. This version, sometimes called TimeLock 4, contains many improvements. The protected EXE is compressed, and the encoded .idata section is in a separate file. The protection itself is located in three DLL libraries:
Vboxp4xx.dll Decompresses and loads DLL files
Vboxt4xx.dll Contains the basic routine for protection of the PreviewParadise_WJ
Vboxb4xx.dll Loads vboxt4xx.dll and calls PreviewParadise
The last two DLL libraries are compressed but not encoded, and information about the imported calls are saved.
Two parts in the file, called Preview and WeijunLi, contain a good bit of code and encoded data. The first part contains normal code, while the second is compressed. Once a protected program is launched, the first call is to vboxpxx.PreviewExecGate_By_WeijunLi, which decompresses the original program in the Preview.
Once everything has been decoded, a small piece of the code contains a call to a function exported from vboxbxx.dll. This function is also first decompressed with vboxpxx.PreviewExecGate_By_WeijunLi before being launched, and it calls vboxtxx.PreviewParadise_WJ. This function also performs the CRC on the protected file, as well as on the vboxt4xx.dll and vboxb4xx.dll files. If CRC is incorrect, the program will work with a wrong decoding key, and after incorrect decoding, the CRC will also be incorrect for the decoded data. The program will then display an error message.
Vbox 4.10
This version contains the following novelties:
· CRCs for all important files are authorizing signals
· CRCs for DLL file copies are calculated in memory
· The program tries to detect a debugger in memory
If someone tries to disassemble the vboxp410.dll code in WinDasm, an error will occur in the program. IDA (Interactive Disassembler) will work fine, but it will create incorrect code.
Vbox 4.3
This latest version of Vbox offers good protection, though it is vulnerable to dumping from memory (just like Armadillo). No matter how extensive the code, you don't have to try to understand it all to crack it. All you have to do is find the beginning of the encoding program and dump it from memory. (Should the authors solve this problem in future versions, Vbox will definitely be one of the best of the commercial protection packages.) Vbox's Vbox Builder application makes it very easy to create a protected application.
It is very easy to create an initial dialog box for your program with Vbox When you launch the program, you set a path to the Vbox privilege file, which each user obtains from the software publisher. To obtain this privilege file, click the Get Privilege File button. Your browser will display the publisher's page, and you will have to fill out a questionnaire. Within a few minutes, you should receive an email containing a short file with the .prv extension. Click Next and enter a file name for the Vbox license information file, and then enter a password to prevent unauthorized people from working with your license file. Next, select the language in which you want to work, and enter the author's name, product, version, year, and product identification number.
In following menus, you will enter the most important information, including limitations on the maximum number of launches or days, or a date on which the application's trial period will expire. In the Advanced
Security Options menu, you'll set the application's protection. If you select Software Binding, users will be unable to copy the application to another computer because of secret files on the hard drive. If you choose Hardware Binding, information about the computer's hardware will be used to identify the licensed machine.
· Test file compression: 835,320 bytes
· Decompressor: Vbox Unwrapper
The Slovak Protector (SVKP)
It is especially tough to write about your own product without bias and with maximum objectivity, as you might imagine, and the Slovak Protector is my product. Still, I promise to stick to the facts and to be as objective as possible.
The Slovak Protector (SVKP) is the youngest of the commercial protection products described here. When developing the SVKP, I adopted the best of the latest trends and, as a result, the SVKP might look like ASProtect. However, that similarity extends only to their appearance and some functions. The SVKP's inner structure is completely different from ASProtect, and it is the only one of the protections I've discussed that is programmed in assembler. The fact that it is built with assembler guarantees high speed and allows for some special programming techniques that are unavailable to many other advanced programming languages.
As with ASProtect, the SVKP is able to encode parts of a protected application, which will then be able to be decoded only with the right registration key. It uses RSA keys of 2048-bytes' length, which makes it impossible to generate false registration keys. To do so, a cracker would have to have found the private key, but obtaining the private key of such a long length by calculation is simply not possible with current computer systems.
There are protected, compiled programs in the destination executables (EXE, DLL, OCX, or SCR). The protected application is not compressed, but it is encoded by the Rijndael algorithm (also known as AES). This algorithm protects against brute-force attacks, and the lack of compression guarantees that the program will run quickly.
These types of application protection are similar to those used in ASProtect:
Coding of the compiled application that, while though not very secure, is adequate in some cases.
The advantages of this protection are ease of use and high speed, and that the application can use its own registration control. The protected application uses the SVKP registration keys. It utilizes API functions to determine whether the right registration key is used.
Blocks (functions) in the protected application are decoded only with the right registration file. To use these blocks, simply mark places or parts of the application that you want to prevent people from using without the right registration key, before compiling the application to be protected. This is a very easy way to create a protected demo version of a program. For example, if you mark SAVE to be disabled before compilation, the user (without the right registration key) will be notified that the SAVE function is disabled in the demo version. Once the program is registered with the correct registration key, the marked functions will be accessible immediately.
We presently have a very serious problem facing us when it comes to commercial protection: the publishing of registration keys on the Internet. If a cracker buys a program (usually using a stolen credit card) and obtains the right registration key, he has two possibilities. First, he can attempt to remove the protection, which is not easy if the program is protected by the SVKP. Second (and a much more attractive possiblity to him), he can publish the stolen registration key on the Internet. In this case, anyone who uses this actual key can turn their demo version into a fully functional program.
The SVKP, ASProtect, and Armadillo all offer the protected application special key types generated for a specific computer to users intending to register. One advantage of these keys is that they cannot be moved between computers; thus, their publication on the Internet does not threat the application's protection.
Of course, there are some disadvantages, as well. For one, registration requires the user to send data about his computer to a server before the key is generated, but not every user likes to do that. Too, none of the listed protections work online, so a registration could be made directly using its API functions. (Further development will likely head toward enabling and paying for registration directly through a protection program, without needing to go to registration website or the producer's site.)
The biggest problem, however, arises with a change of hardware. If the user changes his hardware, the key stops working, and a brand new one needs to be generated. It is for this reason that most developers allow keys to be transferred between computers.
The SVKP includes some other progressive technologies too, the most important of which are API calls that enable a protected application to communicate with its protection , namely the function SVKP_GetRegistrationInformation. Unlike other protections, the SVKP also contains API functions with active protection, including SVKP_LockKeybord, SVKP_KillDebugger, names which reveal their purpose.
In addition to classical coded blocks, which are decoded only with the right registration key, the SVKP includes two other block types. The first type is decoded right before start-up and, after execution, the program code that contains the block is immediately deleted. I recommend that you use this first block type in initial code parts.
The second block type is also decoded right before start-up, but it is coded again immediately after execution. Use this block type for critical code parts.
Athough all of the above technologies protect against dumping, and the SVKP and other commercial protection contain active protection against dumping from memory, it is not enough. This technology offers a very effective protection against dumping a program from memory and then disassembling it.
Let's take another look at some of the technology built into the SVKP and consider the way it addresses the problems of tracers and debuggers, as well as the way it attempts to incorporate metamorphism to increase protection.
Tracers
A tracer is a program that crackers use to try to analyze the protected application on start-up or while it is running. The best-known tracer is IceDump, which is a plug-in to Soft-ICE.
The tracer analyzes instructions directly in machine code, which means that it is a really simple program. But when a tracer is well-designed it can be used in a variety of ways, depending only on the cracker's imagination. Crackers mostly use tracers to repair Import tables, which are frequently used by commercial protections to prevent a program from simply being dumped from the memory. Tracers are also used to decode protected applications by analyzing the code and waiting until the application is decoded. Once the tracer finds that the application has been decoded, it dumps it from memory. The SVKP is one of only a few commercial protections that fights tracers.
Debuggers
Debuggers are yet another problem. The SVKP uses some brand new tricks to detect debuggers, and it is the only protection able to detect and remove all types of breakpoints used by debuggers.
Metamorphism
Metamorphism is a technology with a very promising future, though it is rarely used. The youngest (and most complicated) of all listed technologies, metamorphism tries to solve the problem of protected code repeatability, which stems from the fact that current protections are more or less alike. Once a cracker figures out how to break a type of protection scheme, it is easy for him to break it again and again and in less and less time. Metamorphism tries to prevent this by changing the protection each time it is used, thus making it harder for the cracker to break the protection. None of the protections currently offered use full metamorphism, though the SVKP comes close, since it is much easier to use metamorphism in assembler than in advanced programming languages.
I leave it to you to decide whether the SVKP's protection is any better (or worse) than any other, and I hope that you have not found my opinion to be too biased. | 
Disclaimer
