The Art of Reverse Engineering

Recently a client asked me for advice on setting up a reverse engineering project.  The company had just hired a senior engineer from a competitor that had pulled ahead of them the year before with the release of a next generation product. They needed to respond soon. The new employee was “clean,” they assured me, having come over without any documents or files. So they proposed to get him going with a small technical team and some samples of the competitor’s product. He no longer had access to any trade secrets of his former employer; what could possibly go wrong?

In the world of trade secrets, reverse engineering is universally embraced as acceptable. It involves starting with a publicly available product or set of information and taking it apart to discover how it was created. Why does anyone do this? To discover, legitimately, a path already taken:

  • to learn, as when a child takes apart a clock
  • to change or repair a product
  • to provide a related service
  • to create a compatible product
  • to create a competitive product

In most circumstances, there is nothing wrong with reverse engineering. The recently-enacted Defend Trade Secrets Act declares that it cannot be an “improper means” of acquiring information. (In fact, if you properly reverse engineer a product, the information you discover can be held by you as your own trade secret.) The reason behind the rule is apparent when you consider the limits of trade secret protection: selling a product that reveals the design and method of its manufacture means the secret is imperiled. If it is very easy to discern, then the secret is lost immediately. If it might take some time to figure out, then that’s called reverse engineering, and anyone is allowed to do it.

Like most rules, this one has its limitations. You can’t use the reverse-engineering process to “discover” and duplicate a patented invention. That is one of the advantages inherent in using patent protection instead of trade secrets. Also, if you haven’t simply purchased the product on the open market, but have acquired it by some form of limited license or other contract that restricts your rights to reverse engineer, the courts normally will enforce those restrictions. Finally, you can’t through reverse engineering simply duplicate a product that is protected by a trademark or otherwise market a product so identical that the public would be confused about its source. Indeed, that conduct deserves the derisive label “knocking off.”

But to appreciate the potential of reverse engineering, consider the case of Chicago Lock Co. v. Fanberg. For fifty years the Chicago Lock Company had marketed its special “Tubular Ace” lock, frequently seen on vending machines where maximum security is required. In order to achieve that level of security, the manufacturer would provide a duplicate key only to an owner registered with the company. The codes necessary to duplicate the keys were strictly controlled. Lost keys could only be replaced by the manufacturer or by a locksmith who could “pick” the lock to discover the appropriate configuration and grind a duplicate tubular key.

Locksmiths typically would record the relevant “key code” along with the serial number of the customer’s lock, to be able to duplicate the key if it was lost again. Fanberg, a locksmith himself, advertised for other locksmiths to provide him with correlations they had recorded over the years. He then compiled all of the correlation codes into a manual and offered it for sale. Chicago Lock Company, understandably upset that its security system was jeopardized, filed a lawsuit.

The court directed judgment for Fanberg. Whatever claims the owners of the locks might have had against their locksmiths for divulging the codes, the manufacturer had sacrificed its products to the possibility of exactly the kind of reverse engineering that occurred. The court explained:

“It is well recognized that a trade secret does not offer protection against discovery by fair and honest means such as by independent invention, accidental disclosure, or by so-called reverse engineering, that is, starting with the known product and working backward to divine the process, Thus, it is the employment of improper means to procure the trade secret, rather than mere copying or use, which is the basis of liability.”

If you intend to reverse-engineer a product, however, be careful how you do it. Acquire the product through a simple purchase. Make sure that there are no conditions attached to the purchase that might prohibit you from reverse engineering. In addition, beware of documentation that is provided as part of the sale that may itself contain confidentiality restrictions. This situation occurs frequently with sophisticated equipment accompanied by maintenance manuals or circuit diagrams with restrictive legends. It also comes up in the disassembly of software acquired under license agreements, where issues of copyright infringement may require special legal advice.

Carefully choose the team that will perform the reverse-engineering tasks. Use only those who have had no exposure to the way it was originally designed and made, and be sure that the team does not have access to any confidential material of the original manufacturer. Maintain detailed records of the entire process, so that it can be demonstrated – to the satisfaction of someone with a technical background – that the process was accomplished “from scratch” and without reference to any restricted information.

As for my client who hired the competitor’s engineer, they agreed they were asking for trouble by involving someone who had previously worked on this technology. Since he was already on board, and as extra insurance against a later claim, they abandoned their internal project and contracted with an outside vendor to perform the work in a “clean room” environment (a term borrowed from semiconductor processing, where particle contamination is strictly controlled), with nothing to refer to but the product itself. Reverse engineering may sound good, but as in so many other areas of trade secret law, the right answer isn’t found in a phrase, but in practical risk management.

Share

Warning & Disclaimer: The pages, articles and comments on IPWatchdog.com do not constitute legal advice, nor do they create any attorney-client relationship. The articles published express the personal opinion and views of the author as of the time of publication and should not be attributed to the author’s employer, clients or the sponsors of IPWatchdog.com.

Join the Discussion

23 comments so far.

  • [Avatar for angry dude]
    angry dude
    December 7, 2017 08:32 pm

    BING LIU@22

    “$1 million and half to one year”

    would it be cheaper and MUCH faster just to license the processor IP ?

    Unless its a very large and dedicated infringer and they really want that piece with no contracts attached

  • [Avatar for BING LIU]
    BING LIU
    December 7, 2017 08:20 pm

    @angry dude
    yes, it is expensive but acceptable under some circumstances. Reverse engineering the digital portion of a middle size processor costs about $1 million and half to one year.

  • [Avatar for angry dude]
    angry dude
    December 7, 2017 07:55 pm

    BING LIU @20

    Just because something CAN be done does not necessarily mean it WILL be done
    Proper reverse-engineering of a large obfuscated binary is a hugely time and money consuming proposition – literally years of man’s work (at at least 100$ an hour)
    I’m not even talking about encrypted binaries which get decrypted at run time
    – a common practice for some of the commercial softwares

    It’s much cheaper to buy a license or the whole company altogether

  • [Avatar for BING LIU]
    BING LIU
    December 7, 2017 07:41 pm

    @angry dude
    I said “disclose code” just meant when a microprocessor is on market, the code of a digital block can be considered disclosed because the coded/synthesized functions can be extracted through reverse engineering.

    In reality, because of the process of synthesizing software code to hardware gates, the extracted code would not be the same as the original source code. That is why I think it more likely applies to AFC.

  • [Avatar for angry dude]
    angry dude
    December 7, 2017 07:05 pm

    Paul F. Morgan@12

    there are no “lines” of binary code, dude

    it is trivial to write e.g. a Perl script that will identify identical extracts between 2 binaries – I can do it in an hour or so
    And you do not have to prove “access”, maybe just a possibility of it
    What’s the probability that a monkey randomly typing on a keyboard can eventually type “War and Peace” ???
    Zero, zilch, none
    The judge and jury will agree (but I do have my doubts about US judges lately..)

  • [Avatar for angry dude]
    angry dude
    December 7, 2017 06:54 pm

    @BING LIU

    why would a company disclose their own source code ???

    I keep my source code to myself and if I need to cooperate with other people I give them e.g. compiled DLLs
    good luck reverse-engineering (aka understanding how they actually work as opposed to using them as they are) those
    and if my binary is cracked and disassembled and parts of it are used in their original form (without rewriting code from scratch) then its criminal copyright violation
    much like it is criminal to sell copyrighted software on ebay or on a street corner
    byte per byte diff of a little extract and then straight to court
    not much else required to prove illegal copyright violation
    as opposed to proving patent infringement
    to hell with patents

  • [Avatar for BING LIU]
    BING LIU
    December 7, 2017 03:37 pm

    It would be interesting to know if the AFC is applicable when people copy the codes of digital blocks on semiconductor chips, e.g. microprocessors. The hardware digital circuits are designed basically with almost the same way as software programs. It is much more complex and thus relatively expensive to extract the codes from a digital block on a chip. Therefore, it is not very popular.

  • [Avatar for Anon]
    Anon
    December 7, 2017 02:52 pm

    Excellent conversation. Here is a link with an overview of the afc test: https://en.wikipedia.org/wiki/Abstraction-Filtration-Comparison_test

  • [Avatar for BING LIU]
    BING LIU
    December 7, 2017 10:22 am

    @Rahul Vijh, thank! good to know.

  • [Avatar for Rahul Vijh]
    Rahul Vijh
    December 7, 2017 01:58 am

    @BL: Simply rewriting the software code albeit with new function/variable names and insignificant modifications would probably fail the abstraction-filtration-comparison test (Computer Associates International, Inc. v. Altai, Inc.) and thus can still constitute copyright infringement, provided the code was disclosed.

  • [Avatar for BING LIU]
    BING LIU
    December 6, 2017 05:18 pm

    @Paul F. Morgan,
    Actually I am not sure. I am working on hardware analysis rather than software reverse engineering. There is a book telling the story of copyright and software reverse engineering. I also heard similar stories from somebody who is in this area too.

  • [Avatar for Paul F. Morgan]
    Paul F. Morgan
    December 6, 2017 04:39 pm

    Thanks BL.
    Just out of curiosity, you note that “the disclosed source codes can be easily rewritten to avoid copyright.” But even if that is the case, what if source code is [desirably] NOT disclosed? There is software for comparing all the lines of binary code to determine the amount that is identical. That plus proof of access can lead to alleged copyright infringement.

  • [Avatar for BING LIU]
    BING LIU
    December 6, 2017 03:14 pm

    @Paul F. Morgan, as I know, few companies are still copying codes and masks. The ways to do that are not expensive anymore: the disclosed source codes can be easily rewritten to avoid copyright. For mask work protection, the analog functional blocks can be replaced by different designs with same functions. The codes of digital blocks can be extracted and re-synthesized. The methods are relatively inexpensively.
    For semiconductor circuit, process/structure and electronic system, patenting is still the most useful tool to protect the inventions. We can find the EoUs of the patented inventions.

  • [Avatar for Paul F. Morgan]
    Paul F. Morgan
    December 6, 2017 12:50 pm

    Not to disagree with what AD and BL are saying here about the importance of trade secrets their chip or software technologies, but note that patent, copyright and/or Mask Work protection can often be obtained relatively inexpensively where appropriate without fully disclosing source code or other trade secrets, thus not requiring relying solely on trade secrecy.

  • [Avatar for Night Writer]
    Night Writer
    December 6, 2017 09:26 am

    @5 Richard Catalina, Jr.

    What we haven’t seen yet is the rise of the employment agreement that is going to leverage the trade secrets to restrict the areas of employment of the tech worker.

    The other thing we haven’t seen yet, but likely will, is more development that is specific to one of the monster monopolies, e.g., Google or FB. By building proprietary systems they will make it very hard for employees to switch companies.

  • [Avatar for Night Writer]
    Night Writer
    December 6, 2017 09:23 am

    @4 angry dude.

    The other thing about trade secrets is they restrict the movement and thus the wages of the tech employees.

  • [Avatar for BING LIU]
    BING LIU
    December 6, 2017 08:48 am

    Great article!

    Understanding the art of reverse engineering helps a company to decide its intellectual properties should be protected by industry secrets, patents, or/and copy right.

    have been working in this industry for 20 years, my 2 cents: reverse engineering is more complicated than before, thus it costs higher and needs longer time. A PLL circuit we analyzed on Qualcomm Snapdragon processor, which is made in 13 metals, 10 nm FinFET process, costs about $150k and 3 months. However, reverse engineering is still the most reliable way to prove the EoU (evidence of use) of the patented claims, especially in hardware and semiconductor industries.

    Copy right is good for software but it really works little. Industry secret is the best way to protect manufacturing process, most software, and something between hardware and software, like large digital circuits.

  • [Avatar for American Cowboy]
    American Cowboy
    December 5, 2017 11:39 am

    To the extent angry dude is correct (which I am not disputing), no wonder Silicon Valley wants to eviscerate patents — patents do them very little good, and can do them harm.

    But, Silicon Valley is not the entire USA and should not be allowed to dictate to the rest of us.

  • [Avatar for Richard Catalina, Jr.]
    Richard Catalina, Jr.
    December 5, 2017 10:09 am

    I have represented clients on both sides of this issue in the software context. Developers have skills and learn new skills as they develop for an employer company – including trade secret “special sauce.” When a developer leaves a company and goes to work for a competitor (putting aside any non-compete issues in the employment contract), the developer cannot “unlearn” newly acquired skills directed towards the prior employer’s trade secrets.

    When the developer uses newly acquired skills involving a prior employer’s trade secrets with a new employer, that’s not reverse engineering. That’s misappropriation of trade secrets. Yet, the new employer hired the developer precisely for those advanced skill sets. Within this context, there really is no such thing as a “clean” new employee developer. The question is what does the developer know – as to the prior employer’s trade secrets – and will it be used with the new employer. Whether the developer has papers or a thumb drive with code doesn’t fully answer the question.

  • [Avatar for angry dude]
    angry dude
    December 5, 2017 10:04 am

    trade secrets win over patents hands down in anything that requires more than a simple tear down to replicate a product
    anything software or silicon hardware – trade secrets rule
    just compiling source code into binary imposes major 6-7 figure expense on reverse-engineering
    encrypted binaries, secure boot processors, FPGAs, ASICs ? – forget about reverse engineering altogether – too expensive, cheaper to buy a company
    to hell with useless patents and promoting the progress
    trade secrets forever !!!

  • [Avatar for Paul Morgan]
    Paul Morgan
    December 5, 2017 09:34 am

    Yes, this is the kind of article needed on this blog to disabuse some commentators who seem to think that trade secrecy protection can be a widespread valid alternative to patenting, even though in many technologies that is not practical or even possible for commercial products.

  • [Avatar for Rahul Vijh]
    Rahul Vijh
    December 5, 2017 05:12 am

    Great article, James!

    Reverse engineering has been a key focus area for us – especially as the litigated technology and products in general have gotten more sophisticated (perhaps because software cases are on the decline).

    In my experience, we have faced two key challenges in conducting RE investigations:

    1. Cost: Most RE work in telecom and semiconductors is exorbitantly expensive (because it requires specialized equipment) – plus clients need to invest the large sums without enough certainty that the results will be as desired. At some point, RE would cease to be regarded as a feasible Rule 11 requirement for that reason.

    2. Reliability: Many kinds of RE aren’t conclusive. For example, I have had clients who’d like to de-compile a software binary to furnish human-readable code (software RE) – in order to show that certain code was copied or that a certain algorithm was followed. The problem in this approach is that the decompiled result is only a best guess at what the original code (or one variant) may have looked like in order to produce the binary – no guarantee what it actually looked like. Therefore the reliability of such RE is suspect.

  • [Avatar for Bruce F Webster]
    Bruce F Webster
    December 4, 2017 08:05 pm

    As for my client who hired the competitor’s engineer, they agreed they were asking for trouble by involving someone who had previously worked on this technology.

    Yep. I’ve testified as an expert in several trade secret matters; the ‘unavoidable disclosure’ to a former employee is a common issue. I’m surprised how many companies will hired key people right from a competitor (current or anticipated) and directly involve them in potentially infringing work.

    Frankly, I find trade secret case to be more complex and subtle than most patent cases precisely because of the issues of tracing the protected information’s lifespan and path from the plaintiff to the defendant.