SD Secure Start: Investigating Source Code Theft

SD Secure Start
September 2005


MORE ON INVESTIGATING SOFTWARE AND SOURCE CODE THEFT
Software IP begins where creative effort begins, and it ends where creative effort ends. (Part 2 of 2)

Proving that software is a trade secret is challenging if the software has ever been shipped to a customer who didn't sign a confidentiality agreement. It's also a challenge to prove trade secrets when clarifying additional technical definitions to law enforcement officials. It's rarely disputed that software is both code and data supplied to a microprocessor. However, this definition is usually viewed as overly limiting in practice. A more practical definition of software comes from observation of the work product and process of software engineers, the business practices of software developers and software vendors, as well as the behaviors
and commercial expectations of customers who pay for and make use of software products.

Software engineers today use several engineering tools, including a programming language, a compiler, a linker, an IDE, a UI design tool, a version-control system, CASE tools, third-party source code and object code libraries, and so on that both facilitate the software engineering process and contribute substantially to the intellectual property that is its end result. It's uncommon for new software to be written in its entirety from scratch without the help of such tools. As a result, modern software is frequently defined in terms of the original intellectual property contributed by a particular developer that imparts unto the software its special quality.

In practice, this means that software begins where creative effort begins, and it ends where creative effort ends. Dissecting software during litigation, a computer forensic expert is able to carve away the creative effort made by the parties that resulted in the software that is at issue, and consider that effort apart from the intellectual property of third parties (used with permission under license) and the impact of modern software engineering tools in the creation of the final software products. Many times, it's discovered that the software developer in fact never created, directly or indirectly, a single operation code instruction that is supplied to the microprocessor during program execution. However, the facts of the software developer's skill and competency in his art, the apparent success of the business venture, and the developer's claim that keeping secret some particular code and data enables the business to be successful, make it plain that the developer's efforts resulted in something valuable.

Copyright and trade secrets, when embodied in computer software, may therefore exist only in that special sequence of information created by a developer that the developer claims nobody else has the right to look at, decompile or disassemble.

Source Code as De Facto Trade Secrets

It's widely believed that source code is always a trade secret, particularly when effort is made to keep the source code secret or control its distribution only to authorized persons. There are any number of examples in the literature and in case law that support this view, including successful criminal prosecutions of individuals who obtain unauthorized copies of source code. (For one example, see the Justice Department's press release regarding the conviction of former software engineer Timothy Kissane in Hot Links.) Even when disclosed publicly, as were portions of the Windows source code in early 2004, the end of secrecy does not necessarily deprive the owner of the source code of that party's various property rights to trade secrets contained therein (see
Hot Links for more details).

There are many ways, however, for source code to be obtained without permission of the software owner that do not necessitate theft of source code. For example, disassembly of a software program will result in human-readable and easily modified assembly code. Some software programs are written entirely using assembly language. A conventional software debugger tool typically includes a disassembler, and many resources exist to help programmers, information security specialists, forensic analysts, and others perform sophisticated analysis and manipulation of assembly code. Computer professionals routinely use reverse-engineering tools to examine malicious software, perform forensic audits, or to demonstrate security vulnerabilities in practice. For example, the Metasploit Project provides a free information security tool known as the Metasploit Framework that is an advanced open-source (no source secrecy) platform for developing, testing, and using exploit code. Security professionals use Metasploit in conjunction with disassemblers to purposefully tamper with software to examine or test for security flaws.

Decompilers take reverse engineering a step further, enabling a copy of a software program to be used to recreate an approximation of the source code for that program. As demonstrated by the author of the dcc decompiler -- Cristina Cifuentes from the Queensland University of Technology (QUT) in Australia -- a software program that contains a fibonacci algorithm can be compiled from source code into machine code that any Intel-compatible microprocessor is able to execute, as Cifuentes shows here in hex:

55 8B EC 83 EC 04 56 57 1E B8 94 00 50 9A
0E 00 3C 17 59 59 16 8D 46 FC 50 1E B8 B1 00 50
9A 07 00 F0 17 83 C4 08 BE 01 00 EB 3B 1E B8 B4
00 50 9A 0E 00 3C 17 59 59 16 8D 46 FE 50 1E B8
C3 00 50 9A 07 00 F0 17 83 C4 08 FF 76 FE 9A 7C
00 3B 16 59 8B F8 57 FF 76 FE 1E B8 C6 00 50 9A
0E 00 3C 17 83 C4 08 46 3B 76 FC 7E C0 33 C0 50
9A 0A 00 49 16 59 5F 5E 8B E5 5D CB 55 8B EC 56
8B 76 06 83 FE 02 7E 1E 8B C6 48 50 0E E8 EC FF
59 50 8B C6 05 FE FF 50 0E E8 E0 FF 59 8B D0 58
03 C2 EB 07 EB 05 B8 01 00 EB 00 5E 5D CB


Then, using the decompiler program written by Cifuentes, source code that is functionally equivalent to the original source code of the fibonacci software program can be produced.

In order to sell and deliver to customers any operational software product, a software developer has no choice but to release all of the operation code and data necessary for another party to reverse engineer the subject software and extract from it trade secrets or even a full replica of source code. This means a computer forensic analyst is presented, in a criminal investigation or a civil dispute, with a complex set of unknowns and technical possibilities that are each equally viable as hypotheses of wrongdoing with respect to either party. In software litigation, the parties may literally argue over who was the first to conceive and implement a particular sequence of operation codes or data, with both parties claiming, at best, that they developed their sequences and data completely independent of one another. That such independent creation may be true compels open collaboration between computer experts and the court or prosecutor, in order not to curtail access to computer evidence or allow abuse of process.

As the recent Cisco and Internet Security Systems complaint against ISS researcher Michael Lynn suggests, a company that is able to claim theft of trade secrets has a very wide range of civil and criminal legal mechanisms available based on the presumption that it was genuinely harmed by somebody else's actions. In many cases, however, the truth is that the software or source code was not improperly obtained, and wasn't a trade secret in the first place. Some companies take advantage of engineers' relative lack of understanding of these issues in order to bully them into doing or not doing something. To stop a bully requires at least one person to refuse to comply with the bully's demands, no matter what the consequences. A bully relies on his ability to inspire terror, and law enforcement know what to do with such people; if you are confronted with such a situation, all you need to do is explain these technical issues to law enforcement and ask them for help defending yourself against a bully and in most cases you will receive it. If you are truly a victim of an intrusion that resulted in theft of trade secrets, then you still must explain these technical issues in order not to be viewed as a bully. Hopefully these articles and references are helpful to you in communicating with law enforcement or your attorney in either case.

------------------------------------------------------------------------

Jason Coombs <
jasonc@science.org> works as a freelance computer forensic analyst and security incident response investigator. He also serves as a technical expert witness in civil and criminal court cases.

This article originally appeared in Dr. Dobb's Windows Security column on August 8, 2005. Read more at

http://newsletters.sdmediagroup.com/cgi-bin4/DM/y/eqoW0FbT7j0JSr0DbPi0Ev

***************************************************************