Is Reversing Legal? – Reverse engineering for beginners
Chapter – 1
- Part 1 : What is Reverse Engineering and Software Reverse Engineering?
- Part 2 : Reversing Applications – Reverse Engineering For Beginners
- Part 3 : Reversing in Software Development – Reverse Engineering For Beginners
- Part 4 : Low Level Software – Reverse Engineering For Beginners
- Part 5 : The Reversing Process : Reverse Engineering For Beginners
- Part 6 : The Tools : Reverse engineering for beginners
- Part 7 : Is Reversing Legal? – Reverse engineering for beginners
Is Reversing Legal?
The legal debate around reverse engineering has been going on for years. It usually revolves around the question of what social and economic impact reverse engineering has on society as a whole. Of course, calculating this kind
of impact largely depends on what reverse engineering is used for. The following sections discuss the legal aspects of the various applications of reverse engineering, with an emphasis on the United States. It should be noted that it is never going to be possible to accurately predict beforehand whether a particular reversing scenario is going to be considered legal or not—that depends on many factors. Always seek legal counsel before getting yourself into any high-risk reversing project. The following sections should provide general guidelines on what types of scenarios should be considered high risk.
Getting two programs to communicate and interoperate is never an easy task. Even within a single product developed by a single group of people, there are frequently interfacing issues caused when attempting to get individual components to interoperate. Software interfaces are so complex and the programs are so sensitive that these things rarely function properly on the first attempt. It is just the nature of the technology. When a software developer wishes to develop software that communicates with a component developed by another company, there are large amounts of information that must be exposed by the other party regarding the interfaces. A software platform is any program or hardware device that programs can run on top of. For example, both Microsoft Windows and Sony Playstation are software platforms. For a software platform developer, the decision of whether
to publish or to not publish the details of the platform’s software interfaces is a critical one. On one hand, exposing software interfaces means that other developers will be able to develop software that runs on top of the platform.
This could drive sales of the platform upward, but the vendor might also be offering their own software that runs on the platform. Publishing software interfaces would also create new competition for the vendor’s own applications.
The various legal aspects that affect this type of reverse engineering such as copyright laws, trade secret protections, and patents are discussed in the following sections.
SEGA VERSUS ACCOLADE
In 1990 Sega Enterprises, a well-known Japanese gaming company, released their Genesis gaming console. The Genesis’s programming interfaces were not published. The idea was for Sega and their licensed affiliates to be the only developers of games for the console. Accolade, a California-based game developer, was interested in developing new games for the Sega Genesis and in porting some of their existing games to the Genesis platform. Accolade
explored the option of becoming a Sega licensee, but quickly abandoned the idea because Sega required that all games be exclusively manufactured for the Genesis console. Instead of becoming a Sega licensee Accolade decided to use reverse engineering to obtain the details necessary to port their games to the Genesis platform. Accolade reverse engineered portions of the Genesis console and several of Sega’s game cartridges. Accolade engineers then used the
information gathered in these reverse-engineering sessions to produce a document that described their findings. This internal document was essentially the missing documentation describing how to develop games for the Sega
Genesis console. Accolade successfully developed and sold several games for the Genesis platform, and in October of 1991 was sued by Sega for copyright infringement. The primary claim made by Sega was that copies made by
Accolade during the reverse-engineering process (known as “intermediate copying”) violated copyright laws. The court eventually ruled in Accolade’s favor because Accolade’s games didn’t actually contain any of Sega’s code, and
because of the public benefit resulting from Accolade’s work (by way of introducing additional competition in the market). This was an important landmark in the legal history of reverse engineering because in this ruling the
court essentially authorized reverse engineering for the purpose of interoperability
When used for interoperability, reverse engineering clearly benefits society because it simplifies (or enables) the development of new and improved technologies. When reverse engineering is used in the development of competing
products, the situation is slightly more complicated. Opponents of reverse engineering usually claim that reversing stifles innovation because developers of new technologies have little incentive to invest in research and development
if their technologies can be easily “stolen” by competitors through reverse engineering. This brings us to the question of what exactly constitutes reverse engineering for the purpose of developing a competing product. The most extreme example is to directly steal code segments from a competitor’s product and embed them into your own. This is a clear violation of copyright laws and is typically very easy to prove. A more complicated example is to apply some kind of decompilation process to a program and recompile its output in a way that generates a binary with identical functionality but with seemingly different code. This is similar to the previous example, except that in this case it might be far more difficult to prove that code had actually been stolen.
Finally, a more relevant (and ethical) kind of reverse engineering in a competing product situation is one where reverse engineering is applied only to small parts of a product and is only used for the gathering of information, and
not code. In these cases most of the product is developed independently without any use of reverse engineering and only the most complex and unique areas of the competitor’s product are reverse engineered and reimplemented
in the new product.
Copyright laws aim to protect software and other intellectual property from any kind of unauthorized duplication, and so on. The best example of where copyright laws apply to reverse engineering is in the development of competing software. As I described earlier, in software there is a very fine line between directly stealing a competitor’s code and reimplementing it. One thing that is generally considered a violation of copyright law is to directly copy protected code sequences from a competitor’s product into your own product, but there are other, far more indefinite cases. How does copyright law affect the process of reverse engineering a competitor’s
code for the purpose of reimplementing it in your own product? In the past, opponents of reverse engineering have claimed that this process violates copyright law because of the creation of intermediate copies during the
reverse-engineering process. Consider the decompilation of a program as an example. In order to decompile a program, that program must be duplicated at least once, either in memory, on disk, or both. The idea is that even if the actual decompilation is legal, this intermediate copying violates copyright law. However, this claim has not held up in courts; there have been several cases including Sega v. Accolade and Sony v. Connectix, where intermediate copying was considered fair use, primarily because the final product did not actually contain anything that was directly copied from the original product. From a technological perspective, this makes perfect sense—intermediate
copies are always created while software is being used, regardless of reverse engineering. Consider what happens when a program is installed from an optical media such as a DVD-ROM onto a hard-drive—a copy of the software
is made. This happens again when that program is launched—the executable file on disk is duplicated into memory in order for the code to be executed.
Trade Secrets and Patents
When a new technology is developed, developers are usually faced with two primary options for protecting the unique aspects of it. In some cases, filing a patent is the right choice. The benefit of patenting is that it grants the inventor or patent owner control of the invention for up to almost 20 years. The main catches for the inventor are that the details of the invention must be published and that after the patent expires the invention essentially becomes public domain. Of course, reverse engineering of patented technologies doesn’t make any sense because the information is publicly available anyway. A newly developed technology that isn’t patented automatically receives
the legal protection of a trade secret if significant efforts are put into its development and to keeping it confidential. A trade secret legally protects the developer from cases of “trade-secret misappropriation” such as having a rogue
employee sell the secret to a competitor. However, a product’s being a trade secret does not protect its owner in cases where a competitor reverse engineers the owner’s product, assuming that product is available on the open market
and is obtained legitimately. Having a trade secret also offers no protection in the case of a competitor independently inventing the same technology—that’s exactly what patents are for.
The Digital Millenium Copyright Act
The Digital Millennium Copyright Act (DMCA) has been getting much publicity these past few years. As funny as it may sound, the basic purpose of the DMCA, which was enacted in 1998, is to protect the copyright protection technologies. The idea is that the copyright protection technologies in themselves are vulnerable and that legislative action must be taken to protect them. Seriously, the basic idea behind the DMCA is that it legally protects copyright protection systems from circumvention. Of course, “circumvention of copyright protection systems” almost always involves reversing, and that is why the DMCA is the closest thing you’ll find in the United States Code to an antireverse-engineering law. However, it should be stressed that the DMCA only applies to copyright protection systems, which are essentially DRM technologies. The DMCA does not apply to any other type of copyrighted software, so many reversing applications are not affected by it at all. Still, what exactly is
prohibited under the DMCA?
■■ Circumvention of copyright protection systems: This means that a person may not defeat a Digital Rights Management technology, even for personal use. There are several exceptions where this is permitted, which are discussed later in this section.
■■ The development of circumvention technologies: This means that a person may not develop or make available any product or technology that circumvents a DRM technology. In case you’re wondering: Yes, the average keygen program qualifies. In fact, a person developing a keygen violates this section, and a person using a keygen violates the previous one.
■■ In case you’re truly a law-abiding citizen, a keygen is a program that generates a serial number on the fly for programs that request a serial number during installation. Keygens are (illegally) available online for practically any program that requires a serial number. Copy protections and keygens are discussed in depth in Part III of this book.
Luckily, the DMCA makes several exceptions in which circumvention is allowed. Here is a brief examination of each of the exemptions provided in the DMCA:
■■ Interoperability: reversing and circumventing DRM technologies may be allowed in circumstances where such work is needed in order to interoperate with the software product in question. For example, if a program was encrypted for the purpose of copy protecting it, a software developer may decrypt the program in question if that’s the only way to interoperate with it.
■■ Encryption research: There is a highly restricted clause in the DMCA that allows researchers of encryption technologies to circumvent copyright protection technologies in encryption products. Circumvention is only allowed if the protection technologies interfere with the evaluation of the encryption technology.
■■ Security testing: A person may reverse and circumvent copyright protection software for the purpose of evaluating or improving the security of a computer system.
■■ Educational institutions and public libraries: These institutions may circumvent a copyright protection technology in order to evaluate the copyrighted work prior to purchasing it.
■■ Government investigation: Not surprisingly, government agencies conducting investigations are not affected by the DMCA.
■■ Regulation: DRM Technologies may be circumvented for the purpose of regulating the materials accessible to minors on the Internet. So, a theoretical product that allows unmonitored and uncontrolled Internet browsing may be reversed for the purpose of controlling a minor’s use of the Internet.
■■ Protection of privacy: Products that collect or transmit personal information may be reversed and any protection technologies they include may be circumvented.
The DMCA is relatively new as far as laws go, and therefore it hasn’t really been used extensively so far. There have been several high-profile cases in which the DMCA was invoked. Let’s take a brief look at two of those cases. Felten vs. RIAA: In September, 2000, the SDMI (Secure Digital Music Initiative) announced the Hack SDMI challenge. The Hack SDMI challenge was a call for security researchers to test the level of security offered by SDMI, a digital rights management system designed to protect audio recordings (based on watermarks). Princeton university professor
Edward Felten and his research team found weaknesses in the system and wrote a paper describing their findings [Craver]. The original Hack SDMI challenge offered a $10,000 reward in return for giving up ownership of the information gathered. Felten’s team chose to forego this reward and retain ownership of the information in order to allow them to publish their findings. At this point, they received legal threats from SDMI and the RIAA (the Recording Industry Association of America) claiming liability under the DMCA. The team decided to withdraw their
paper from the original conference to which it was submitted, but were eventually able to publish it at the USENIX Security Symposium. The sad thing about this whole story is that it is a classic case where the DMCA could actually reduce the level of security provided by the devices it was created to protect. Instead of allowing security researchers
to publish their findings and force the developers of the security device to improve their product, the DMCA can be used for stifling the very process of open security research that has been historically proven to create the most robust security systems. US vs. Sklyarov: In July, 2001, Dmitry Sklyarov, a Russian programmer, was arrested by the FBI for what was claimed to be a violation of the DMCA. Sklyarov had reverse engineered the Adobe eBook file format
while working for ElcomSoft, a software company from Moscow. The information gathered using reverse engineering was used in the creation of a program called Advanced eBook Processor that could decrypt such
eBook files (these are essentially encrypted .pdf files that are used for distributing copyrighted materials such as books) so that they become readable by any PDF reader. This decryption meant that any original restriction on viewing, printing, or copying eBook files was bypassed, and that the files became unprotected. Adobe filed a complaint stating that the creation and distribution of the Advanced eBook Processor is a violation of the DMCA, and both Sklyarov and ElcomSoft were sued by the government. Eventually both Sklyarov and ElcomSoft were acquitted
because the jury became convinced that the developers were originally unaware of the illegal nature of their actions.
License Agreement Considerations
In light of the fact that other than the DMCA there are no laws that directly prohibit or restrict reversing, and that the DMCA only applies to DRM products or to software that contains DRM technologies, software vendors add
anti-reverse-engineering clauses to shrink-wrap software license agreements. That’s that very lengthy document you are always told to “accept” when installing practically any software product in the world. It should be noted that in most cases just using a program provides the legal equivalent of signing its license agreement (assuming that the user is given an opportunity to view it).
The main legal question around reverse-engineering clauses in license agreements is whether they are enforceable. In the U.S., there doesn’t seem to be a single, authoritative answer to this question—it all depends on the specific
circumstances in which reverse engineering is undertaken. In the European Union this issue has been clearly defined by the Directive on the Legal Protection of Computer Programs [EC1]. This directive defines that decompilation
of software programs is permissible in cases of interoperability. The directive overrides any shrink-wrap license agreements, at least in this matter.