January 05, 1998,
Issue: 987
Section: News
Brian Santo
Portland, Ore. - There was the guy who stole some software and stripped out all the block comments but left the code unchanged in every other respect. He got caught. Then there was the guy who did an "amazingly thorough" job of rewriting some stolen code-but neglected to delete the original copyright messages.
The occasional boneheaded criminal notwithstanding, detecting software theft, plagiarism and copying is a complicated, painstaking endeavor. But as product value increasingly is found in intellectual property, such crimes are occurring with greater frequency, giving rise to a new subdiscipline of engineering: forensic software analysis, the preservation and analysis of computer-based evidence.
"Computer evidence speaks very loudly; it screams," said Andy Johnson-Laird, a pioneer of the field. Based in Portland, Johnson-Laird has written extensively on computer-based crime and provided his services and testimony in scores of cases, including Symantec Corp. vs. McAfee Associates, the State of Oregon vs. Randal L. Schwartz and the trade-secrets dispute between Avant! and Cadence.
Different worlds
The work of this Sherlock Holmes of software sheds light on how little engineers sometimes know of the legal system, and how little the legal system understands technology.
Detecting software theft depends on catching a thief making a mistake or neglecting to cover his tracks. Often, forensic software analysis is a straightforward -though by no means simple-matter of comparing the original code with the code said to be a copy or illegal derivative. The aim is to find telltale similarities.
The types of clues Johnson-Laird looks for include errors and stylistic quirks-coding mistakes, similar spacings, typographical errors-the accumulation of which lead to the conclusion that one block of code is a copy of another.
The first hurdle is getting to the code. Many times, you can simply mount a chip in a test fixture to a tester and extract machine code. But sometimes the code is encrypted, or anti-piracy mechanisms are in place. When that's the case, Johnson-Laird has followed software clues all the way down to the wires, employing the same techniques used in reverse engineering.
"You start with fuming nitric acid and drop it on the underside of the chip. It burns through, exposing the silicon die," he said. The next step is to "take photomicrographs to find relevant sections of the chip. These are taken at magnifications of 1,000x to 1,200x, at which point you can see the layers of silicon or silicon dioxide. You can see the fusable link. You can use two probes to find connections or use the connective paint and short it out."
The next task is to determine how the bits are organized. "The bits of a byte are often distributed all over; there's nothing that says they have to be adjacent to each other," he said. "You must physically decode the zeros and ones. Then you can move up through layers of abstraction."
The tough part, said Johnson-Laird, "is answering the question: Why is the code doing that? One of my guys says that's the origin of the phrase, 'Will stare at code for food.' "
Johnson-Laird is convinced that several people have gotten away with software theft in at least a few of the cases he's worked on. "Sometimes you must tell a client that maybe he did get ripped off, but there's no proof," he said.
Far from being cloak-and-dagger, Johnson-Laird believes his job is something any competent technologist could do.
"There's certainly no black art to it," he said, "although there are some specialized tools. Until recently, you couldn't buy a program to duplicate a hard disk bit for bit, or back up a disk to tape." He finally found "a local company that has a product it sells to law-enforcement agencies." The trusty Norton Utilities is an equally valuable tool, he said.
Evidence is often but not always in code. Other clues can be found in documents and backup systems. The search is aided by the fact that people-even EEs-tend to take a computer at face value, as if what they see on screen is the whole story.
"Take Microsoft Word," he said. "Most engineers create a document and print it. What they usually don't realize is that there are historical remains from prior versions of that document. Word Perfect 6.1 has a default setting, where the last 10 editing operations are kept along with the document. The default can be set to up to 300 operations."
Likewise, "When you click-and-drag and delete, that selection is off the screen. But six months or six years later, you can open that file, do an 'undo,' and it pops right back."
The same is true of e-mail. "Most engineers think e-mail is transient," he said."There's some expectation of privacy. But it's not private. It's more like a postcard. I end up reading stuff no one thought would be read: shopping lists, love letters."
Sifting through those traces leads Johnson-Laird to call his job "techno-archaeology." "What you're looking to do is become a time traveler. You use the revision-control system of the source code, or prior versions of schematics or backup tapes that contain historical data."
If that part of the job demands hours squinting at a computer screen, the other side is more public: serving as an expert witness. "The expert's job is to explain to the court what technology is,"said Johnson-Laird. "That's where the going can get really tough. The other side is out to impugn you. It's confrontational. It's probing. . . it's very intimidating."
That's partly because of the fundamental differences between the legal and tech worlds. In the digital domain, everything is true or false. Engineers are trained to blow through barriers, to solve problems directly. Progress in developing a body of law, on the other hand, is more nuanced. "I think engineers are offended by that," said Johnson-Laird. "They want to know why you can't just go from A to B."
Consider the case of Randy Schwartz, a leading expert on Perl software. Several years ago, while working as a contractor for one Intel division, Schwartz hacked into the internal network of another Intel division-to demonstrate, he said, that Intel's security was inadequate. But Intel sued, and Schwartz was convicted on three felony counts.
"I know on a visceral level that he did what he did with the best of intentions," said Johnson-Laird. "There were no sinister motives at all. Randy's a techie, and techies do things on occasion that offend their employers, managers, whomever."
Equally problematic is that judges and lawyers may fail to grasp the fine points of technology. In Johnson-Laird's view, that's what happened in National Educational Support Systems Inc. (Nessi) vs. Autoskill International Inc. "No one in the court understood software," he said.
Autoskill, a Canadian company, had created a learning program-essentially computerized flash cards-in which a computer spoke a nonsense word and the child found the best match from three written words on screen, using the 1, 2 and 3 buttons on a keyboard to choose.
Johnson-Laird testified on behalf of Nessi, Autoskill's American distributor, which wrote its own version of the program from scratch but also used 1, 2 and 3 keys for purposes of selection. That one similarity, the judge decided, was evidence of plagiarism.
The outcome, Johnson-Laird said, was that Nessi "filed for Chapter VII bankruptcy. They were in the right, but the court found them wrong, for technically invalid reasons." He said the case continues to be "mis-cited to justify silly things like the 1, 2, 3 keys."
Even though forensic software analysis is growing as a discipline, Johnson-Laird said it's "not keeping up with the problems of the next five years or beyond." One of them is that "software is now so complex, you cannot predict its failure."
A software-development project that fails to meet contractual requirements or is terminated for cause before completion can result in a lawsuit. "A typical case [involved] a complex billing system for a health-maintenance organization in the Midwest," said Johnson-Laird. "The software deliverer was in the Bay Area. It was sued for failing to deliver on time and of insufficient quality."
Slow and painful
Software failure is rarely a matter of a single catastrophic error. "It's more like death by a thousand cuts," he said.
At the outset, there is no way to assess how long a project will take because you don't yet know what the problems are. "Worse, you cannot know. But saying that you really don't understand the problem yet-that doesn't fly in corporate America.
When asked whether there is anything the industry can do to minimize the risks of computer-based crime, Johnson-Laird offered little solace: "The technology is such that if someone wants to steal your crown jewels, they can do so in a shirt pocket. You can fit the entire intellectual property of any company on media that will fit in a pocket. The things you can do to stop that are unconstitutional and probably cruel and unusual."
Still, he said, "Companies can be vigilant. They can educate their employees about who owns what and under what circumstances. It's a balancing act-how to balance the creativity of the individual with the company's rights to the individual's work product. If you have an overprotective company, you have a police state. If you have too open
an environment, the company's IP hemorrhages."
For more on forensic software analysis, visit Johnson-Laird's Web site at www.jli.com.
Copyright (c) 1998 CMP Media Inc.
CryptoSoft GmbH
Feedback: webmaster@cryptosoft.com
Copyright ©1995-1998 Cryptosoft GmbH
All Rights Reserved