Protection vs. cracking

Let's make this clear right from the start: anything can be cracked, at the very least from a theoretical point of view. Do not believe those people who try to convince you from the opposite. We have studied cracking long enough to know better. However, there exist ways to make it extremely difficult due to time related matters. Indeed, lARP64Pro makes it so hard and time consuming that so far, no lARP64Pro protected file has been cracked yet! Although of course: never say never!
Still, apart from compression and encryption, lARP64Pro defends your registration scheme by the lARP64 technology which is a sum of very hard to read obfuscated code and all kinds of advanced anti-cracking techniques like for example  anti-dumping, anti-debugging and anti-disassembling. All of these being a result of our in-house research. In short, this brings so many different defenses into your program that it is very unlikely that a cracker will succeed in his goal. Also, our 64 bit program protection software accepts and even encourages you to keep using your own licensing system. That is because it would rather be stupid to offer only the "lARP64Pro registration scheme". Even if this scheme could be implemented with (minor) variations on the theme. We have found that this would indeed only bring ease for the crackers. Once they have reversed a certain scheme, it becomes far easier to keep cracking the same registration scheme from the same protector over and over again. No, it is far more annoying to find a new system in every new program. Else, one can be sure that no matter how difficult it is, the scheme will be cracked sooner or later. No, not sooner or later but sooner than later! Hence, we deliberately aimed lARP64 technology at protecting your own (*) licensing scheme! Also, most coding is done in high level languages but cracking is done in debuggers and disassemblers in assembler language. Assembler offers so many possibilities that are not or hardly possible in high level languages. Hence, the protective  code in lARP64Pro  was also  completely coded in

General info

64 bit software cracking is the modification of x64 software aiming to remove protection methods, more specifically the shareware trial/demo version, serial number, hardware or software keys, date checks or software annoyances like nag screens and adware. It differs from the so-called reverse engineering by being an illegal action. The distribution and use of "cracks" is illegal in almost every country.

Reverse engineering (RE) 64 bit software is the process of analysis of its structure, function and operation. It involves taking the x64 software program apart and analyzing its workings in detail to try to make a new or better program that does the same thing without copying anything from the original. The purpose is to deduce design decisions from end products with little or no additional knowledge about the procedures involved in the original production. The  techniques are researched for legacy software to replace incorrect, incomplete, or otherwise unavailable documentation. Still, the term reverse engineering is often also used to refer to cracking.
Copyright (c) 2006-2010 lARP64Tech Software                                             All rights reserved

lARP64Tech
(*): obviously, if your software was keygenned by crackers before, you will need to make a (minor) change in your registration scheme before protecting with lARP64Pro.
x64 software protection shield
x64 protection
x64 compression
A little bit of history

Reverse engineering is a discovery process and is known and has been with us for a long time already. When we take a fresh look at code, whether developed by ourselves or others, we examine and we learn and we see things we may not have expected. Not only is it interesting to see how the master has done it, it also provides a quick way of learning.

"Modern" RCE started with programmers who circumvented copy protection on classic computer games in the early 1980s. Although this trend quickly became a way to distribute pirated computer software, a core of experts remained who developed the RCE field purely for academic reasons. Indeed, one can't state those people had wrong goals with their work.

Some of the legendary characters of those early days were genius software reversers and prolific authors and teachers in the matter. Their classic texts are still considered mandatory reading for RCE students today. A new generation of reversers has rediscovered the ancient texts and begun to advance the science once again. Still, reverse engineering of software became only better known around the early nineties. Since then, there has been a broad and growing body of research on reversing techniques, software analysis, program understanding, software visualization, data reverse engineering and all its related tools and approaches.

Nowadays, there is an increasing interest in reverse engineering to support platform migration, interoperability, malware detection, and problem determination.

The cracking tools

Even more today than before, the software reverse engineer is only as good as his/her tools. And RCE has quite a lot of those. In the old days, hex editors were common tools. These days, in order to edit binaries in hexadecimal which is also known as patching, one does not need a hex editor anymore. Nowadays, editing the binaries is also possible from within the debugger. A debugger is in fact an advanced disassembler offering also the possibilities of executing and controlling the code at wish. A disassembler attempts to dissect a binary executable into human-readable assembly language. The disassembler software reads the raw byte stream output from the processor and parses it into groups of instructions. These instructions are then translated into assembly language instructions. The disassembler makes a best guess at the assembly language code, often with variable results. Nevertheless, it is the basic tool for a software cracker. However like said before, modern debuggers have disassembler possibilities built-in and most can be done with this one tool already. One could also mention decompilers as a crack tool, still, decompilers are seldom the main tool.

Many commercial software programs are compressed with commercial compressors or "packers" in order to save disk space or to make the disassembler's work a real pain. A good example of a freeware packer is lARP64Free. The highest level in hindering reversing consists of the protectors. Some compress and protect as well by adding all kinds of tricks and ruses to defeat the reverser or cracker. The used ruses by a protector can be many and under many different forms. A good example of such a combined compressor-protector is lARP64Pro.

The science of unpacking compressed and protected binaries -and we shall call it science indeed- is very complex and comprises an entire subspecialty of RCE.

Since it is illegal to defeat protections on copyrighted works, reverse engineers now program their own protection schemes for teaching purposes. Thus, crackmes are small programs that contain the heart of the protection scheme, and little else.

After all, in regard to the illegal cracking, the question is often: and who will win the battle?
Reversing, or did you mean cracking?

So, Software Reverse Engineering or Reverse Code Engineering (RCE) is the dissecting and studying of binary applications without having their source code. Reasons for reverse-engineering are several. One of the most important functions of RCE is to reverse engineer malicious code such as computer viruses, worms, trojans, addware and spyware. Reverse engineering is also practiced because the documentation of a particular device has been lost or was never written, and the person who built it is no longer available. The only way to incorporate or study functionality into new technology can be to reverse-engineer an existing hardware and then re-design it. There is also product analysis to examine how a product works inside, what components it consists of, etc. There is security auditing and don't forget that in the anti-virus software industry, there is "only" reverse engineering and hardly anything else. On the other side however, there is also the removal of copy protection, circumvention of access restrictions and the creation of unlicensed or unapproved duplicates. In contradiction to open source software which doesn't need being reviewed for security reasons, closed-source software offers the user a "black" box. Seen historically, Reverse Code Engineering has been performed on Windows platforms, but at this moment exists an increasing need for expert-everything-else-reversers as well. Indeed ... the word reverser has a dual meaning as reversing can be a good and legimate thing too! On the other hand, the word "cracking" almost always has the meaning of something illegal, of a fraudulent action.

As a teaser: who has said a virus creator shouldn't have rights on his/her work too? And where to draw the line if it is legal or not to crack the code from a virus? And how to know if this newly installed program on my PC is really what the author claims? And is it sure there is nothing wrong with his stuff?

Either way, RCE allows to study the insides of the black box. Simply by disassembling an application, one can observe the software execution at its deepest levels. At the moment the application is broken down into machine language, an experienced researcher can scan the working of any binary application, no matter how sophisticated the developer has tried to hide or protect his work.

Why would a security expert need to learn RCE? Like said before, the most common reason is to research or reverse all kinds of malware such as viruses. For example, the antivirus researchers need the ability to reverse binaries in order to counteract to them. Besides, the proliferation of adware, spyware and software antipiracy protections that "call home" raise major concern problems regarding privacy. And as an extension, even debugging your own code is a form of reverse engineering.
Laws

The legality of RCE is in question in many areas. Almost all software is shipped with an end-user license agreement or EULA, just like lARP64Free and lARP64Pro. According to lARP64Tech and those other software manufacturers, by clicking "I agree" when installing software, one is contractually bound to accept the licensing terms. Most EULAs include an article that prohibits the end user from reverse engineering the software in order to protect the intellectual property of the developer. There is no doubt that in these cases where the author prohibits reverse engineering explicitly, people who still reverse engineer such binaries break the law. In fact, the Digital Millennium Copyright Act (DMCA) forsees harsh criminal penalties for some examples of reverse engineering. One might raise the question why so many people risk these penalties and seem to be unable to stop those criminal actions. Let's see a little bit of history first to be able to answer this pressing question.
The answer is dual: on the one hand, developers should use a professionally made combination compressor and protector to protect their software from crackers. lARP64Pro is your first choice for 64 bit software protection. On the other hand, developers should also apply some basic rules to their registration schemes. See protection measures for developers.
lARP64Tech

So, with all the discussion, pro's and con's described above, what is the eventual decision? For lARP64Tech, the answer is clear: reversing does indeed have a right for existance. Crackers are allowed to study my software. But this right for existance does not mean "that they can distribute my software for free"! Indeed, and we are very firm in this: nobody has the right to crack one's software to distribute it for free! Those crackers can as well write their own programs ("crackme's") and crack those. There is absolutely no need to steal our income and those people have certainly no need to make drop our revenues from our hard work. Period! Ask any developer who has suffered from his programs being cracked how he thinks of this! He will answer immediately that he/she has lost money, and not a small amount but often an awfull lot of money was lost!

But if laws can't help us to the full extent ... what's next? Obviously, there is only one solution: developers themselves should protect their work. But how?
Pro and con

Well, it has been said by authorities in the field that crackers and developers of protection mechanisms are not just opponents ... they are also colleagues. If one assumes that crackers are parasites, exploiting the programmer’s inability to build high-quality protection mechanisms, then one has to realize that programmers are also parasites, exploiting the end user’s inability to write programs!

Reversing with the emphasis on the illegal action and programming with the emphasis on the legal action, have much in common. Creating high-quality and reliable protection mechanisms requires low-level programming skills and the ability to work with operating systems, drivers, equipment and knowledge of the architecture of processors, the specific features of code generation typical for specific compilers, and the working of the libraries being used. At this level of programming, the distinction between programming and cracking becomes so thin that it is hardly possible to draw a line between them. One could compare a cracker using his tools with a burglar using a stethoscope. A stethoscope could be used by the burglar to listen to the lock mechanism of a safe to hear the tumblers fall in place. But the same stethoscope could be used by a doctor to detect heart or health problems. The tool is not inherently good or bad, nor he or she who uses the tool. The issue arises with the use the tool is chosen for. And it is pretty obvious that the stethoscope must not be forbidden nor destroyed because one could use it for less admirable reasons too.

Every protection requires careful and thorough testing to evaluate its usability, just like any other software component. In this context, the usability is interpreted as its ability to withstand firm attempts to breach it by qualified users, armed with or without cracking tools. Protection quality is evaluated not by its strength but by the relationship between the man-hours required to program it and the man-hours required to crack it. In the long run, every protection system can be cracked because cracking is only a matter of time, money, cracker abilities, tools and effort. However, expertly-designed protection does not and must not provide easy opportunities for cracking. And this is exactly where lARP64Pro comes in the game: we have made lARP64Pro so strong and time-consuming to crack that it is hardly "crackable". Still, we shall see some more arguments from the cracker's point of view, later on.

To develop protection mechanisms, the programmer must have at least a general idea about the working methods and technical tools used by his or her opponents. To master this technical arsenal at a level not lower than that of the opponent, is even better. Practical experience with cracking tools is highly desirable because it allows someone to carefully study the tactics and strategy of the offensive party, thus allowing the organization of an optimal defense. It simply allows the programmer to detect and reinforce the most probable targets against cracker attacks, concentrating on them the maximum available intellectual resources. This means that the developer of protection mechanisms must be inspired by cracker psychology and must be able to think like a cracker.

Thus, mastering the information-protection technology assumes mastering the cracking technology. If you don’t know how protection mechanisms are cracked, are unaware of what their vulnerabilities are, and have no information about the cracker’s arsenal, you won’t be able to create a strong protection mechanism that is inexpensive and easy to implement. The books about security that consider this subject exclusively from the protection point of view have the same drawback as storage devices that can only write information: they have no practical value. Studying the bad brings the good up. And knowing the enemy makes your defenses better. So indeed, lARP64Tech has studied cracking, its tools and its techniques for years. We have become quite skilled in thinking like a cracker in order to always be one step ahead of the opponent. Only extended study and learning to think like a cracker with the reason to stay ahead of them, has brought lARP64Tech the ability to develop the lARP64 technology!

When crackers are asked why they crack software, one of the most common answers is that they do it for the challenge and the thrill of success. Also, cracking is done to learn and become smarter with software. Mostly, crackers are very smart people who will work on removing software protection for days at a time, and in extreme cases even for weeks, just for the challenge of it. The cracker's success almost always depends on his motivation. It may surprise you to learn that most of the cracker's motivation is not financial. After all, crackers post their cracks and information for free. They're not making money off your software, though the people who use their cracks are saving money. Rather than crack software for financial gain, crackers are taking part in a sort of informal competition. A cracker who can remove a new and very complicated protection scheme becomes a highly regarded and respected person within the cracker community.

Another teaser: there is a common opinion that open publications about holes in security systems bring more harm than profit and that they must be forbidden. In other words, the supporters of this opinion are saying that they cannot create a worthy copy-protection mechanism and do not want to admit their errors. Is that the right solution then?

Can laws help?

It is very difficult to draw lines in this matter but lines must be drawn somewhere. As noted before, reversing has also a distinct and legal reason for existence. Laws do exist, so arises the question if those laws are firm and able to push back the evil when it arises ... the answer is not so clear ... . Let's first see what the defenders of cracking say.

Advocates of copyright laws must understand that the more intensely protection mechanisms are cracked, the more progress in the field of their development will be achieved! Under such conditions, developers have a strong motivation to create high-quality and competitive protection packages. There is no need to hide the things that every cracker can disclose using a debugger and disassembler. Scrupulous investigation of the protection mechanism must be welcomed. After all, there is the concept of the completeness of information of the goods. Attempts to hide obvious defects and drawbacks are illegal. Good things won’t suffer from it, but bad things fear openness like the plague.

The Digital Millennium Copyright Art forbids the propagation of technologies, devices, and services created to bypass existing protection mechanisms, which seems logical. Lawyers try to protect the world against obvious criminals and vandals. However, it is necessary to distinguish cracking and research activities in the field of informational technology. Someone who cracks with malicious intent is reprehensible at the least, and at the most deserves to be fined or even sentenced to imprisonment. But the penalty must be comparable to the damage caused by the cracking. There is no use in equating crackers with terrorists!
assembler. This has turned our protector into a fine-tuned anti-cracking machine. Just to be complete, let's also mention that the GUI is coded in .NET. Hence, one may need to download and install the .NET runtimes to run lARP64Free and lARP64Pro. The compressed and/or protected files don't need the runtimes though.