By Michael Barr
Note: This article offers practical guidance for attorneys and technologists working with reverse engineering in litigation. It is general commentary, not legal advice. The legality of any particular reverse engineering effort turns on the facts, the jurisdiction, and the governing agreements. Consult counsel about any specific matter.
The most important facts in a software or electronics dispute are usually locked inside a product nobody will hand over. The accused device ships as a sealed board and a stripped binary. The protocol is undocumented. The chip at the center of the case is a black box the size of a fingernail. I have spent a good part of my career opening boxes like these, sometimes in rooms where the protective order was so strict that the computers had never touched the internet and nothing left the room but our own notes about what we had learned.
Reverse engineering is how a technical expert turns a shipping product into evidence about how that product actually works. Done well, that evidence stands up. Done poorly, or in the wrong legal posture, it becomes a liability: a methodology that collapses at the Daubert stage, or worse, an act that exposes your client to a counterclaim.
The short version: reverse engineering a lawfully purchased product is broadly legitimate under U.S. trade-secret law, is permitted under copyright law for purposes like interoperability, and gets legally complicated the moment an access control or a license clause is involved. It becomes admissible evidence the same way a source code review does: documented methodology, intact chain of custody, reproducible results.
What reverse engineering means in litigation
Reverse engineering is the disciplined process of examining a finished product to determine how it was designed and how it functions, without the original design documents. In litigation it takes one of a few forms, and choosing among them is itself an expert judgment, because each answers a different evidentiary question at a very different cost.
Clean-room analysis
A two-team method used most often in copyright and trade-secret matters. One team examines the target and writes a specification describing only what the product does, stripped of any protected expression. A second, isolated team implements or evaluates against that specification without ever seeing the original. The wall between the teams is the point: it produces a documented record that the result was derived from function, not from copying.
Decompilation and disassembly
Translating a compiled binary back toward human-readable form to recover its logic. This is how an expert examines behavior when no source code was produced, or verifies that the produced source actually matches the shipping binary. That second use is underrated. Source code produced in discovery is not always the code in the product, and the binary does not lie.
Protocol analysis
Observing the messages a device sends and receives, over a network, a bus, or a radio link, to reconstruct an undocumented protocol or data format. Common in interoperability and infringement disputes where the accused behavior is a communication rather than a static file.
Firmware and netlist extraction
Pulling embedded code out of a microcontroller or flash device, or recovering the gate-level netlist that describes a chip's logic, so the actual implementation can be compared to a patent claim or an accused design.
Silicon die analysis
At the deepest level, decapsulating a chip and imaging its layers to reconstruct the circuit as fabricated. In my experience this is the technique clients ask about first and need last. It is expensive, specialized, and sometimes genuinely the only way to prove what is inside an integrated circuit, but a week of protocol analysis has answered many questions that a die shot was about to be commissioned for.
When it is permitted, and when it crosses a line
Reverse engineering is lawful and long-accepted in many contexts. It is not lawful in all of them. Three bodies of law tend to govern, and they do not always point the same direction.
Trade-secret law generally treats reverse engineering as legitimate. Under the widely adopted Uniform Trade Secrets Act framework and the federal Defend Trade Secrets Act, acquiring information by reverse engineering a lawfully obtained product is an accepted means of acquisition, not misappropriation. Start from a properly purchased product and work backward, and you are, as a general matter, on solid ground. The critical qualifiers are lawfully obtained and by proper means. If the starting material was taken, or the analyst had access through a confidential relationship, the trade-secret shield can turn into a trade-secret claim. This is why chain of custody for the analyzed unit matters as much as chain of custody for the resulting evidence.
Copyright law permits reverse engineering for some purposes, notably interoperability. A well-developed line of cases recognizes that intermediate copying during reverse engineering can be fair use when the goal is to understand unprotected functional elements, such as the interface needed to build a compatible product. The clean-room method exists precisely to keep that line clean.
The DMCA adds a separate layer when technical protection measures are involved. Section 1201 prohibits circumventing measures that control access to a copyrighted work. Its statutory exceptions, including good-faith reverse engineering for interoperability and legitimate security research, are real but narrow, and their conditions are specific. If your expert has to defeat encryption to reach the evidence, counsel belongs in the conversation before the first keystroke, not after.
Contracts can restrict what the law would otherwise allow. Many licenses carry anti-reverse-engineering clauses, and whether such a clause is enforceable varies by jurisdiction and facts. The practical point is blunt: how the unit was obtained, and under what terms, can determine whether the resulting analysis is usable or radioactive. Resolve that up front. Discovering it at deposition is how careful technical work gets thrown away.
How reverse engineering becomes admissible evidence
Lawful reverse engineering still has to clear the reliability bar. Under Federal Rule of Evidence 702 and the Daubert line of cases, expert opinion must rest on a reliable methodology reliably applied. Reverse engineering earns admissibility the same way a source code review does: through discipline documented while the work happens, not reconstructed afterward.
What that discipline looks like in practice:
- A written plan before touching the target. What will be examined, with what tools, to answer what question. The record should let the expert describe the method under oath as a method, not as improvisation.
- Chain of custody, treated seriously. The analyzed unit is evidence. Where it came from, who handled it, how it was stored. A gap here does more than weaken the result; as noted above, it can convert legitimate analysis into alleged improper acquisition.
- Reproducibility. Another qualified engineer, given the same inputs, tools, and steps, should reach the same result. That means preserving tool versions, exact inputs, and intermediate artifacts. Opinions that cannot be reproduced tend not to survive a serious challenge, and in my view should not.
- Honest limits. The opposing side will probe error rates, alternative explanations, and whether the method was invented for the litigation. An expert who used established techniques and can explain what the result does not show is the one still standing after that cross.
The tools differ from a code review. The standard does not, a theme we develop at length in our guide to vetting a source code review team.
A checklist before you authorize reverse engineering
Work through these with counsel and the expert together, before the analysis begins:
-
How was the unit acquired, and under what terms? Confirm lawful acquisition and identify any license that traveled with it. Anti-reverse-engineering and confidentiality questions get resolved now, not after.
-
Which legal regime governs the goal? Interoperability, security research, trade-secret defense, and infringement proof sit under different rules. Name the purpose, because it drives what is permitted.
-
Are technical protection measures in the way? If reaching the evidence means circumventing encryption or an access control, DMCA Section 1201 is in play before the work starts.
-
What is the least invasive technique that answers the question? Protocol analysis or decompilation may prove the point without the cost and risk of die analysis.
-
Is the methodology documented and the chain of custody intact, from the first step?
-
Can the result be reproduced, and is someone preserving the tools, versions, and artifacts that make that possible?
-
Is the expert qualified in this specific technology? Firmware, protocols, and silicon are different disciplines. A reviewer fluent in one can be lost in another.
Why the specific expert matters
Reverse engineering exposes the same mismatch we see across technology litigation: the person doing the work has to actually know the technology. A firmware expert reading a netlist as if it executed line by line will mischaracterize a chip built from concurrent logic. A web developer disassembling a real-time control system will miss what matters. None of these is a job for a generalist who "knows computers."
The qualified expert also knows where the legal lines run and builds the analysis to stay inside them: least invasive technique first, method documented as it proceeds, record kept clean enough to survive both a Daubert challenge and a chain-of-custody attack. That combination of domain depth and litigation discipline is what turns reverse engineering from an interesting technical exercise into evidence a court will credit.
What we do at Barr Group
Our electronics and software expert witnesses come from engineering, and we match the expert to the technology the case actually involves: firmware extraction, protocol analysis, decompilation, or hardware-level examination. We plan the reverse engineering approach with counsel so the legal posture and the technical method are designed together, we document methodology and chain of custody as the work proceeds, and we hold every result to a standard that reproduces and withstands cross-examination. That discipline runs through our work in patent infringement, software copyright, and trade secrets litigation, and it carries into the expert reports and testimony built on top of it.
One example of that at scale: DirecTV retained a Barr Group team to reverse engineer and test more than one hundred suspected signal-piracy devices, and our experts testified in several dozen of the cases that reached trial. See the satellite TV piracy case study, or our reverse engineering expert witness services.
Open the box properly
Reverse engineering is one of the most powerful tools in a software or electronics case and one of the easiest to misuse. The law permits far more of it than most people assume, and forgives far fewer shortcuts. Plan the legal posture and the technical method together, pick the least invasive technique that answers the question, and put the work in the hands of an expert who genuinely knows the technology. The black box will open. What matters is whether a court trusts what you found inside.
Barr Group's team of electronics and software expert witnesses provide experienced and unbiased source code reviews, expert reports and testimony for product liability, patent infringement, software copyright, and trade secrets litigation involving computer-based technology and software. HIRE AN EXPERT
Get a matched recommendation >
Free, confidential, conflicts-checked, and our fee is built into the expert's hourly rate, so we are paid only if you retain.