EFF FAQ on reverse engineering

This FAQ is intended for those who do not have a law degree, but at the same time wish to have a certain idea about how US laws may affect reverse engineering performed by programmers. This information is a general guide to issues and does not constitute legal or technical advice.
')
Legal surveys arising from reverse engineering are complex, and legal risks may depend on certain facts and legal doctrines that are beyond the scope of this guide. This FAQ is designed to familiarize you with some of the principles so that you can have a more meaningful conversation if you involve a lawyer to help you in a certain situation.

Feel free to contact EFF if you need help finding a qualified reverse engineering lawyer.

Using the term “legal risks” in the text, we do not claim that the activity as a whole is legal or illegal. We say that there are areas of activity to which the law is applicable, so any researcher who pays attention to such aspects should take the time to think about such aspects and, possibly, get some legal help.

• If your access to the software code or computer system that you are learning is governed by any contractual rules (for example, an end user license agreement (EULA), a terms of service notification (TOS), a terms of use notification (TOU), non-disclosure (NDA), developer agreement or API usage agreement), your legal risks are higher than when you are not bound by such agreements. You should discuss with a lawyer before agreeing to any conditions and begin to study any distributed software, even if you have become the owner of the code of such a program without consent to any conditions.
• The risks are extremely high in the event of disclosure or use of any information you receive, the use of which is regulated by NDA or other confidentiality contractual obligation.
• There are legal risks in case of studying the program, if you own it illegally.
• There are legal risks in making copies of the program if you are not authorized to do so by the copyright holder (for example, under the terms of a license agreement).
• There are legal risks in circumventing any “technical protection measures” (for example, authentication, protocol encryption, password authentication, code obfuscation, code signing) that control access to the code or any particular functionality.
• There is a high legal risk in the case of copying code into a program that you create as a result of reverse engineering, since such copying will violate copyrights, except in cases of fair use provided for by copyright. Note that copying can include both simulating non-functional elements and literal copying at the same time.
• There is a legal risk in the case of performing any network packet checking, unless (1) the network is configured for free access, (2) you have consent from all users whose packages you check or (3) you have consent from the network provider, when such verification is necessary to provide services or protect the rights and property of the provider.

In any case, do not feel hopeless. Check out our latest FAQ section on how to reduce legal risk.

The following five elements of US law are partly related to the relevant computer specialists involved in reverse engineering:

• Copyright law and fair use clauses codified as Section 17 of the United States Code (USC) and Section 107 of this section;
• Production secret law;
• The prohibition of circumventing technical measures to protect the Digital Copyright Copyright Act (DMCA), codified as Section 1201 of Section 17 of the United States Code;
• Contractual law if the use of the software is governed by an end user license agreement (EULA), a notice of terms of service (TOS), a notice of terms of use (TOU), a non-disclosure agreement (NDA), a developer agreement or an API agreement); and the Electronic Communications Privacy Act, codified as Section 2510 of Section 18 of the United States Code and subsequent.

Reverse engineers extract the code and / or make copies of the software as part of the analysis of how the program works. Copyright in general gives copyright holders a certain set of exclusive rights, including the right to create copies of copyright works. Software is one of the categories of copyrighted works. As a result, if you create copies of the program, you generally must get consent from the copyright holder for this, or your copying must be subject to the exception provided for by copyright laws. Consent must follow from a direct sale of a copy of the program or from a license agreement. The copyright exception most relevant to reverse engineering is the fair use doctrine.

Running the code also raises the possibility of copyright issues. Some courts ruled that the code considered in those cases copied from disk to RAM could be copying in the meaning of copyright, and if such a copy in RAM is not licensed, it is a violation. In other words, the execution of unlicensed code can be a violation. In addition, and some rights holders argue that cached copies that are available in the permanent storage location may be a violation of rights.

Consent: the copyright holder can always give you consent to make copies (for example, in a license agreement), and depending on the nature of such consent, it may allow reverse engineering. For example, if a license agreement allows you to “use” a program, and does not explicitly express a ban on reverse engineering, this may be the consent you need.

Fair Use: The Fair Use Doctrine allows users, without prior consent of the copyright holders, to make copies under certain circumstances. Courts made decisions that reverse engineering, for example, for the purposes of interaction, may be fair use.

Some of these are:

• In the case of Sega Enterprises v. Accolade , ¹ leading video game console maker (Sega Genesis) filed a lawsuit against the game publisher (Accolade) after the publisher did reverse-engineering the console in order to create compatible games. Accolade installed the decompiler into the console scheme at the time of loading three different licensed games. She then compared the disassembled code to determine the console interface specifications. This information was then compiled into a written manual that was used by programmers to develop their own Accolade games for the Genesis console. The code of the Sega company itself was not copied into the games from Accolade - the Accolade code was completely original. Although Accolade in the first instance lost the lawsuit in the district court, the Ninth Circuit Court ultimately determined that the “intermediate” copying by Accolade (for example, copying solely for the purpose of defining the functional interface specifications, which were then independently implemented) was fair use, based on the fact that disassembling was the only way to gain access to the concepts and functional elements contained in the Sega computer program and thus, Accolade would a sufficient reason for determining that access. ( Note that Sega sold Genesis without any licensing agreement, so the court did not have to investigate any contractual prohibitions with respect to reverse engineering. )
• Sony Computer Entertainment v. Connectix ² was a software publisher (Connectix), who developed a program known as Virtual Game Station, which emulates a Sony PlayStation game console on computers running Macintosh and Windows operating systems. When developing the Virtual Game Station, I had to resort to reverse engineering, which included extracting the BIOS of the PlayStation console and monitoring it using a debugging program, as well as disassembling the BIOS object code. Sony filed a lawsuit, Connectix lost the dispute in the first instance, and was obliged to comply with the ban on distributing the Virtual Game Station. However, in the end, the Ninth Circuit Court reconsidered this decision, determining that the interim copying by Connectix was fair use. The court paid special attention to the interim copying nature (for example, no code included in the Sony BIOS was included in the Virtual Game Station code), the need for reverse engineering and the importance of consumer availability of PlayStation games on new platforms. (As in the Sega case, there were no licensing agreements in this case, so the court did not make any judgments regarding the interpretation of contractual terms against reverse engineering.)
• Atari Games Corp. Case v. Nintendo of America, Inc. ³ : Nintento created a lock code - 10NES - to prevent the launch of unauthorized game cartridges on the Nintendo Entertainment System (NES) console. Atari tried unsuccessfully to crack 10NES by monitoring the exchange of data between authorized gaming chips and a console chip, followed by a physical examination of the chips. Then the company became a licensee of Nintendo, having received limited access to the 10NES program. Under the terms of the license, Atari could develop 5 games for NES annually, and Nintendo had to embed code 10NES in order for the game to be available for launch on the console. Atari then fraudulently obtained a copy of 10NES from the US Copyright Office. She used this copy to debug a microscopic examination of the code from the chip. Then Atari developed the original program, which did not use any code from 10NES, but which performed the same function. The court determined that Atari had violated rights by creating a copy of 10NES, since it was not authorized to hold such possession. Any reverse engineering attempts that were not accompanied by illegal copying, including chemically removing layers, examining the chip under a microscope, transcribing the object code into a handwritten sheet with units and zeros, coded with information in a computer when the object code was disassembled, were legitimate cases of fair use. But any reverse engineering, which resulted in the use of a copy stolen from the US Copyright Office, was illegal. To top it all, the Atari deblocking program was substantially similar to the 10NES program in areas that are not necessary to repeat the unlock functionality of the NES console. Even if the program was written for another chip and in another programming language, such similarities suggest that the Atari program was not an independent development, but an unauthorized copy.
• Compaq Computer Corp. Case v. Procom Technology, Inc. ⁴ : The court determined that Compaq’s compilation of thresholds for parameters used to determine the inevitability of a hard disk crash was a creative enough solution to be copyrighted. At its discretion, the company determined a number of parameters, as well as determined which specific parameters should be monitored, and thus the threshold values ​​were not just facts. Procom was selling hard drives that were compatible with Compaq-promoted servers, and made its hard drives competing with Compaq drives, copying thresholds and then making similar troubleshooting warnings available. Since Procom made the material carriers of such copyrighted thresholds and then used them without modification, such material carriers were counterfeit.
• Case Blizzard v. BnetD ⁵ : BnetD was an open source program that allowed players to play popular Blizzard games like World of Warcraft on third-party servers outside of Battle.net, thus offering players more options. The BnetD programmers agreed with Blizzard’s end-user license agreement (EULA) terms and conditions for using the service (TOU) Battle.net, before starting reverse engineering the game to create BnetD. EULA and TOU explicitly prohibited the reverse engineering and deployment of Blizzard games on other servers. The Court of the Eighth Circuit ruled that such mass market click-through licenses were legally binding contracts and that programmers violated several provisions of the EULA, including the provision for reverse engineering. Even if reverse engineering is fair use under federal copyright law, programmers waived these rights by accepting the terms of the EULA. The court also ruled that programmers violated the DMCA's prohibition of circumventing technical protection measures when they programmed BnetD servers to emulate the authentication process between the gaming software from Blizzard and the Battle.net server. By doing this, the BnetD team bypassed the technical protection measures of Blizzard, which controlled access to the software code of the game protected by copyright. Further, the clause in the DMCA regarding reverse engineering to achieve interaction with an independently created computer program is not applicable. The provisions of the EULA did not entitle the BnetD programmers to use gaming software on a server not owned by Blizzard. The BnetD team has allowed the work of software that violates copyright. Ultimately, the BnetD team copied more code than was necessary to ensure interoperability to provide an identical gaming environment.

As well as copyright infringement, misappropriation of production secrets can be a civil offense as well as a criminal offense. In general, a production secret is information that (1) has an independent economic value, real or potential, because it is unknown to the public or to third parties who can achieve economic benefits if it is disclosed or used, and (2) is the object of reasonable measures aimed at maintaining the secrecy of such information. Illegal taking means the unlawful receipt or disclosure of production secrets.

Reverse engineering in general does not violate the law on production secrets, because This is a bona fide and independent way of studying information, and not misappropriation. If the information becomes known with a fair and honest way of obtaining it, it can be stated without violating the law on production secret.

However, if reverse engineering violates the NDA or other contractual obligations to prohibit reverse engineering or disclosure of information, ⁶ this may be considered an illegal acquisition. A violation of the promise set forth in the NDA is more likely to result in a claim regarding the production secret, rather than a violation of the EULA. If you are subject to any contractual limitation, be it an EULA or NDA, or if the code you are studying is generally subject to terms of similar contracts, you should consult a lawyer before you begin your activity on studying such a code.

Section 1701 of Section 17 of the United States Code, which sets out the DMCA's prohibition of circumventing technical protection measures, prohibits the circumvention of “technical protection measures” that “allows you to successfully control access” to objects of copyright. The law also prohibits the sale of funds that were originally created, applied or distributed to circumvent such measures.

In other words, article 1201 creates a potential legal obstacle for the researcher or the coder if the software manufacturer applies control mechanisms for accessing its software or other available means for this. Many people think that article 1201 prohibits hacking into digital rights management systems (DRM). Be that as it may, the wording of article 1201 prohibits more than just hacking the traditional “copy protection” mechanisms used in DVDs and digital video downloads. It also prohibits hacking "access control". Software manufacturers argue or try to argue that technologies such as authentication, code signing, code obfuscation, and protocol encryption are collectively defined as “technical protection measures” protected by the DMCA. While the study of such techniques may nevertheless be legitimate for various reasons, researchers working on programs for encryption, security, and interoperability should be concerned about whether article 1201 is applicable to their study.

For more information on how the DMCA's prohibition of circumventing technical protection measures applies against researchers and others, see the White Paper of unintended results prepared by the EFF.

Article 1201 contains an exception for both reverse engineering and security research, encryption and distribution of security tools, all of which may be applicable to reverse engineering. However, these exceptions are spelled out very narrowly. If your research may involve applying Article 1201 to it, consult with a lawyer to determine if you can do your job in a manner that is permitted by one of the provided exceptions or an exception that is periodically provided by the United States Copyright Office. The following factors are essential for determining whether you are entitled to perform reverse engineering, research, or security exceptions. However, having one or all of these factors will not necessarily protect your work. The proposed list only provides you with the concept of those aspects that allow you to distinguish the allowable reverse engineering from the unacceptable:

• You have properly obtained the right to use a computer program;
• You have disclosed the information you received in good faith, which does not allow you to allege any copyright infringement or computer fraud;
• Your only goal in the workaround is to identify and analyze the parts of the program that are needed to achieve interaction;
• Reverse engineering reveals the information needed to achieve interaction;
• Any interacting program created by you as a result of reverse engineering is not subject to violation of rights;
• You are authorized by the copyright holder or the operator of the program or a protected computer system in respect of which reverse engineering is carried out to conduct such a study;
• You are involved in a legitimate training course, you are employed, or you have the appropriate skills or experience in the field of encryption;
• You provide timely notice of your findings to the copyright holder.

Even when your circumvention actions of technical protection measures are allowed by virtue of the exceptions of Article 1201, actions to implement circumvention tools for reverse engineering, encryption, or security may be prohibited. Do not distribute the code or other means that have arisen as a result of the study provided for in Article 1201, without prior consultation with a lawyer. For more information, read our Vulnerability Information FAQ .

Most software is now distributed with the EULA, and such EULA may contain provisions on the prohibition of reverse engineering. Websites and other Internet services may also have their own TOS or TOU, designed to ban any research activity in relation to them. Researchers and programmers sometimes gain access to the appropriate code under the terms of an NDA, developer agreement, or API usage agreement that denies the right to report security vulnerabilities. The legal status of contractual bans on security research or reporting vulnerabilities continues to be incompletely defined. Although it is more likely that the court will give preference to the NDA agreed by the parties than the EULA intended for the mass market, the law is not unequivocal. Be sure to consult a lawyer if the code you are going to study is subject to contractual restrictions of any kind.

This law, Section 2510 et seq. Section 18 of the United States Code, prohibits the interception of electronic data transmitted over a network. Since data packets are messages; interception of network data packets may violate the law. There are many exceptions regarding this prohibition. For example, a service provider may intercept and use data as part of “any activity that is an integral element of its service or protection of the provider’s rights or property of such a service, unless the provider of a public wireline service does not have to use its service for monitoring or accidental monitoring, unless it is for the purpose of mechanical regulation or quality control of the service. ” In addition, if the parties to such messages agree, there is also no problem. This law is a confusing document, so if your research involves intercepting network data packets — even if you are only interested in address information, such as starting and ending addresses, you must first consult with a lawyer to be sure that your activity falls within one of the exceptions.