Compressing or encoding programs is an excellent way to add additional product protection. One advantage of compressing a program is that the program must be uncompressed before it can be changed. Also, better compression programs complicate program debugging, and, of course, you cannot disassemble a compressed file. (While it may still be possible to create a loader that will change the program code directly in memory once the program has been decompressed, no well-protected program should allow anything like this.)
Compressing all of a program's files makes it difficult to change things like text, but compressed programs will run a bit more slowly than uncompressed ones (though the performance hit with a good compression program will be insignificant.) Rather than compress all of a program, you can compress executables only—this will not slow the program down at all, though start-up will be slightly slower (because compressed programs are decompressed in memory during start-up).
When deciding whether to use compression, find out whether there is a decompressor for the particular compressor you want to use. If so, don't use it. For example, while PKLITE is the best compressor for EXE files in DOS, there are many decompressors. Your best bet, of course, is to create a new compressor. Still, most programmers will use the preprogrammed ones, so we'll take a look at a variety of compression and encoding programs for executables, as well as some other types of commercial protection.
aPLib
aPLib (http://home19.inet.tele.dk/jibz/apack/index.html) is a commercial compression library for programmers who want to compress data in their programs, created by the great programmer Joergen Ibsen. aPLib is used by many compression programs for executable files because it is one of the best products in the field.
ASPack
ASPack (http://www.aspack.com) is a compression program for EXE, DLL, and OCX files. It is easy to use, even for less-experienced users. On the other hand, more-experienced programmers may not like it because the program menu doesn't offer many options, as shown in Figure 5.1.
To remove ASPack, all you need is a special decompressor, though you can also create a loader that will change the program code directly in memory. (ASPack has no protection against anything like that.) I have even seen a program on the Internet that makes it possible to create these patches for ASPack.
Compress Resources Compresses resources along with the program.
Create Backup Copy (.bak-file) Creates a copy of the compressed file.
Auto Run After Loading Compresses the program automatically as soon as it is loaded.
Exit When Done Closes ASPack once a program has been compressed.
Max Compression Compresses the program as much as possible.
Use Windows DLL Loader Uses the Windows DLL loader (this is important if you have an old Borland C++ linker).
Preserve Extra Data Preserves extra data located after the end of a file. (This mostly concerns files with overlay data.)
Add Into Context Menu Adds an ASPack item into the Explorer menu. If you right-click on a file, you can immediately compress it with ASPack.
Section's Name Specifies a section name for the decompressor data in the compressed file (this is a kind of author's mark).
Language Sets ASPack's language.
ASPack is a very good compression program, but it needs to be toughened up with more anti-debugging tricks. On the other hand, because its decompression routine doesn't contain any incompatible operations, it shouldn't cause problems with most programs, and it does offer very good compression.
In recent versions, the ASPack programmers have focused on dumping the program from memory in an effort to protect the import table as much as possible. They seem to have forgotten, though, that without good antidebugging tricks and anti-disassembling macros, it is very easy to trace and view the ASPack code, so it will not take long before a new decompressor appears.
Test file compression: 486,400 bytes (using an unregistered version of ASPack with maximum compression option turned off)
Decompressors: ProcDump and UnASPack
Ding Boys PE-Crypt
Ding Boys PE-Crypt (shown in Figure 5.3) is another commonly used executable file encoder. It's particularly interesting because it implements anti-debugging tricks designed to make it impossible to run an encoded program when a debugger is present in memory. The creator's radical solution to this problem is also interesting because the program will freeze without warning if a debugger is in memory. Still, the program's encoding isn't too difficult, and it's no surprise that there is a decoding program freely available on the Internet.
decodes only 29 bytes, and each contains anti-debugging code, which means that the cracker has to remove this code from each individual loop. Manual decoding would therefore take several hours. (Of course, if you use a decoder, it will take only a few seconds.)
Once you run the program, you will see a menu from which you can select several encoding functions, as discussed in the list below. At the top you'll see a field where you can type a path to the program that you want to encode, or you can click Open and browse to the program. Use Run to start the program.
Start Message Sets a message that will appear when the program starts.
Restrictive Date Sets a date on which the program will expire. (It is surprising that you can set only months.)
Restrictive Times Sets how many times the program can be run.
Restrictive Message Setting Specifies a message to appear after one of the time limits expires. Pass Word Sets a password that will always be required to run the program.
Register Key Sets a registration number for the program. (Ding Boy's PECrypt supplies you with a program that will calculate such a number for you.)
Password. Register Message Setting Sets the text of a message that will appear after an incorrect password or registration number has been entered.
Ding Boy's PE-Crypt is definitely one of the better encoding programs and, because it is not too widely used, it may be more effective against crackers. Manual decoding of PE-Crypt-encoded files is both difficult and very time consuming, though who knows whether decoders will really have a problem removing Ding Boy's PE-Crypt.
Note Ding Boy's PE-Crypt's universal functionality is diminished by the fact that it cannot be used under Windows NT, Windows 2000, or Windows XP. Also, while the program itself is in English, its documentation is in a language unknown to me, which may be a problem for many users.
Test file compression: 1,729,553 bytes
Decoder: Undbpe
NeoLite
NeoLite (http://www.neoworx.com) compresses executables including EXE, DLL, and OCX files. While the compression level is very high, the authors forgot to protect against unwanted decompression. In fact, the program itself can decompress files compressed by NeoLite, and the only way to safeguard against this is to select maximum compression.
I didn't manage to find any protection against debugging in the decompression routine. The only protection I did find was a set of changes in the PE header for the .text section: The program will immediately start running in the Symbol Loader for SoftICE. (I have already shown how easy it is to remove this protection in the ASPack discussion earlier in the chapter; manual decompression then takes only a short while.)
The program itself contains many functions for compression tuning and should therefore be considered a good professional compression program when protection against decompression isn't that important.
To begin using the program, choose the program you want to compress. After clicking Next, you can set several options on the next screen:
Information Clicking this button will display information about the structure of the file that you chose to compress.
Create .BAK Backup File Makes a backup copy of the compressed file.
Overwrite Existing Output Files Overwrites a file with the same name if one is found.
Update Time & Date Stamp Sets the current date and time in the compressed file. By default, the date and time are the same as those in the file that is being compressed.
Use Quick Compression Method Enables a quick compression method that is less effective but which speeds up the decompression and subsequent starting of the program.
Force Executable Compression Compresses a program even if NeoLite can't manage to shorten a program's length. The default behavior is for NeoLite not to perform any compression in this situation.
Compress Compresses the program, but it will be possible to decompress the program with NeoLite.
MaxCmp Compresses the program with maximum compression, and it will not be possible to decompress the program with NeoLite.
Change Advanced Settings Settings for advanced users.
Advanced Compression Options
The screen shown in Figure 5.4 offers a series of advanced options as follows:
This section sets the options for handling icons.
Compress All Icons Compresses all icons. It is recommended only for DLL files.
Compress All Except 1st Icon Group This is the default setting because Windows Explorer uses the first icon group for displaying files. (If these icons were compressed, the files would not be displayed correctly.)
Do Not Compress Icons No icons will be compressed. Preserve Data
Determines whether extra data that may be located in the so-called overlay will be compressed.
Don't Preserve Extra Data All extra data is ignored and removed from the final compressed file.
Preserve Extra Data at End of File All extra data is located after the end of the file is preserved.
Preserve Extra Data at End of PE Image All data is located after the PE image is preserved.
NeoDataSim without Compression Extra data will not be compressed. This is a model developed by the authors of NeoLite for preserving extra data.
NeoDataSim with Compression Extra data will be compressed. This is the default setting, and is a model developed by the authors of NeoLite for preserving extra data.
Other Resources
This section includes settings for compressing resources in files. Compress Bitmaps Compresses all images. This is a default setting. Compress Cursors Compresses all cursors. This is a default setting. Compress Other Resources Compresses all other resources. This is a default setting. Miscellaneous
These are some other settings for the program.
Do not compress Import Table data Does not compress the Import Table data.
Compress non-ordinal Import Table data Enables the program to locate imported functions that use only numbers as names, which is not common. If a program prints out the message "Unable to locate exported function #
Compress all Import Table data Ensures that all data in the Import Table is compressed. This is done by default.
Preserve EXE Relocation Information Preserves all relocation information in the file.
Thunk EXE exports Adds a code into the decompressing routine code that deals with EXE files that set export function values, before running the main function itself. (This doesn't affect DLL files.)
NeoLite is one of the best professional compression software packages. However, as far as compression itself is concerned, it isn't that good at protecting against decoding and debugging. I would recommend NeoLite to professional programmers who care about the size of a file but who are not particularly concerned about security, and I hope that future versions will contain some protection.
Test file compression: 646,577 bytes
Decompressor: ProcDump
NFO
NFO is a very simple encoder for PE files that doesn't allow you to set parameters before file encoding. Files are only encoded and optimized, which shortens their length slightly, but they are not compressed. (Unfortunately, the programmers didn't take Windows NT, Windows 2000, and Windows XP into consideration, and an encoded program will not run under these operating systems.)
The decoding routine is well programmed and, at first sight, appears hard to debug because it contains many anti-debugging and anti-disassembling tricks. Still, you can easily find a decoder for this encoder on the Internet.
Test file compression: 1,583,104 bytes
Decompressor: unNFO
PECompact
PECompact from Collake Software (http://www.collakesoftware.com) is compression software for executable files. It was created by the excellent programmer Jeremy Collake and works with EXE, DLL, and OCX files.
The entire program is written in assembler and uses two compression libraries for compression: aPLiB is the first of them, and it is one of the best compression algorithms. The other library, JCALG1, was programmed by Jeremy Collake. Unlike aPLiB, it is open source, and you can use it for free.
I was surprised to discover that if you use maximum compression, JCALG1 compresses even better than aPLiB (though compression does take quite a long time). Loading compressed files will take about the same time with both libraries.
The software's design is really very practical. You set the compression level by means of a simple volume control, and then choose the type of program you want to compress. The advanced configuration item (shown in Figure 5.5) contains a detailed menu where you can set many switches, including settings for compression optimization, whether the decompressor in the file should be optimized for size or speed, which resources will be compressed, and other settings. (You can find detailed descriptions of the settings in the documentation.)
I was slightly disappointed, however, in how easy it was to remove PECompact. The developer claims in the documentation that the program will complicate debugging, but I don't think is very true because I didn't find any anti-debugging tricks (which means it isn't difficult to debug). Otherwise, this is one of the best compression programs. If you need a high compression ratio and you don't care that the compressor may be easily removed, PECompact is a great choice.
Test file compression with JCALG: 526,336 bytes
Test file compression with aPLIB: 537,088 bytes
Decompressors: ProcDump and tNO-Peunc
PELOCKnt
PELOCKnt (shown in Figure 5.6) is one of the older but still among the best encoding programs for executable files. The Marquis de Soiree demonstrated considerable programming skills here. Debugging a program protected with PELOCKnt isn't easy at all, because it contains many anti-debugging tricks and the whole code is full of anti-disassembling macros. You can set several program switches, including:
It has been some time since the last version of PELOCKnt appeared, and a decoder has, naturally, appeared in the meantime. Unfortunately, it seems that PELOCKnt is currently a dead project. This is unfortunate, since it truly is a good program.
Test file encoding: 1,703,936 bytes
Decoder: PEUNLOCK-NT
PE-Crypt
PE-Crypt is a great example of what can happen when two of the best crackers get down to writing protective software.
I encountered something like this for the first time in DOS when virus creators tried to protect their works in this way against debugging and against heuristic analysis. These systems are based on a simple principle but are very difficult to program. Only a skilled assembler programmer will succeed, and such a person must know the PE file structure perfectly. There aren't many people who know both of these fields really well.
The whole file is either encoded or compressed. At the beginning, there is a routine that decodes (decompresses) the file. This opening routine is very interesting, since any fool who knows something about PE-Crypt will try to trace it. What is so interesting about it? The answer is very simple: The routine doesn't make any sense at all. I have managed to decode several programs encoded by PE-Crypt, but this work requires tremendous patience.
Figure 5.7 shows a list of PE-Crypt's options.;immediately jumps farther
I tried to apply PE-Crypt to a 4KB program. After encoding, the program was 35KB, meaning that the decoding routine takes about 30KB. Tracing such a routine would take an unbearably long time, which is bad news for those who would like to try it.
If PE-Crypt is traced or stopped by an API call breakpoint, it causes an error and the program will not run correctly. (PE-Crypt is protected by various anti-debugging tricks.)
It is possible to place anti-SoftICE routines into the program code, and rather difficult to discover them when a new and smart code is used. If a programmer takes care of other problems as well, he can rest assured that even the best crackers will spend endless hours or days on his work. Even if a cracker manages to get past all the protective software and find a place to make changes, he hasn't won yet.
When a file is encoded or compressed with PE-Crypt, you can't make a direct change to the program code. Your only choices when working with the file are to:
Manually remove PE-Crypt from the file.
Create a loader (a memory patcher).
Manual Removal
Manually removing PE-Crypt from a file is difficult, and it's very easy for a cracker to make a mistake. I don't want to claim that it is impossible, because there are people who have managed to do it. If you want to try it, I recommend using a less well-known debugger called TRW instead of SoftICE.
Another, much better, possibility is to use a PE-Crypt remover (such as Bye PE-Crypt). Once PE-Crypt has been removed, making changes in the protected application's code will not be a problem.
Creating a Loader
In order to create a loader you need to write a program that will run the compressed file, decompress it in memory, and then make changes directly in the memory.
You will have trouble if API hooking or anti-memory-patch functions were switched on before encoding. In these cases, PE-Crypt will try to prevent the loader from making code modifications. This function isn't very popular, though, because it isn't compatible with Windows NT, Windows 2000, or Windows XP. However, if a programmer is sure that his product will not be used under Windows NT, Windows 2000, or Windows XP, he may use these functions.
PE-Crypt Options
PE-Crypt offers a lot of options in its Options menu: Create Backup File (*.sav) This creates a backup of the original file.
Virus Heuristic This inserts a heuristic routine into the file for antivirus and anti-change protection. Resource Compression/Encryption/Ignoring:
Compression This uses LZW compression to compress the resource part, and it leaves icons and other information concerning the version of the program alone.
Encryption This encodes the resource part while leaving icons and other information concerning the version of the program alone.
Ignoring This function makes PE-Crypt ignore the resource part. This function is necessary when encoding fails or when the icons aren't correct.
Relocation Encryption 12-Bit/16-Bit/Relocation Packing:
Relocation Encryption 12-Bit or 16-Bit This will encode relocations (Fix-up Table) of the PE file and will add the Relocation-Loader.
Relocation Packing This compresses relocations (Fix-up Table) of the PE file by means of DELTA compression and the LZW routine.
Anti-Debugging Procedures This adds anti-debugging tricks for SoftICE that are compatible with Windows 9x and Windows NT.
Enable Hooking of API Function This enables a protective device against program-code changes in the memory. After you switch this function on, you will see a window with API calls in which you can select the API calls used by your program.
PE-Crypt allows CRC warnings. With this function enabled, a CRC test of the code part of the program is performed with every API call that was selected. You shouldn't set API-hooking on frequently called APIs, or on API functions that are located in time-critical sections of the program. Problems under Windows NT, Windows 2000, and Windows XP could occur with these settings.
Erase PE Header This will delete the program's PE header after the program has been started. This function won't work with Windows NT, Windows 2000, or Windows XP, or after compilation with some compilers.
Disable TLS Support This switches off the internal TLS support of PE-Crypt. You only need to switch this function on when the program doesn't run after encoding.
Import Hiding This adds protection against generic decoders, such as ProcDump or GTR95. You have to test it, though, since some programs don't want to run with this function enabled.
Anti-Memory Patch This is similar to the Enable Hooking of API function. It also protects against changes in the program code. In contrast to the enablehooking function, this one is focused on threads. It may not work with Windows NT, Windows 2000, or Windows XP.
Anti-Breakpoints This function switches on protection against breakpoints with API calls in SoftICE (bpx API, bpm API). It may not work in Windows NT.
CRC Warnings:
Display Window on CRC Error If PE-Crypt encounters a CRC error (such as when the program code has been changed) it will display an error message.
Hang-up on CRC Error The process will freeze in case of a CRC error.
PE-Crypt Summary
PE-Crypt was probably the best product in program protection until its decoder Bye PE-Crypt appeared. While PE-Crypt was successfully used with Settlers 3, for example, there's not much point in using it today because it can be removed so easily.
Note There is one other version of PE-Crypt that is used by some cracker groups. This is a slightly different version, and you cannot remove it with Bye PE-Crypt. Unfortunately, it is only for internal use of the group and therefore is not accessible to the general public.
I don't want to damn PE-Crypt here. You can still use it, and the less experienced crackers will have a tough job removing it. Unfortunately, there don't seem to be any hints of a new version in development.
Test file compression: 864,256 bytes
Test file encoding: 1,052,672 bytes
Decompressor: Bye PE-Crypt
PE-SHiELD
At this writing, PE-SHiELD (shown in Figure 5.8) is probably the best encoder for executable files, even though the current version cannot encode DLL files (parts of it are incompatible with them). On the other hand, because PESHiELD won't decode DLLs, it's safe to use to encode EXE files.
ANAKiN, PE-SHiELD's creator, is clearly at the top of his field and he created many of the anti-debugging routines that are now commonly used. (You can reach him at anakin@rockz.org.) In fact, it took almost a full year for a decoder to appear. The program is so good because its decoding is polymorphous, meaning that it changes with each new encoding, just like a virus. This polymorphous characteristic makes it impossible to find where the encoding ends or where any other orientation points.
The only way to correctly decode files encoded with PE-SHiELD is to analyze the code with heuristics to determine each particular instruction's function (this is precisely how the PE-SHiELD decoder works). While people have attempted to decode PE-SHiELD using ProcDump, they have failed because PE-SHiELD contains many protections against tracing in general, and ProcDump in particular.
PE-SHiELD contains many anti-debugging tricks that make debugging nearly impossible. For one thing, it checks all API calls on the breakpoints located in the Import table. It deletes debug breakpoints while running, and thus renders debugging programs useless.
I am not sure whether ANAKiN was the first to use heuristic API calls, but PE-SHiELD masters this method very well indeed. The program heuristically analyzes its opening before the API call, since its opening changes with various Windows versions. As such, it can start the API code elsewhere, omit the beginning of the API service, and jump to someplace like MessageBoxA+8, thus bypassing possible debug breakpoints for API calls.
Another great PE-SHiELD feature is its ability to optimize a file with the -r switch. Files optimized in this way, while not encoded, will be optimized in the best possible way. In my view, PE-SHiELD is absolutely one of the best optimization tools.
At this writing, ANAKiN is working on a new version of PE-SHiELD that should offer completely rewritten code, not a mere update or error correction (there are almost no errors to correct anyway). Considering ANAKiN's abilities, I can say with some certainty that the new version will be a hard program to break.
PE-SHiELD is shareware that may be used for private purposes for free. (The unregistered version is fully functional.) The encoded file shows that it was encoded with an unregistered version, along with other information.
Test file encoding: 1,622,016 bytes
Decoder: UnPEShield
Petite
Petite is also commonly used to compress executables, most often together with SecuROM. Before compression begins, you can set the classic ratio of speed to quality for the compression, though there aren't many additional options (see Figure 5.9).
Petite's decompression routine isn't very well protected against debugging, and it can be manually decompressed. While at this writing there was not yet a decompressor for the current version, 2.2, this version isn't very different from version 2.1, so it probably won't be long before a decompressor appears.
Test file compression: 538,490 bytes
Decompressor: ProcDump
Shrinker
Shrinker, shown in Figure 5.10, from Blink Inc. (http://www.blinkinc.com), is a rather expensive commercial compression tool. The latest version is over two years old, which suggests that it isn't in continuous development. This is a pity, because Shrinker offers pretty good compression and it is still usable. It also contains some good anti-debugging tricks.
Test file compression: 723,456 bytes
Decompressor: ProcDump
UPX
UPX (http://upx.sourceforge.net) is a wonderful, free (GPL'd) compressor for executables that ranks among the best. There are versions for DOS, Linux, and Windows, but we'll focus only on the Windows version here because it's the most commonly used.
UPX's lack of a GUI may be a disadvantage these days, but one talented individual has created a GUI for it. Personally, I don't miss the GUI, though there is also an official UPX GUI in the works.
Because UPX was beta tested for almost two years, it's likely that any major faults have been removed and that your programs will work correctly after compression. My tests rank UPX as the second best compression program, after ASPack. While its compression routine takes a bit longer to run, the results are very good. Still, it is very hard to say which PE Compressor is the best. For some files, UPX is better than ASPack, but for others it is the reverse.
Unfortunately, UPX is much too easy to remove because it doesn't seem to contain any anti-debugging tricks or other protection. Programs compressed by UPX can even be decompressed with UPX, simply by setting the -d switch as shown in Figure 5.11 (though the current version may not always decompress programs compressed with older versions, probably due to changes in the compression algorithm).
Test file compression: 496,128 bytes
Decompressor: ProcDump
WWPack32
The latest version of WWPack32 (http://www.webmedia.pl/wwpack32) is disappointing. Its compression isn't very good (certainly nowhere near as good as ASPack's), though the program looks good. The environment is fine and compression is really easy, but you cannot set many options, including the compression-to-speed ratio.
In the main window, you'll see a directory like those in Windows Explorer (see Figure 5.12). Select the files you want to compress, and click the compression icon. WWPack32 does the rest.
Test file compression: 823,808 bytes
Decompressor: Currently none
Chapter 6: Commercial Software Protection Programs
Overview
In addition to the freeware and shareware programs discussed so far, there are a number of commercial programs for software protection. These, too, vary in quality.
When planning this book, 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 (shown in Figure 6.1), 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.
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 (discussed later in this chapter), 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 (as shown in Figure 6.2). 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.
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 (as shown in Figure 6.3 on page 80). 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.
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
#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 (see Figure 6.4). Before the program uses a protected function, it checks to see whether a particular user has a right to use the function.
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 (shown in Figure 6.5) 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).
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 (see Figure 6.6). 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.
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 (discussed later in the chapter), 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 (see Figure 6.7) 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.
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
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
Vbox from Aladdin Knowledge Systems (http://www.ealaddin.com) is one of the oldest and most frequently used commercial protection programs for Windows (see Figure 6.8). While it is used mostly for shareware, demo versions of expensive programs are sometimes protected with it as well.
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 (see Figure
6.9).
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, as shown in Figure 6.11. 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.
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 (described later in this chapter) 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.
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, as we have discussed throughout this book. 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.
No comments:
Post a Comment