A reverse engineering tool can now identify a cryptographic routine inside a stripped binary in seconds. Getting that answer is no longer the hard part of the work. The hard part is standing behind it in a deposition when opposing counsel asks how the conclusion was reached, what the error rate is, and whether the analyst can reproduce it.
That question has become more pointed. Federal Rule of Evidence 702 was amended in December 2023 to require the party offering expert testimony to demonstrate admissibility by a preponderance of the evidence, and Rule 702(d) now emphasises that an opinion must stay within the bounds of what follows from a reliable application of the expert’s methodology. The Advisory Committee made the change in response to concerns about unreliable forensic testimony.
That is the frame for AI in reverse engineering. A technique that produces a fast answer nobody can explain is not an advantage in patent litigation, but is a liability. The value of AI here is that it clears the mechanical work so expert time goes where the analysis has to be defended, and the sections below work through what that looks like in practice.
Key Takeaways
- Reverse engineering and source code review are different disciplines. Reverse engineering starts where source code is unavailable and works backwards from binaries and firmware; source code review starts with code produced in discovery.
- What reverse engineering produces is reconstructed pseudocode and behavioural evidence, not source code. Describing it as source code in an expert report invites a credibility challenge.
- The 2023 amendment to FRE 702 raised the bar on methodology, which makes explainability a threshold requirement for AI-assisted findings rather than a nice-to-have.
- AI changes where expert hours go. It does not reduce the need for a qualified engineer who can reproduce a result and testify to how it was obtained.
- The two disciplines intersect usefully in one place: comparing produced source against the shipped binary to confirm a production is complete and matches what the defendant actually ships.
Table of Contents
Check out our Reverse Engineering Services
Reverse Engineering Is Not Source Code Review
Reverse engineering analyses compiled software, firmware, or executables to determine how a system works when the source code is unavailable. If the source were available, there would be nothing to reverse engineer.
The two get discussed interchangeably often enough to be worth separating, because the difference decides what the evidence is worth.
| Reverse Engineering | Source Code Review | |
|---|---|---|
| Starting point | Purchased product, binary, or firmware | Source code produced in discovery |
| Access route | Self-help on a lawfully acquired product | Court-ordered production |
| Can it be barred? | Sometimes, where a licence prohibits it | No, production is compelled |
| What it produces | Reconstructed pseudocode and behaviour | The authoritative artifact, with comments and history |
| Evidentiary status | An inference requiring validation | Direct evidence of implementation |
Decompiler output resembles C or C++ but is rebuilt from the compiled binary, carrying none of the comments, original variable names, or revision history that source code carries. An expert who reports having reviewed source code when they analysed decompiler output has handed opposing counsel an opening.
Where a licence can prohibit reverse engineering outright, as in Bowers v. Baystate Technologies, the limits are set out in Reverse Engineering Patent Law. The technique set itself, covering disassembly, decompilation, static and dynamic analysis, and protocol monitoring, is in our patent reverse engineering guide
What AI Adds, and What It Does Not
AI systems trained on large datasets of binaries and firmware recognise code patterns, propose function purposes, detect similarity between implementations, recover stripped symbols, and generate pseudocode summaries. On a large firmware image this turns weeks of triage into hours.
Each of those outputs is a hypothesis awaiting confirmation. When a model labels a routine as AES encryption, it has told the engineer where to look first, and the engineer still has to trace the routine to establish what it does. Skipping that step is what turns an accelerated investigation into an unsupportable one.
Explainability is the practical constraint. Deep learning systems are black boxes by default, and a conclusion that cannot be traced is one an expert cannot defend under cross-examination. Where explainability is missing, the finding has to be re-established through conventional analysis anyway, which removes the time the tool saved. For the comparison methods behind similarity results, see Source Code Comparison Methods for Trade Secret and Patent Disputes.
The Workflow
Target acquisition, recorded so lawful acquisition is documented. Binary or firmware extraction. Static analysis through disassembly. AI-assisted function identification to triage. Decompilation into pseudocode. Similarity detection against known implementations. Behavioural analysis of execution paths.
Confirmed functionality is then correlated with patent claim elements to support claim chart preparation, and findings are documented as function summaries, architecture diagrams, and technical reports. Only validated findings enter the claim mapping stage, because a claim chart built on unverified output carries that weakness into the litigation record.
Expert Validation Is the Deliverable
Every stage above produces candidates. Validation turns them into evidence. An engineer confirms AI-generated function identifications against actual behaviour, verifies similarity results by examining the implementations, and checks that claim mappings hold against the claim language rather than a paraphrase.
This is also the work that survives cross-examination. Under the amended Rule 702, reliability has to be demonstrated rather than assumed, which is why Lumenci’s expert witness practice is built around engineers who defend their own analysis rather than present someone else’s.
Where the Two Disciplines Meet
When source code is produced in discovery, compiling it and comparing the result against the shipped binary tests whether the production is complete. It can reveal functionality present in the retail product but absent from the production, or third-party components not disclosed. Lumenci’s HDMI-CEC ITC matter ran this way, combining source code review, firmware analysis, and device testing across streaming devices, televisions, and third-party chipset components.
Why Lumenci
Lumenci’s reverse engineering practice is staffed by engineers with domain experience in semiconductors, embedded systems, wireless protocols, and multimedia software.
- Engineers who testify: our experts defend their own methodology in deposition rather than presenting analysis performed by someone else.
- Reproducible method: every finding traces to an observable behaviour or identified structure, with the analytical path recorded.
- Full stack coverage: binary, firmware, protocol, and silicon-level analysis handled in-house.
For binary and firmware analysis where source code is unavailable, talk to Lumenci. At portfolio scale, iLumOS applies the same principle: automation for speed, analyst verification for defensibility. Request a demo for iLumos here.
Conclusion
AI has changed the economics of binary and firmware analysis. Work that took weeks of manual instruction tracing can now be triaged in hours.
What it has not changed is what makes a finding usable. A claim chart is only as strong as the evidence under it, and that evidence is only as strong as the engineer who can explain how it was obtained. The 2023 amendment to Rule 702 tightened that standard, and no amount of automation moves the accountability off the person signing the report
Can You Prove Infringement in a Consumer Device?
Lumenci combined source code review with device testing to prove HDMI-CEC infringement.
Frequently Asked Questions
Is reverse engineering the same as source code review?
No. Reverse engineering reconstructs behavior from binaries or firmware where source is unavailable. Source code review examines code produced in discovery under a protective order.
Does reverse engineering produce source code?
It produces decompiled pseudocode, which resembles source code but lacks comments, original variable names, and revision history. It should be described accurately in expert reports.
Can AI-generated findings be used in litigation?
Only after expert validation. Under the amended FRE 702, testimony must reflect a reliable application of the expert’s methodology, so an engineer has to reproduce and explain the result independently of the tool.
Why does explainability matter for AI in reverse engineering?
An untraceable conclusion cannot be defended under cross-examination. If it cannot be explained, it has to be re-established through conventional analysis, removing the efficiency the tool was adopted for.
Is reverse engineering legal?
Analysing a lawfully purchased product is generally permitted, though licence agreements can restrict it and rules vary by jurisdiction. Reproducing patented technology found through that analysis is a separate question.
