Coders’ Rights Project Reverse Engineering FAQ

People have always explored and modified the technologies in their lives, whether crystal radios, automobiles, or computer software. Reverse engineering is one expression of this tinkering impulse. Unfortunately, legal regulation of reverse engineering can impact the Freedom to Tinker in a variety of ways. This FAQ gives some information that may help coders reduce their legal risk.

What is this FAQ and who is it for?

This FAQ is intended for non-lawyers who want some general information about how U.S. laws might affect reverse engineering by computer programmers. This information is provided as a general guide to the issues, and is not legal or technical advice.

The legal questions raised by reverse engineering are complex and legal risks may depend on particular facts and legal doctrines that are beyond the scope of this general guide. This FAQ is meant to familiarize you with some of the principles involved, so that you can have a more effective discussion if and when you engage an attorney to help you with your specific situation.

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

First the Scary Stuff: What Kinds of Reverse Engineering Are Most Legally Risky? ^

By using the term "legally risky" here, we aren't saying that the activity is certainly legal or illegal. We're saying that these are areas where the law may apply so any researcher considering these steps should take the time to think it through and probably get some legal help.

• If your access to the code or computer system you are studying is conditioned upon agreeing to any contractual terms (e.g. End User License Agreements (EULA), terms of service notices (TOS), terms of use notices (TOU), a non-disclosure agreement (NDA), developers agreement or API agreement), you are at greater legal risk if your research activities do not comply with their stated terms and conditions. You should talk to a lawyer before agreeing to any terms and before studying any software distributed with such terms and conditions, even if you have come into possession of that code without agreeing to anything.
• It is extremely risky to disclose or use any information you obtained subject to an NDA or other negotiated contractual obligation of confidentiality.
• It is legally risky to study software you do not possess legally.
• It is legally risky to make any copies of software that have not been authorized by the copyright owner (such as by a license agreement).
• It is legally risky to bypass any “technical protection measures” (e.g., authentication handshakes, protocol encryption, password authentication, code obfuscation, code signing) that control access to the code or any specific functionality.
• It is highly risky to copy any code into a program you create as a result of reverse engineering, because that copy could infringe copyright unless it is a fair use under copyright law. Note that copying can include both imitation of non-functional elements as well as verbatim duplication.
• It is legally risky to perform any network packet inspection unless (1) the network is configured to be accessible to the general public; (2) you have consent of all users whose packets are intercepted; or (3) you have consent of the network provider where the inspection is necessary for provision of the service or to protect the network provider’s rights and property.

Don't feel hopeless, however. Visit our section on How to Limit Legal Risk.

What Legal Doctrines Are Most Likely To Affect Reverse Engineering? ^

Five areas of United States law are particularly relevant for computer scientists engaging in reverse engineering:

• Copyright law and fair use, codified at 17 U.S.C. 107;
• Trade secret law;
• The anti-circumvention provisions of the Digital Millennium Copyright Act (DMCA), codified at 17 U.S.C. section 1201;
• Contract law, if use of the software is subject to an End User License Agreement (EULA), Terms of Service notice (TOS), Terms of Use notice (TOU), Non-Disclosure Agreement (NDA), developer agreement or API agreement; and
• The Electronic Communications Privacy Act, codified at 18 U.S.C. 2510 et. seq.

This FAQ does not address international or foreign law.

How Could Copyright Law Limit My Ability To Legally Reverse Engineer? ^

Reverse engineers execute code and/or make copies of software as part of analyzing the way the program works. Copyright law generally grants a certain set of exclusive rights to copyright owners, including the right to make copies of copyrighted works. Software is one category of works that are protected by copyright. As a result, if you make copies of software, you generally need either permission from the copyright owner, or your copying must fall within an exception granted by the copyright laws. Permission can be inferred from the outright sale of a copy of software or from a license agreement. The copyright exception most relevant to reverse engineering is the fair use doctrine.

Executing code also raises the possibility of copyright issues. Some courts have stated that causing code to be copied from disk into RAM may be a copy for purposes of copyright law, and if that RAM copy is unlicensed, then it is infringing. In other words, executing unlicensed code could be infringing. Further, some copyright owners argue that cached copies held in more permanent storage may be infringing.

What U.S. Copyright Law Doctrines Allow Reverse Engineering? ^

Permission: a copyright owner can always give you permission to make copies (perhaps in a license agreement), and depending on the nature of the permission, it may authorize reverse engineering. For example, if a license agreement authorizes you to “use” the software, and it does not expressly prohibit reverse engineering, that may be all the permission you need.

Fair Use: The fair use doctrine allows users to make unauthorized copies in certain circumstances. Courts have found that reverse engineering for interoperability, for example, can be a fair use.

Are There Court Decisions That Illustrate Reverse Engineering As Either An Infringing Or A Non-Infringing Fair Use? ^

• In Sega Enterprises v. Accolade,1 the maker of a leading video game console (Sega Genesis) sued a video game publisher (Accolade) after the publisher reverse engineered the console in order to make compatible games. Accolade wired a decompiler to the console’s circuitry while loading three different, licensed games. It then compared the disassembled code in order to ascertain the interface specifications for the console. This information was then compiled in a written manual, which coders relied upon in developing Accolade’s own Genesis-compatible games. No Sega code was copied in Accolade’s games—the Accolade code was entirely original. Although Accolade initially lost in the district court, the Ninth Circuit ultimately found that Accolade’s “intermediate” copying (i.e., copying solely in order to discover functional interface specifications that were then independently implemented) was a fair use, emphasizing that disassembly was the only way to gain access to the ideas and functional elements embodied in Sega’s copyrighted computer program and that Accolade had a legitimate reason for seeking such access. (Note that Sega sold the Genesis without any license agreements, so the court had no need to address any contractual prohibitions on reverse engineering.)
• Sony Computer Entertainment v. Connectix2 involved a software publisher (Connectix) that developed software known as the Virtual Game Station that emulated the Sony PlayStation game console on Macintosh and Windows computers. Development of the Virtual Game Station required reverse engineering efforts that included extracting the BIOS of a PlayStation console and observing it in a debugger, as well as disassembling the BIOS object code. Sony sued and Connectix lost an initial skirmish and was temporarily enjoined from distributing the Virtual Game Station. Ultimately, however, the Ninth Circuit reversed that ruling, finding that Connectix’s intermediate copying was a fair use. The court emphasized that the intermediate nature of the copying (i.e., no Sony BIOS code as included in the Virtual Game Station code), the necessity of reverse engineering, and the value of permitting consumers to play PlayStation games on new platforms. (As in Sega, the case did not involve any license agreements, so the court was not called upon to interpret any contractual terms against reverse engineering.)
• Atari Games Corp. v. Nintendo of America, Inc.3: Nintendo created a lock code – 10NES – to prevent unauthorized game cartridges from playing on the Nintendo Entertainment System (NES) console. Atari tried but failed to break 10NES by monitoring the communications between the authorized game chips and console chip, and then by physically examining the chips. The company then became a Nintendo licensee, which limited its right to access the10NES program. Under the license, Atari could develop five games per year for the NES and Nintendo would insert the 10NES code so that the games would play on the console. Atari then lied to the Copyright Office in order to get a copy of 10NES. It used that copy to debug its microscopic examination of the code from the chip. Atari then developed an original program that used none of the 10NES code, but which performed the same function. The court found that Atari infringed by reproducing a copy of 10NES that it was not authorized to possess. Any reverse engineering efforts untainted by the infringing copy, including chemically removing layers, microscopically examining the chip, transcribing the object code into a handwritten list of ones and zeros keying the information into a computer then disassembling the object code, were non-infringing fair uses. But any reverse engineering that made use of the copy purloined from the Copyright Office was improper. Finally, the Atari unlocking program was substantially similar to 10NES in ways not required to replicate the function of unlocking the NES console. Even though the program was written for a different chip and in a different programming language, these similarities suggested that the Atari program was not an independent creation, but an unauthorized copy.
• Compaq Computer Corp. v. Procom Technology, Inc.4: The court held that Compaq’s compilation of threshold values for parameters used to determine when failure of hard drive was imminent was sufficiently creative to be copyrightable. The company had exercised discretion in choosing number of parameters and which particular parameters to monitor, and thus these threshold values were not facts. Procom sold hard drives that were compatible with the servers marketed by Compaq and made their drives competitive with Compaq drives by copying the threshold values and thereby enabling the same failure warnings. Because Procom made a verbatim copy of these copyrighted threshold values and used them without alteration, the verbatim copies were infringing.
• Blizzard v. BnetD5: BnetD was an open source program that let gamers play popular Blizzard titles like World of Warcraft on servers other than Blizzard's Battle.net service, thereby offering players more options. BnetD programmers agreed to Blizzard’s EULA and Battle.net’s TOU before reverse engineering the game to create BnetD. The EULA and TOU expressly prohibited reverse engineering and hosting of Blizzard games on other servers. The Eighth Circuit held that these mass-market click-through licenses were enforceable contracts and that the programmers violated several parts of Blizzard's EULA, including the section on reverse engineering. Even though reverse engineering is a fair use under federal copyright law, the programmers waived their fair use rights through the EULA. The court also held that the programmers violated the anti-circumvention provisions of the DMCA when they programmed BnetD servers to emulate the authentication sequence or "secret handshake" between Blizzard game software and the Battle.net server. By doing so, BnetD circumvented Blizzard’s technological protection measure that controlled access to the copyrighted game software code. Further, the DMCA exception for reverse engineering to achieve interoperability with an independently created computer program did not apply. The EULA did not authorize BnetD programmers to use the game software with a non-Blizzard server. BnetD allowed infringing game software to operate. Finally, BnetD copied more code than was purely necessary for interoperability in order to provide an identical play environment.

How Could Trade Secret Law Limit Reverse Engineering? ^

Like copyright infringement, misappropriation of trade secrets can be both a civil and criminal offense. Generally, a trade secret is information that (1) derives independent economic value, actual or potential, from not being generally known to the public or to other persons who can obtain economic value from its disclosure or use; and (2) is the subject of efforts that are reasonable under the circumstances to maintain its secrecy. Misappropriation means a wrongful taking or publication of a trade secret.

Reverse engineering generally doesn’t violate trade secret law because it is a fair and independent means of learning information, not a misappropriation. Once the information is discovered in a fair and honest way, it also can be reported without violating trade secret law.

However, reverse engineering that violates an NDA or other contractual obligation not to reverse engineer or disclose6 may be misappropriation. Breaking a promise made in a negotiated NDA is more likely to result in a trade secret claim than violating a term in a mass market EULA. If you are subject to any contractual restrictions, whether a EULA or NDA, or if the code you are researching is generally distributed pursuant to such agreements, you should talk to a lawyer before beginning your research activities.

How Could The Anti-Circumvention Provisions of the DMCA Limit Reverse Engineering? ^

Section 17 U.S.C. 1201, the anti-circumvention provisions of the DMCA, prohibits circumvention of “technological protection measures” that “effectively control access” to copyrighted works. The law also prohibits trafficking in tools that are primarily designed, valuable or marketed for such circumvention.

In other words, section 1201 creates a potential legal obstacle for a researcher or coder if a software vendor employs mechanisms that control the way copyrighted software or other materials can be accessed or used. Many people think of section 1201 as prohibiting cracking digital rights management schemes (DRM). However, the language of section 1201 prohibits more than breaking traditional “copy-protection” mechanisms applied to DVDs and digital video downloads. It also prohibits breaking “access controls”. Software vendors have argued, or are likely to argue, that techniques such as authentication handshakes, code signing, code obfuscation, and protocol encryption all qualify as “technical protection measures” protected by the DMCA. While research on these techniques may nevertheless be legal for a variety of reasons, researchers working on encryption, security and the creation of interoperable programs have to worry about whether section 1201 applies to their research.

For more information on how the DMCA anti-circumvention provisions have been used against researchers and others, see EFF’s Unintended Consequences White Paper.

What Exceptions Does DMCA Section 1201 Have To Allow Reverse Engineering? ^

Section 1201 contains an exception for reverse engineering, as well as security research, encryption research, and the distribution of security tools, all of which may support reverse engineering. However, these exceptions are drafted very narrowly. If your research might implicate section 1201, consult a lawyer to see if you can do your work in a way that is allowed by one of the relevant exceptions or by an exemption periodically granted by the Copyright Office. The following factors are relevant to whether you are entitled to a reverse engineering, research or security exception. However, meeting any or all of these factors will not necessarily protect your work. The list is offered just to give you an idea of the kinds of things that distinguish permissible from impermissible reverse engineering:

• You lawfully obtained the right to use a computer program;
• You disclosed the information you obtained in a good faith manner that did not enable or promote copyright infringement or computer fraud;
• Your sole purpose in circumventing is identifying and analyzing parts of the program needed to achieve interoperability;
• The reverse engineering will reveal information necessary to achieve interoperability;
• Any interoperable program you created as a result of the reverse engineering is non-infringing;
• You have authorization from the owner or operator of the reverse engineered software or the protected computer system to do your research;
• You are engaged in a legitimate course of study, are employed, or are appropriately trained or experienced, in the field of encryption technology.
• You provide timely notice of your findings to the copyright owner.

If I Conduct Research Within The Section 1201 Exceptions, Can I Then Distribute Code Derived From That Research? ^

Even when your acts of circumventing a technological protection measure are allowed under a section 1201 exception, you may still be prohibited from trafficking in reverse engineering, encryption or security tools that circumvent. Do not distribute code or other tools that come from research regulated under Section 1201 without talking to a lawyer first. For more information, read our FAQ on Vulnerability Reporting.

How Could Contract Law Limit Reverse Engineering? ^

Most software today comes with EULAs, and EULAs may have “no reverse engineering” clauses. Websites or other internet services also may have TOS or TOU that purport to restrict otherwise legal research activities. Researchers and programmers sometimes receive access to code pursuant to an NDA, developer agreement or API agreement that restricts the right to report security flaws. The legal status of contractual prohibitions on security research or vulnerability reporting is still in flux. While it is more likely that a court will enforce a negotiated NDA than a mass market EULA, the law is not clear. Be sure to consult with counsel if the code you want to study is subject to any kind of contractual restriction.

How Could The Electronic Communications Privacy Act Regulate Reverse Engineering? ^

The ECPA, sections 18 U.S.C. 2510 and following, prohibit interception of electronic communications flowing over a network. Because packets are communications, network packet inspection may violate ECPA. There are many exceptions to this general prohibition. For example, the service provider may intercept and use communications as part of “any activity which is a necessary incident to the rendition of his service or to the protection of the rights or property of the provider of that service, except that a provider of wire communication service to the public shall not utilize service observing or random monitoring except for mechanical or service quality control checks.” In addition, if the parties to the communication consent, then there is also no legal problem. The ECPA is a complicated statute, so if your research involves inspecting network packets -- even you’re only interested in addressing information, such as source and destination addresses -- you should talk to a lawyer first about ensuring that your work meets one of the exceptions.

In Sum, If My Research Involves Reverse Engineering, What Can I Do To Limit My Legal Risk? ^

• Consult a lawyer
• Try to make only copies that are necessary for figuring out how a program works and for accessing the ideas, facts and functional concepts contained in the software.
• Use less “intrusive” techniques, such as observation of inter-chip communications or step-wise debugging, before resorting to decompilation or disassembly.
• Try to make only intermediate copies. Avoid using copyrighted code in the final product unless it is absolutely necessary.
• Have the reverse engineering team that studies the code develop a written manual that describes the necessary interfaces in purely functional terms, then engage separate developers to build original code based on the manual and without access to the copyrighted software.
• Acquire the software that you are reverse engineering legitimately. Purchase as many copies as you need to accomplish your reverse engineering. Do not use “cracked” or other adulterated versions from Internet sources.
• Watch out for and do not agree to “no reverse engineering” clauses in license agreements or terms of use.
• Watch out for “technical protection measures” (e.g., authentication handshakes, passwords, encryption, code obfuscation) that control access to the software as a whole or to particular modules or functionality.
• If your research involves interception of packets without the consent of the parties to the communication, you should consult a lawyer.
• Try to avoid disseminating the results of your research in a way that promotes copyright infringement or computer fraud. See also our FAQ on Vulnerability Reporting.
• 1. 977 F.2d 1510 (9th Cir. 1992).
• 2. 203 F.3d 596 (9th Cir. 2000).
• 3. 975 F.2d 832 (Fed. Cir. 1992).
• 4. 908 F. Supp. 1409 (S.D. Tex. 1995).
• 5.Davidson & Associates DBA Blizzard Entertainment, Inc.; Vivendi Universal Inc. v. Jung et al., 422 F.3d 630 (8th Cir. 2005).
• 6. In DVD CCA v. Bunner, the defendant posted a copy of DeCSS acquired by reverse engineering, and the DVD CCA alleged violations of California’s Uniform Trade Secrets Act. The trial court found the trade secrets were acquired by reverse engineering in violation of a license agreement and therefore acquired by improper means. DVD Copy Control Ass'n, Inc. v. Bunner, 31 Cal.4th 864 (Cal. 2003). While the California Supreme Court’s subsequent opinion reached only whether a preliminary injunction violated the first amendment, a concurring opinion rejected the argument that a "no reverse engineering" EULA clause transformed reverse engineering into something other than a "fair and honest" way of acquiring trade secrets. See id. at 875, 901 n.5 (Cal. 2003) (Moreno, J., concurring) ("[N]owhere has it been recognized that a party wishing to protect proprietary information may employ a consumer form contract to, in effect, change the statutory definition of "improper means” under trade secret law to include reverse engineering, so that an alleged trade secret holder may bring an action even against a nonparty to that contract.")