Reverse Engineering and You
Let’s start with a story:
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.
Contractual Safeguards
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.
Privacy Rights
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.
Conclusion
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.
IP Enforcement for Independent Game Developers
This issue has a lot of angles and typically two or more sides to each story. On the one hand you have the enforcer, or anyone who owns original IP. An example of the stereotypical enforcer includes Microsoft, who put a complete stop to the independent development of a Command and Conquer “HaloGen” mod that employed Halo’s intellectual property, developed by a small studio called Slipstream. MS subsequently went on to have Ensemble develop Halo Wars, which is, you guessed it, a Halo RTS. Another philosophically controversial “enforcer” example is Apple, who has worked continuously to enforce its EULA against the owners of jailbroken iPhones.
At the other side of this debate is the alleged infringer, which could be an indie like Slipstream or, more problematically, the crackers and black hats who hack DRM and pirate games in a manner that damages the entire industry. This is, in fact, one of the biggest problems arising from jailbroken iPhones; it has rapidly become a problem that creates constant strain in the application and casual game markets.
Regardless of your personal philosophy concerning the identity of the enforcer or the infringer, IP enforcement is an important aspect of protecting what you create. It’s as important in commercial works as it is in open source projects even though the ideals behind enforcement may differ. The issue here is control and access, and who has that control and access. Without this article will explain intellectual property enforcement methodology without touching on personal philosophy or the identity of the infringer or enforcer. It is my belief that it is just as important for independent developers to protect their IP as it is for the majors, and as such the tools for enforcement should be available to all.
Getting it in Writing
Contracts such as EULAs, licenses, and employment agreements are the first line of defense in IP enforcement. The more clearly your contracts set out your intellectual property rights and your remedies in the event of infringement or breach, the more likely the people you contract with are to comply. This is particularly true with regard to proprietary technology, trade secrets, and ideas you want to keep confidential.
Identifying Intellectual Property. The first step in protecting your IP is identifying what you consider protected under the shield of the contract. In the case of employment agreements and NDAs you need to be as specific as possible with regard to trade secrets and proprietary technology. With regard to EULAs you need to identify all components of what you want to protect, including content you’ve licensed from third parties. One example of how this can be done* is demonstrated in the World of Warcraft EULA, which identifies IP in two places: it sets out the game, patches, and manuals in the introduction, and expounds on those basics in the “Ownership” section further down.
Identifying Permissible Use of Intellectual Property. The next step in protecting your IP via contract is clearly stating what the licensor/end user/employee CAN do. Explain what is permissible: in the case of your game’s EULA, explain what users can do with your software; in the case of your employee agreements, explain how and when employees may access or use information; in the case of non-disclosures and confidentiality agreements, explain who information may be disclosed to or when confidentiality may be waived.
Identifying Impermissible/Infringing Use of Intellectual Property. Once you’ve explained what people CAN do with your IP, you need to explain what they can’t do. For example, in the case of games, computer programs, and hardware, one major issue of contention is reverse engineering. Under the Copyright Act reverse engineering is generally (but be careful, because this is a devilishly tricky area of the law) permissible if it is done exclusively for the purpose of interoperability. However, you may not want your game or software to work on jailbroken iPhones or other gaming devices that you plan on porting to down the road. This is something that may arguably (although this is by no means settled law) be limited by the EULA. Most major content owners seem to think so. If it’s something you deem necessary to protect your future interests, you should consider including it.
Identify Remedies and Damages. This is where you let the people you’re contracting with know what they risk if they infringe or impermissibly use your IP. You should include all available equitable remedies (remedies not grounded in monetary damages), including injunctions and restraining orders, as well as statutory and actual damages or profits resulting from infringement.
DRM and Keeping Secrets. If you’re using DRM technology, you need to let people know that you’re using it. You also need to explain that the disruption or removal of that DRM will expose them to additional Copyright Act liability if they choose to crack it. In the case of employment agreements, if you’re trying to protect trade secrets you must take steps to keep information secret. This includes DRM, password protection, encryption, and making it clear to employees that disclosing that information to anyone outside of their department is a big No No.
Cracking Skulls
There’s always a possibility that someone will breach your contractual provisions, or your game will be cracked and pirated, or you’ll find an inferior clone that passes itself off as the original. You will be angry and you will want to do everything you can to stop this from happening. First, calm down. Immediately calling a lawyer and filing a complaint or otherwise throwing a fit is expensive and probably bad for your health and peace of mind. Next, evaluate the validity of your claim. Do you have a claim? Is it really infringement? Would you know if it weren’t? For example, if the product is similar or identical to your own but released prior to or very shortly after your own, there’s a strong presumption of independent creation (which isn’t infringement under Copyright Law). You may want to talk to an attorney before going further. Take a deep breath and review the suggestions below, from most cost efficient to least. In some cases you may want to skip the first option, but as you’re an independent developer you may garner more sympathy from other small collectives, pirates, or studios who are (perhaps unwittingly) infringing on your rights.
Contact the people directly. A polite phone call or casual e-mail as a first step can go a long way in preventing future ill will or the need to lawyer up. If the infringer isn’t aware that the material is infringing or if they don’t understand the basics of IP law, they may comply with a friendly request without any further cost to you. This isn’t always the case, but as I said above, you’re an indie. There’s camaraderie among your fellow compatriots and there’s nothing wrong with taking advantage of that good will to protect your IP.
Send a Cease & Desist. If the first approach is unrealistic or ineffective the next option is a more formal C&D. This should typically come from a lawyer, but if you’re still trying to avoid the need to lawyer up you will want to at least include the following:
- An introduction that sets out your name, your product, and where your product can be found;
- A description of the rights you hold in the work, including any music, artwork, engines or code you’ve exclusively licensed;
- A description of their work, and how it is infringing;
- A citation of the laws being infringed, including Copyright law, Copyright Circumvention laws, trademark and unfair competition;
- A list of actions that they must cease and desist;
- A request for damages, if relevant;
- A “respond to by” date;
- Your preferred contact method.
Before you go any further. Have you registered your work/trademark? Under U.S. law you can’t bring an action for copyright infringement against anyone until you’ve filed your application, paid your fee and submitted your deposit. In the case of trademark, monetary damages including profits aren’t available unless your mark is registered and you’ve included the ® symbol or some other notice of registration. The sooner you register the better. Under Copyright law you’re entitled to statutory damages so long as the infringement occurred after you’ve fully completed your application and submitted your fee/deposit, or within three months of the infringement. Since the minimum statutory award is $750 for each infringement registration really shouldn’t be put off. In fact you should make it a policy to register as soon as you complete a project and have something to submit to the copyright office.
Send Takedown Notices. Send takedown notices wherever you find your infringed work. Bear in mind that the DMCA safe harbor only applies to those sites with a registered DMCA agent. If the site or service provider doesn’t have an agent you may want to instead send another C&D explaining why they are also infringers.
File a Complaint. This is certainly the point of no return. If you haven’t lawyered up yet, do so now. If your C&Ds have gone ignored or the infringer has sent a put back up notice in response to your take down, the only way to get that infringing material taken down again is to file a complaint and send a copy of that complaint with a second take down notice. Most websites with DMCA provisions will explain that process in their EULA. You will likely be filing your complaint in federal court and you will want to include every possible cause of action available, including all possible state claims.
At this point the conflict could take a few turns. If this catches the infringer’s attention, you can try to achieve settlement quickly or use some of the mediation or arbitration techniques described previously. It’s typically at this point that enforcement gets pricy and time consuming, but it may be a necessary step to protect your rights.
* Direct copying from any document including EULAs and other contracts without permission from the original drafter or document owner is typically considered copyright infringement. Draft your own or hire an attorney to draft it for you.
Speaking of DRM: Call for Comments
Every three years, the Library of Congress puts out a public call for comments to determine whether certain classes of copyrighted works should be exempt from 17 U.S.C. §1201(a), which penalizes circumvention of copyright protection technology.
The LoC asks the public specific questions relating to the types of copyright protection technology currently in effect and the types of copyrighted works that are affected by the technology. They further ask how non-infringing uses of certain copyrighted works are hindered by the anti-circumvention laws. Bear in mind that 17 U.S.C. §1201(a) (and the exemptions considered) concern only circumvention of technology that controls access to copyrighted works. Specific copyright violations for unauthorized reproduction and distribution are still covered under 17 U.S.C. §106, and the importation, sale, or distribution of circumvention tools is regulated by 17 U.S.C. §1201(b).
This raises a few questions. First, is this an effective rule-making device considering the rapid advancements in copyright protection technologies? Next, what "non-infringing uses" does this rule-making process consider? The language of the Act is fairly vague on this point:
"(i) the availability for use of copyrighted works;
(ii) the availability for use of works for nonprofit archival, preservation, and educational purposes;
(iii) the impact that the prohibition on the circumvention of technological measures applied to copyrighted works has on criticism, comment, news reporting, teaching, scholarship, or research;
(iv) the effect of circumvention of technological measures on the market for or value of copyrighted works; and
(v) such other factors as the Librarian considers appropriate." – 17 U.S.C. §1201(a)(1)(C)
The major point of contention with Chapter 12 of the DMCA is that it doesn't protected copyrighted works—it protects copyright protection technology. On the one hand it permits certain types of reverse engineering for computer software, while on the other it prohibits enabling interoperability for all other classes of works. One point I've alluded to repeatedly is that current technology and the supporting DMCA law enables copyright owners to sell access to content as opposed to "copies". Yet we see time and time again how these laws and technologies are abused in a manner that hinders lawful, non-infringing uses. This also hinders the ongoing effort to promote interoperability in the entertainment sector. As a result, piracy thrives and consumers remain disgruntled. Companies and content provider associations use litigation as a "deterrent" instead of taking advantage of the opportunities made available by technology.
Is the law itself flawed? Does the provision for exceptions assist in mitigating the often far-reaching and damaging effect the law has on technological advancement? Is the law even necessary, considering its premise of prohibiting copyright infringement, which is already protected under §106?