The Hardware Ledger · Flipper Zero series · 18 September 2026
Previous: U2F · Series contents
Status: Source review, not a THL hardware investigation. The examples below identify who reported the result and what kind of evidence it provides.
“It can do this” and “someone used it to do this” are different statements. A complete account also needs the target, software, conditions, observed effect, and reason the result matters. These cases connect the mechanisms in the earlier chapters with actual research and reported events.
Case 1: checking whether a protective product protects
Beneficial use · Original investigator’s report · 16 May 2023
SANS Internet Storm Center handler Jesse La Grew tested shielding bags using several devices. Flipper was used for LF credential and NFC reads; separate phones and computers handled the Bluetooth, Wi-Fi, and cellular checks. In the reported setup, LF card and fob reads still worked through the bags, while the tested NFC read was blocked. The outcome differed by interface. Original SANS test report
How: Compare a known readable item with the same item inside the protective enclosure, keeping the reading conditions controlled. Why it helps: A protection claim becomes an observable question instead of a label on packaging. The report describes very close Flipper placement and does not certify every product or frequency.
For a classroom adaptation, use an existing inactive training tag and an existing enclosure; do not use a payment card. Keep the original successful read as a control and record placement and closure. If there is no suitable equipment, analyze the published observations on paper. This is a suggested adaptation, not an additional SANS or THL result.
The general lesson is methodological: one failed read is weaker evidence than repeated controlled comparisons, and neither substitutes for calibrated shielding measurements. See Part 03 and Part 04 for what a read establishes.
Case 2: public disruption on a train
Harmful use reported by an eyewitness · Published 2 November 2023
In an original interview with Ars Technica, security researcher Jeroen van der Ham described repeated prompts and reboots during train journeys in the Netherlands in October 2023. The article attributed the activity to a nearby passenger using Flipper and reported van der Ham’s subsequent controlled reproduction. Treat this as a reported eyewitness incident, not a court finding or a public forensic identification of the operator. Original interview
How the related mechanism works: Devices process certain discovery advertisements before pairing. Unwanted messages can provoke repeated prompts; defective handling of crafted traffic can cause denial of service. Researcher Christopher Reynolds describes the Flipper-related investigation of this behavior. Why misuse harms people: Availability is the target: the owner loses normal use of the phone even without evidence of stolen files. Researcher’s account
Neither an eyewitness account nor a later successful reproduction proves every detail of the earlier incident. They support different conclusions: one describes what a person experienced, while the other demonstrates a technical possibility under selected conditions. Part 08 provides the version-specific technical evidence and a nondisruptive exercise.
Case 3: the same research contributes to a fix
Beneficial security research · Vendor acknowledgement
Apple’s iOS/iPadOS 17.2 advisory, for the release of 11 December 2023, records CVE-2023-42941 and credits Christopher Reynolds. It describes denial of service through crafted Bluetooth packets and a correction using improved checks; the entry was added on 10 January 2024. Apple advisory
How research helps: A reproducible failure gives a vendor a condition to investigate and regression-test. Why it matters: The relevant boundary is how untrusted input is handled, so fixing that handling is more general than recognizing the casing of one transmitting product. This is the series’ interpretation of the research and advisory, not a claim about Apple’s internal development process.
A vulnerability’s existence, responsible investigation, public exploitation, and repair are separate events. Do not call research malicious merely because it demonstrates an attack, or call broadcasting at unsuspecting people research merely because it uses a research tool. A historical fix also does not certify every present-day Bluetooth implementation.
Case 4: the car-theft controversy
Policy statement and disputed attribution · 2024
Canada’s 8 February 2024 national auto-theft summit announcement named Flipper in proposed action against signal-copying devices. The announcement establishes the policy position at that time. It supplies no reproducible Flipper theft case with a specified vehicle and successful engine authorization. Government announcement
How to assess the claim: Identify whether the alleged method is static replay, rolling-code abuse, live relay, or another attack. Then identify the outcome: reception of a signal, opening a door, or permission to drive. Why it matters: Those outcomes involve different checks. Part 06 examines them, including a documented relay demonstration that used different equipment.
The sources reviewed for this series do not establish a verified Flipper vehicle-theft incident. That is a statement about this evidence set, not proof that such misuse is impossible. This chapter makes no claim about current Canadian law.
Case 5: a real attack class is not automatically a Flipper case
Documented malicious USB activity · Device attribution kept separate
Part 07 discusses a 26 March 2020 advisory about malicious USB keystroke injection against businesses. Its source concerns the BadUSB attack class; it is not evidence that the attackers used Flipper Zero. That distinction keeps a useful historical example from becoming a false product-specific allegation. Advisory hosted by Texas DIR
How: An accepted input device supplies keystrokes in the user’s session. Why: Software often needs to accept legitimate keyboards, and malicious input can exploit that permission. The chapter’s lab types one harmless sentence into an editor the reader opens manually. It demonstrates the input path, not malware installation or defeat of every endpoint control.
Produce your own defensible case note
Choose one case and complete the worksheet. Write four short paragraphs:
- Claim: Identify the reported event and the exact effect alleged.
- Mechanism: Explain the input, the receiver’s trust decision, and the necessary conditions.
- Evidence: Identify original documentation, measured research, testimony, and missing information separately.
- Response: Propose a control that addresses that mechanism, plus a safe way to check it.
An effective conclusion is narrow enough to defend. “The tested reader accepted the training identifier” is useful. “Every door is vulnerable” is not supported by that observation. Flipper’s lasting value as a learning tool is the opportunity to make that distinction visible.