Mallory the Mythical developer and two of her good buddies are big fans of “Katarina’s Conquest”, a FPS loosely based on the Bolshevik Revolution of 1917.The game incorporates modern weaponry in a historical, beautiful, and immersive environment. Unfortunately when the game was released the original developers, October Industries, didn’t expect the game to achieve such a high level of success; the servers are unable to handle the number of new users and haven’t stayed up for more than 3 hours at a time since launch.
In response to this issue Mallory and her two good buddies decide to host a private server where they can play the game with a handful of friends across the globe without worrying about the server shutting down. To do this they will have to use reverse engineering to translate the game’s network protocol so their game clients can communicate with the new server. Mallory, being an experienced and business savvy developer, immediately realizes that there may be some legal problems here.
Mallory is right—reverse engineering can be a risky endeavor and shouldn’t be attempted without first consulting an attorney. Below I’ll discuss what reverse engineering is and how it’s accomplished and, more importantly, when reverse engineering will put you and your development team at risk.
What is Reverse Engineering?
Legally speaking, the reverse engineering of computer software is any method of studying a program for the purpose of obtaining useful and detailed information about the functional components and mechanisms of the program in question. The Supreme Court defined it as a “fair and honest means… [of] starting with the known product and working backward to divine the process which aided in its development or manufacture.” This can be as simple as observing game play to determine the functional elements of the game’s rule set, or as complex as decompiling a file and analyzing its components to learn how ads are displayed across the game server.
Tools used to reverse engineer a game include debuggers, disassemblers, and network protocol analyzers (packet sniffers) to name a few. The essential function of these tools is to give the programmer access to data that reveals the precise functions and mechanics of a program so those functions and mechanics can be reproduced with minimal or no use of the original source or binary code.
Traditionally this method of learning functions and processes has been viewed as fair game and, indeed, to some extent is still protected under fair use. As a result inventors in the field of technology and software have relied on reverse engineering for decades. For example, while the Copyright Act protects the three-dimensional patterns and designs of a microchip, it expressly allows the reverse engineering of those patterns and designs (referred to by the Act as a “mask work”) to analyze the concepts or techniques embodied in the chip. Similarly many courts have found that analyzing a computer program for the sole purpose of learning and reproducing its precise functions (provided those functions are not otherwise protected under patent law) is typically fair use.
This does not, however, mean that all reverse engineering is treated equally under the law. In software and games in particular the practice of reverse engineering has been under assault for a while.
Copyright and the DMCA Anti-Circumvention Act
Machine code and source code are protected as literary work under the Copyright Act. The copying of either without permission is copyright infringement. Using any part of someone else’s code in your own project, particularly non-functional code, without permission will almost certainly make you an infringer.
Sometimes during the process of reverse engineering the programmer may want to copy a data file or the entire program; typically that type of copying isn’t permitted under the Copyright Act, although there are a few very limited exceptions for backing up files for a legal purpose (such as repairing or debugging a lawfully owned program so the program can function).
Yet Copyright Act’s protection of computer programs goes well beyond the question of whether you’ve copied anything. In fact you don’t need to copy one iota of code to run afoul of U.S. Copyright law. 17 U.S.C. 1201, the Anti-circumvention provision of the DMCA, prohibits the circumvention of any technological measures that control access to any part of the work. It also prevents the distribution of software that enables circumvention of an access control.
Circumvention under the Act means descrambling or decrypting a work, or otherwise bypassing, removing, deactivating or impairing any technological measure without permission. A few classic examples of technological measures: remember those old Sierra games that required you to input a word from a specific paragraph on a specific page of the user manual before you could play the game? That’s an access control. Data file encryption is a more specific application of an access control. CD Key and license key encryption are another classic and oft-used example. Circumventing key encryption to access the content is typically illegal under the DMCA—but that isn’t the only scenario where a programmer could find himself in hot water under the Copyright Act.
This is particularly relevant in Mallory the Mythical developer’s case; if Mallory’s new server doesn’t provide the safe guards used to control access to the original game servers, such as a CD-key or version verification protocol, her own server is circumventing access controls to the online component of the game; by distributing the program, means (such as DIY instructions), or code to access servers that don’t use the game’s original access controls she would be running afoul of the anti-circumvention provision. According to at least one court decision this is sufficient to constitute a breach of 17 U.S.C. 1201.
Note that this does not mean that all aspects of reverse engineering are prohibited under the DMCA— for instance, analyzing un-encrypted machine code in order translate those processes and functions to source code is generally permissible. However, because the definition of “circumvention” is so broad under the act it is important to be mindful of any encrypted or otherwise protected data contained in a program or program file when you are attempting to lawfully reverse engineer a process or function.
There is one major exception to the DMCA: bypassing or decrypting encrypted data files of a legally owned copy of a program for the sole purpose of making that program interoperable with other legal software (for instance, a different operating system) is expressly permitted under the DMCA. However, this does not mean that you can distribute a way to bypass a CD-key or other cracking or decrypting software to make that software playable. This is why most interoperability projects, such as ScummVM, require end users to legally own the games they make playable. They cannot legally provide a means of playing cracked games, even if the primary purpose of the project is interoperability. Interoperability must be the only purpose.
It is important to note here that this exception can be waived if you agree to an EULA that prohibits reverse engineering.
A less confusing but no less treacherous risk comes from EULAs, NDAs, and other agreements or contracts a programmer might subject themselves to when they legally license the software they want to reverse engineer. For years courts in a variety of cases have upheld contract provisions that limit the end user’s right to reverse engineer a program for any purpose. Click-wrap and shrink-wrap agreements are generally considered enforceable.
For instance, if Katarina’s Conquest includes an EULA that expressly prohibits reverse engineering and Mallory the Mythical Developer has clicked the “I Accept” button when installing the program, Mallory would likely want to shelve her hopes of creating a private server by reverse engineering the client. A programmer can be liable for breach of contract and a slew of other causes of action, including misappropriation of trade secrets, by violating the EULA.
You can’t legally circumvent the EULA for a few of reasons. If it’s a shrink-wrap agreement you’ve accepted once you’ve purchased the software. If you didn’t legally purchase the software you don’t own a legal copy. In the case of click-wrap agreements, your legal use of the program is dependent on accepting that agreement. If you don’t accept you don’t have a license to use the software. Second, the EULA’s “click-wrap” process is an access control in and of itself. Bypassing that access control so you don’t have to agree to the license has a purpose beyond interoperability that doesn’t fall under the DMCA exception.
Pay close attention to the EULA of any game or program you want to reverse engineer. Even if you hope to reverse engineer the program for legal purposes you would still be prohibited if you’ve accepted the EULA’s terms in any manner—this includes purchasing a product with a shrink wrap license or clicking the “I Accept” button during the installation process.
In almost all cases of reverse engineering of a game the only network communications Mallory the Mythical Developer can or would want to monitor are her own client’s communications with the game server. This typically won’t raise many legal issues, and in almost all cases it would be impossible to virtually “sit in the middle” and monitor an encrypted communication between a game client and a game server. That’s what the encryption is designed to prevent. However, if you’re working on the kind of project where inspecting network packets that aren’t yours come into play you should be aware of a couple of laws.
The first is the Electronic Communications Privacy Act, which is part of the Wiretap Act, (18 U.S.C. 2510 et. Seq.). Under the ECPA you can’t intercept electronic communications, which includes data packets or any other transfer of information between a client and a network provider, server, or other computer or system, while that data is en route on a network unless you’re the network provider or an official (police or other government agency) authorized to access that information for investigative purposes under the Act.
The second is the Stored Communications Act (18 U.S.C. 2701 et. Seq. ). This Act is designed to prevent unauthorized access to ISPs and network service providers that allow the transfer of private electronic communications; accessing the data temporarily stored at those points without authorization, or otherwise exceeding your authorization and obtaining data you shouldn’t have access to, can expose you to criminal liability under this Act.
Both of these laws are designed to prevent you from accessing private communications, including data packets sent over a network or temporarily stored on a network. For this reason alone, reverse engineering projects that require monitoring communications you don’t have permission to observe or analyze should be avoided.
Reverse engineering isn’t inherently illegal. However, it does implicate a variety of legal issues. This isn’t the type of project you want to pursue if you’re risk avoidant; after all, reverse engineering is traditionally done for the purpose of recreating the useful functions of someone else’s work. That alone is typically enough to get more attention from content owners than you may want or need.
However, you can mitigate your risk by contacting an attorney and learning the steps you need to take to protect yourself and your project.