Six cases and controversies. Six recurring problems. One question: What does the evidence actually prove?
When a digital forensic examination goes wrong, everyone wants to know what software was used. Fair question. But what about the examiner?
I respect forensic software developers. Without them, we wouldn't have half the capabilities we rely on today. Yet we're quick to take credit when an examination goes well and just as quick to blame the tool when it doesn't.
The bigger issue is attribution. A tool can establish that an event occurred, but that doesn't automatically establish who caused it, why it happened, or whether someone intentionally did something wrong.
Different tools. Different examiners. Same mistakes. And the same devils keep coming back.
1. The Devil of Accusation without Attribution
I received a series of emails from a forensic examiner accusing law enforcement of using WinFE to plant evidence and convict innocent people. The examiner claimed firsthand knowledge but provided no identifiable cases despite repeated requests.
Acquisition errors happen. But altered evidence doesn't automatically establish intentional manipulation, much less who was responsible.
WinFE is a tool, not an actor. If evidence was deliberately planted, establish what happened, who did it, and what supports that conclusion. Don’t blame the software.
That's attribution. An accusation isn't evidence of it.
2. The Devil of Confusing Capability with Conduct
The 2026 controversy involving Oxygen Forensics resulted in public accusations and a federal lawsuit, Oxygen Forensics, Inc. v. Weissberg, filed August 28, 2026.
I obtained court filings because I wanted to examine what was actually alleged instead of relying on what people were saying about the allegations.
One issue that caught my attention was the use of the word "hacking."
Some forensic tools exploit vulnerabilities, execute code, obtain elevated privileges, and bypass security restrictions to extract data. You can call some of that hacking. But calling a capability hacking doesn't establish criminal conduct.
The same technical method can be used during an authorized examination or an unauthorized intrusion. The difference isn't necessarily the software. It's the authority and the conduct of the person using it.
And allegations about a forensic company don't become facts simply because they're repeated online or appear in a lawsuit. A lawsuit establishes that allegations were made, not that they were proven.
If you're going to accuse someone of criminal conduct, connect the conduct to the person. The software's capabilities aren't proof of guilt.
3. The Devil of Mistaking Tool Operation for Expertise
In United States v. McLeod, the Ninth Circuit considered a challenge to testimony involving a Cellebrite extraction.
Detective Damian Jackson testified about extracting information from a phone. The defense challenged the reliability of the testimony and whether it should have been admitted without a proper expert-reliability determination.
The appellate court noted the testimony as admitted and affirmed the conviction, but a dissenting judge raised concerns about the detective's qualifications, knowledge of extraction methods, and the absence of a sufficient reliability determination.
The detective wasn't Cellebrite-certified, appeared uncertain about some extraction methods, and didn't know when the device had last been updated. Those concerns were part of the dissent, not findings adopted by the majority.
If your explanation begins and ends with "Cellebrite produced the report," that's not much of an explanation.
The software might accurately recover messages, timestamps, and other artifacts. But the examiner still needs to explain what those artifacts mean and what they establish about the alleged activity.
Cellebrite can extract the evidence. It can't supply the examiner's expertise or make an unsupported attribution defensible.
4. The Devil of Confusing Changes With Evidence Tampering
In State v. Ortega, a 2026 Arizona appellate decision, the defense challenged aspects of a GrayKey extraction.
The defense claimed that GrayKey had altered 1,522 files and sought additional testing. The trial court found that the established modification involved a date change consistent with the extraction process. The defense expert also acknowledged that the images underlying the charges had not been modified.
The appellate court upheld the relevant rulings denying the requested additional access and testing.
That doesn't mean GrayKey, or any other forensic tool, should be immune from independent examination. Quite the opposite, but there is a difference between detecting a change and establishing that the change compromised evidence.
What changed? Why did it change? Was the content affected? Did the change alter an important conclusion?
Those questions need answers before anyone assigns responsibility.
This also applies to arguments about proprietary software. Open-source software isn't automatically reliable, and commercial software isn't automatically reliable. Neither the license nor the vendor's reputation establishes that a particular result is correct.
If you're claiming that a forensic tool altered evidence improperly, establish what happened and whether it matters.
An observed change is evidence of a change. It isn't automatically evidence of tampering, misconduct, or a defective tool.
5. The Devil of Confusing a Computer With a Person
In Strike 3 Holdings, LLC v. John Doe, a federal copyright dispute, a defense expert used X-Ways Forensics to examine a computer associated with alleged illegal downloading.
The examiner searched the available data, including recoverable deleted files, and found no matching works among the files examined. The court considered the forensic findings strong circumstantial support for the defendant and granted summary judgment on the non-infringement counterclaim.
This case goes directly to something I've been arguing for years.
An IP address isn't a person. A computer isn't a person. An account isn't necessarily the person using it.
Finding evidence associated with a device or account doesn't automatically establish who performed the activity.
I've used X-Ways extensively and written two books about it without being paid by its developer. I've also contacted Stefan Fleischmann when I encountered problems. During one class, a question arose about the software. I contacted Stefan, and he provided a fix overnight.
That's how the relationship between examiner and developer should work. Identify the problem, communicate it, and resolve it.
But I cannot expect Stefan to write software that identifies the guilty person simply because I found something incriminating on a computer. X-Ways can recover and interpret file-system data. It can help establish when certain activity occurred and what artifacts exist.
Connecting that activity to a particular person is my investigative responsibility. Sometimes the evidence supports that connection. Sometimes it doesn't.
If I can't establish who performed the act, I can't blame X-Ways for failing to make that connection for me. That's not what I bought it to do.
6. The Devil of Mistaking Tool Output for Methodology
This last case should be required reading for anyone writing forensic reports or testifying about digital evidence.
In Alliance Laundry Systems LLC v. Adams, an August 2026 federal decision, a judge excluded the opinions of a digital forensic expert because the methodology supporting those opinions had not been adequately explained.
The examination involved several commercial forensic products, including FTK, Forensic Explorer, USB Detective, and Magnet AXIOM.
The court didn't find those tools defective. The problem was the expert's explanation of his work.
The original expert, Mark Lanterman, withdrew following an investigation into his credentials. Sean Lanterman, who had participated in the examination as a peer reviewer, was substituted.
The court found that Sean had not sufficiently explained the methods used to reach his opinions. His qualifications and identification of the software weren't enough to establish reliability under Federal Rule of Evidence 702.
You can spend years using forensic software, complete thousands of examinations, and collect certifications. But when you offer an opinion, you still need to explain how you reached it.
Naming four forensic tools isn't methodology. Neither is saying you followed standard forensic procedures. And this is where attribution becomes especially important.
A forensic report might establish that a USB device was connected, files were accessed, or data was copied. Those findings can be important evidence. But if the examiner concludes that a particular person intentionally stole information, the report needs to explain the connection between the artifacts and that conclusion.
That connection cannot simply be assumed because the software produced a result.
I support forensic software developers. But I don't expect them to appear in court and rescue me when I cannot explain my own conclusions.
The tool produces findings. The examiner must explain the reasoning. And the evidence must support the attribution.
The Developer Is Not Your Scapegoat
I've made mistakes using forensic software. I've misunderstood features, encountered defects, and found problems that turned out to be my own doing.
When software fails, developers should address it. When an examiner makes a mistake, the examiner should own it. Neither should be blamed without evidence.
We've become very good at recovering and processing digital evidence. I'm not convinced we've improved at the same rate when it comes to determining what that evidence proves. Our tools’ capability has outrun our abilities in data analysis.
A tool can identify files, accounts, devices, and activity. It cannot automatically identify the person responsible. And when something goes wrong, the software isn't automatically responsible either.
Attribution works both ways.
If you're going to accuse a person of an act, establish the connection. If you're going to blame a forensic tool for an error, establish that connection, too.
We're supposed to be investigators.
Act like it.
Cases and Source Material
- WinFE correspondence. Private emails I received. The allegations described here have not been independently established because the examiner refuses to give me case citations (and I can’t find any online).
- Oxygen Forensics, Inc. v. Weissberg, No. 1:26-cv-02826 (E.D. Va. 2026). Federal court docket. Weissberg messaged me and agreed to be interviewed about the claims, but he hasn't replied to me to set a date.
- United States v. McLeod, No. 16-50013 (9th Cir. Feb. 6, 2019). Amended appellate disposition.
- State v. Ortega, No. 2 CA-CR 2024-0044 (Ariz. Ct. App. 2026). Appellate decision.
- Strike 3 Holdings, LLC v. John Doe, No. 2:17-cv-01731 (W.D. Wash. 2020). Summary judgment order.
- Alliance Laundry Systems LLC v. Adams, No. 3:23-cv-22130 (N.D. Fla. Aug. 9, 2026). Expert testimony order.