lARP64Pro, professional protector
Range
Our protection software supports almost all types of natively compiled 64-bit x86 applications (not suited for .NET). Protected programs are compatible with any Windows 64 bit operating system ranging from Windows XP till most recent Windows 2008 Server (all 64-bit versions). The protector is updated to provide compatibility with all new versions of Windows x64 operating systems.
lARP64Pro
is the most powerful protecting system for x64 known today but it was designed to be very easy to implement. Its strong protection features will protect your application from unauthorized modifications like there is reverse engineering or cracking. Don't take our word for it: just test it out!
Ease of Use
As a 64 bit program protection software, lARP64Pro is primarily meant for developers. Still, it has been a special concern to provide an extremely easy tool in its handling. Indeed, it suffices to click a couple buttons to "lARP64" an executable. Also, you will be surprised by the speed of working: lARP64Pro works at lightning speed and the act of protecting is almost instantly!
lARP64Pro intentionally provides 'only a few' options to skip certain protection features. This facilitates user interaction and always results in the strongest possible protection for your application.
Our protector is so strong that it will provide the ultimate secure protection for your own licensing system. Hence, just continue using your own usual registration scheme. lARP64Pro will defend and hide your sensitive code from crackers by its multiple protecting system based on the in-house developed lARP64 technology.
Limitations
Functionally unlimited versions are available for download. The professional packer-protector has been provided with evaluation capabilities without time limitation. If you need to decide if the compressor or the protector is most appropriate for your specific needs, then be aware that lARP64Pro is far better suited if program security is required.
Read about lARP64 technology.
Copyright (c) 2006-2010 lARP64Tech Software All rights reserved
IDE integration
lARP64Pro provides you with command line support allowing you to integrate protection into your preferred development environment.
Royalty-free distribution
lARP64Pro allows you to protect, license and distribute an unlimited number of applications and software protected with lARP64Pro at no additional cost.
SITE
NAVIGATION
HOME
PRODUCTS
TECHNOLOGY
DOWNLOAD
ORDER
SCREENSHOTS
HELP
General info
In case of shareware or any need for software protection, we strongly recommend lARP64Pro. It is based on the same principles as the compressor but it offers so much more!This extremely strong 64 bit executable protector is also an extremely strong 64 bit dll protector.
Files protected with lARP64Pro are self-contained and are compressed first in the protecting action. This also makes your programs and libraries smaller and decreases load times across networks or download times from the net.
Protection measures for developers
A protector is the strongest defense against cracking but developers can do a lot to hinder cracking too. Developers should always apply some basic rules to their registration schemes. This will prevent the software from being cracked by the beginner cracker. Let's mention a few possibilities that the developer has. It is even not difficult, it only requires a bit of work but it is not impossible to program good protection in your own programs that makes the crackers job quite more challenging. Still, you must remember that if you use typical programming methods, you make the cracker's job easier. Most crackers use several well-tested methods to crack particular types of protection and, as such, are able to remove a large percentage of the protection scheme. The key is to use less-common methods, which will slow the cracker down or even stop him/her.
Next are a few rules for writing good protection in your registration scheme.
* First of all: if your program has been cracked, release a new version. Frequent updates to your program may put off crackers, especially when the protection was removed by changing the code. This is also because the patch will probably not work in the new version. In case your program got keygenned, then rewrite your registration scheme in a completely different way!
* Use strong encryption for the registration scheme and other sensitive areas in your code. If this doesn't stop the cracker, it will at least slow him/her down considerably.
* Never use self-describing names. For example, if you use the function names IsNotRegistered and IsRegistered in your source, then the cracker will immediately know where in the code to focus his effort. Agreed, it will be somewhat more difficult to write your programs, but cracking will become a lot harder too! It is even a good habit to use some fake names hinting to a decoy registration scheme!
* Don't use error messages (they are probably unnecessary anyway). If the program gives an error message after an incorrect registration number has been entered, the cracker can simply search the program code for the error message to track down the procedure that called it. This can for him/her even be as simple as breakpointing MessageBoxA to land immediately in the right spot. When error messages are really unavoidable, hide them as much as possible, and create them (dynamically) in real time rather than use resources for them. It's also a good idea to encode the data and the procedure that creates an error message which makes it much more difficult for the cracker to find it back in the disassembled code.
* Don't execute the registration testing immediately after input of the serial. This will make it a lot more difficult for the cracker to trace the program in a debugger. It is even better to require that the program is to be restarted before the real testing begins.
* Add random tests for the registration by using a testing method that differs from the original one. Crackers really hate them because it usually takes a lot of time to remove them. As a variation on this theme, you may want to make different schemes to test the act of registering and the registration verification at each startup. So this means that you should not call the same verification but indeed create seperate functions for this.
* Use partial checksumming in your application. When testing your EXE (and DLL) files for unwanted changes, especially in sensitive areas, crackers will be hindered to modify those areas with simple patching. Sure, they will still be able to modify the code directly in memory, so don't be afraid to test as well for changes to the program code in memory. Be aware that a cracker can change the checksum to the correct value after patching the program, so, if you perform checksums on smaller sections of the program, you make the cracker's job more challenging.
* Use nested checking routines on sensitive areas to make it harder to remove the protection. Every part of the routine should only verify a part of the correctness of the registration, not the whole of it, to prevent the registration being understood too easily when a cracker discovers it. By using more than one checking routine, the cracking of the program will often be incorrect because the cracker may miss one or more of the checking routines.
* Code a decoy registration routine in your program. This technique with false testing routines confuses the cracker since there are endless variations on the theme and it is rather difficult to detect which routine is eventually the important one.
* Don't just use the first possible registration scheme you think of in your program. The registration scheme is most certainly the most important piece of code (apart from the main function?) in your program, so, think long about the possibilities and find advice on the subject if necessary.
* Encrypt your registration using a technique that is dependent on the particular computer's hardware to make it harder to use the same file to register the program on another computer.
* Put your registration information in an unexpected place. If the registration information is kept in the windows registry, then it can too easily be unveiled. A possibility is to put it in a file that nobody would suspect from that it might hold the registration scheme data. Like for example in a DLL. By giving it a confusing name and placing such a DLL into the Windows system directory, you will make the registration scheme very disturbing and difficult for the cracker. Even if the cracker uses a file monitoring tool (filemon,... ) to follow reading/writing to files, it may take a good while before he's able to situate the registration scheme. Better still, move pieces of the registration in seperate places to make it much harder for the protection to be circumvented correctly.
* There's no need to be afraid of relatively long registration files or serial numbers. If the registration file or serial number is longer, then it takes longer to understand its forming. Also, if you make the registration file or serial number sufficiently long, it can be used to hold important information the program requires for its registered working (decoding key), and if such a program is patched, it may crash or at least not run correctly.
* Make the verification process for your serial routine incomplete but randomly test the remaining parts of the serial elsewhere, not immediately but from time to time. This is a very strong measure because it is much harder for the cracker if the so-called registered program suddenly and randomly notices it is in fact not registered due a verification on a part of the serial that was not yet performed!
* For time-limited trial shareware, you should test several time related bits of data such as file date and others. Also, you can save the date and time after each launch of the program, and then test the current date and time during a new launch. If the current date or time is the same or smaller than when the program was run previously, it will be clear that the time was adjusted.
* A common mistake is that testing routines are made too long to execute. Something that takes only one second when a program is running, already takes a long enough time to study under debugger. Everything that takes longer brings additional points of attack to the cracker. It is often true that the simpliest methods are the strongest to defeat though this certainly is not always the case for your serial verification routine. So, some decoy code in your registration scheme is often a good idea too. Nevertheless, make sure that it isn't possible for the cracker to tell whether some piece of code is important or not or they will know whether they can jump right over it.
* Consider encrypting sections of the code that are not supposed to function in an unregistered version, to be decrypted only after registration. The decrypting key must then contain the registration, so that the program cannot be decoded without it.
* If your application uses a registration number, then that number should never be visible in memory, nor should the correct serial ever be completely formed in memory. Verify parts of the serial, destroy its memory and then verify the next part of the serial. This means that it should be impossible to find your program's registration number when the program is being debugged. This means also that the serial verification should do something much more complicated than just comparing two strings. A possible but still too easy path is to encrypt the entered registration number and the correct registration number in the same way. The two numbers can then be compared without a too big risk of the cracker discovering the code. Use your imagination! You might also compare a checksum of the entered registration number with the checksum of the correct registration number, though if you do so, you will have to use more checking methods to really make sure that the correct registration number was entered, rather than modified in accordance with the checksum that the cracker had seen in his debugger.
* A simple additional but very short compare for a partial verification in a seperate thread doesn't use a lot of resources if only executed now and then. Still, these are a real pain to find.
* Consider requiring online registration though this may have some downfalls too, it is also not advisable for particular software. Still, the internet has greatly increased the feasibility of online registration and its verification. When a program is registered online, its registration data is sent to a particular server. In its most basic form, this server then sends back information to the program telling it whether the registration was successful or not. Important side-effect is that the server can also be used to send data that the program needs in order to launch the registered application. This data may range from important parts of the code to a key needed to decode parts of the program. Or the program can time-randomly check on the server if all is still fine. Still, a word of warning is at its place here: if the cracker finds the code for the servers reply (which is often really easy to find), then all is useless. Obviously, if you go for requiring online registration, you will need to defend, hide and encrypt this piece of code by all possible means!
* Do never act immediately if a registration problem is detected. Send the cracker in the woods to go play with Robin Hood for a while and make the final action very disturbing: no warning at all about what is wrong, just unregister and continue in unregistered state.
* If you limit your program's functionality, then make it a real demo by making sure that the program doesn't contain the code for the limited function. Many developers make the mistake of including the code for a function that is only to be available after registration in the registered program. In such a case, the cracker can modify the code so that the function will work.
* Use a (slightly) different registration scheme for 32 and 64 bit versions of the same software.
* Stay updated. We know that it is hardly possible to read and study all cracking material. Still, some reading about new techniques, about protection and about cracking in general never hurts. On the contrary: it will already help a lot in avoiding basic mistakes!
Remark that any of the above will avoid your software from being cracked, not even if you use all the above measures together in your program. Has your software never been cracked before? Then notice that you are either very lucky or your software was unremarked yet or your software isn't interesting enough. Still, it's better to protect your software because one never knows what tomorrow might bring ... . So, the last but certainly not the least important measure all software developers should take is ... protect your software with a strong protector made by serious people with strong knowledge of cracking techniques.
Remember that crackers are often better informed than you are. The best of them are also excellent programmers, and they cannot be surprised easily. Hence, you should use a professionally made protector: those people have studied cracking and know better than the usual developer how to best defend your software! One remark: construct and use your own registration scheme even if you really have no idea how to do this in a strong way. Once that the protector software's registration scheme is cracked, it is too easy for crackers to be able to crack the same scheme from the protector over and over again. It is far more difficult if you have your own scheme that you use together with the added protection from the commercial protector!
Good luck!
