Assess

Independent LrrK research · Edition 2026-11-01.3

Hardware Attack Library (HAL)

Hardware-first evidence for drones, robotics and embedded devices: what researchers actually showed, on which device, with what access, and what stayed unresolved. Records are organised by the hardware threat classes in MITRE EMB3D™, with ATT&CK® cross-references only where a source supports them. LrrK endorses this framework as an independent effort of the security research community and is not affiliated with or endorsed by The MITRE Corporation.

89 reviewed evidence records · 5 pending leads · 20 closed lead reviews (15 resolved to records, 3 reviewed as context only, 2 reviewed and excluded) · reviewed through 1 November 2026. Context-only reviews are background, not demonstrated attacks. Several records share a paper or experiment, so these are not 89 independent attacks. Coverage means representation in this documented corpus — not every device, attack or source on the internet.

EMB3D Framework

Counts are records in this documented corpus, including discussions and reported results; they are not independent experiments, exhaustive coverage or confirmed device applicability. Choose a threat to filter the evidence.

Reviewed evidence records

Showing 10 of 89 reviewed records for EMB3D TID-115 Firmware/Data Extraction via Hardware Interface. Default order: hardware, then device interface, then context; within each, drones and robotics first, then fault-injection learning.

Full archived edition (JSON) ↓
HardwareDrones & roboticsDemonstrationDR-019Holy Stone HS175D: unprotected SWD permits internal MCU flash and SRAM reads66/100
Bounded outcome
Researchers report successful readout of MCU internal flash and SRAM through SWD. They do not report malicious code installation, modified motor outputs or a runtime safety bypass.
Stated claim
Holy Stone HS175D: unprotected SWD permits internal MCU flash and SRAM reads
Evidence status
Original preprint hardware debug readout (original-preprint-hardware-debug-readout)
Device, firmware & configuration

Vendor: Holy Stone Models: HS175D Configuration: MindMotion MM32F103 MCU; paper reports accessible SWD and no active readout protection on its tested unit.

Access required

Class: physical-debug-interface Requirements: Physical access to the MCU debug interface and a compatible hardware debug probe.

Scope / hardware boundary
Actual privileged hardware debug readout, beyond mere boot-console discovery.
Dates
Published: 11 May 2026 · Reviewed: 1 November 2026
Mechanisms
Firmware/Data Extraction via Hardware Interface

Sources

Shared source; these records are not independent experiments. Shared with DR-018, DR-020.

Limitations

  • Firmware revision, board revision, exact readout size/hash and an independently accessible debug-session transcript are not supplied in the inspected account.
  • Do not transfer the HS175D SWD result to HS720 or HS360S; those debug interfaces were not tested.
  • A memory-read result is not code execution or physical actuation.

Follow-up

Evidence confidence · 66/100

Confidence components for DR-019
ComponentScoreReason
Provenance18/20Unavailable — no separate reason was recorded.
Technical evidence24/35Unavailable — no separate reason was recorded.
Configuration specificity16/20Unavailable — no separate reason was recorded.
Independent corroboration0/15Unavailable — no separate reason was recorded.
Follow-up resolution8/10Unavailable — no separate reason was recorded.

Overall rationale Direct preprint statement and model-specific table; detailed session artifacts and exact firmware pin are missing.

Framework mappings

Original record: https://arxiv.org/html/2605.11040v1 (opens original source in a new tab) · Share: link to this record

HardwarePrimary hardware researchDemonstrationLRRK-20261101-FI-001STM32L051K8 test-firmware readout through voltage-induced flash-erase suppression78/100
Bounded outcome
SYSS-2025-033 reports recovery of the sample firmware. The detailed blog separately says its conventional bootloader voltage-glitch attempts did not work on the tested STM32L051 setup. Failed erase-suppression attempts can destroy the data sought.
Stated claim
The author reports reducing readout protection while suppressing the associated flash erase, then reading the retained test firmware.
Evidence status
Original author demonstration and advisory (original-author-demonstration-and-advisory)
Device, firmware & configuration

Tested part: STM32L051K8, as explicitly named in SYSS-2025-033 Family: STM32L0 / Cortex-M0+ Test firmware: Simple LED-toggle test program with readout protection enabled Blog product link: The blog links an STM32L051C6 product page; this does not override the advisory's tested K8 part. Artifact version: Linked working repositories have changes in 2026, so current source is not assumed identical to the 2025 experiment.

Access required

Physical laboratory access to the MCU, power supply and SWD/debug interface; tested on prepared laboratory hardware.

Scope / hardware boundary
Voltage perturbation during a protection-downgrade/erase operation on a laboratory MCU. No clock-glitch, deployed flight-controller, robot or customer-secret extraction result is established.
Dates
Published: 23 May 2025 · Event: 4 April 2025 · Reviewed: 1 November 2026 — Advisory reports discovery 2025-04-04, vendor notification 2025-04-07 and public disclosure 2025-05-23. Detailed blog is dated 2025-06-06. These are source-reported dates, not LRRK experiments.
Mechanisms
voltage fault injection; flash-erase suppression

Sources

Limitations

  • Same-team blog, advisory and repositories are not independent experiments.
  • Success rates in the source are configuration-specific and are not vulnerability probabilities.
  • No result on a drone, robot or LRRK device is inferred.
  • The earlier paper reports method-specific failures and device variation; those are preserved rather than generalized away.

Follow-up

Performed

  • Read the original advisory and detailed blog, not only the Penthertz summary.
  • Checked original linked artifacts and the earlier 2024 paper's exact device table and method-specific results.
  • Searched for an independent STM32L051 erase-suppression reproduction.

Results

  • Resolved the exact tested part to STM32L051K8 and separated the generic/C6 product link.
  • The CWE title mentions voltage and clock glitches, but the actual demonstrated mechanism here is voltage injection.
  • Earlier paper used different STM32L1/L4 and other-vendor targets. Its successful EMFI results must not be described as universal voltage-glitch success.

Contradictions

  • Blog's generic product link and advisory's explicit K8 test identity differ in specificity; use the advisory part for the tested claim.

Open questions

  • No exact die revision or independently validated raw readout artifact.
  • No independently verified same-configuration reproduction or current vendor remedy matrix found.

Evidence confidence · 78/100

Confidence components for LRRK-20261101-FI-001
ComponentScoreReason
Provenance20/20Original research advisory, detailed author article and linked artifacts were inspected.
Technical evidence30/35Sources state a sample-firmware readout and retain unsuccessful attempts/data-loss outcomes; no physical execution or raw binary validation by LRRK.
Configuration specificity19/20Exact advisory part and test-program context are known; die/board revisions and complete build pin remain absent.
Independent corroboration0/15All exact-result artifacts are same-author; the earlier paper uses different parts and is not exact-configuration reproduction.
Follow-up resolution9/10Part-identity/date/mechanism ambiguities were narrowed; independent reproduction and current remediation remain open.

Overall rationale 78/100 concerns the narrowly reported laboratory result, not device applicability, severity or a probability.

Framework mappings

Original record: https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2025-033.txt (opens original source in a new tab) · Share: link to this record

HardwarePrimary hardware researchDemonstrationLRRK-20261101-FI-004NVIDIA Tegra X2 on Jetson TX2: author-reported voltage-fault activation of a hidden bootloader74/100
Bounded outcome
Authors report full boot-ROM code and key-material extraction and decryption of the next boot stage on their tested platform. They attribute reproduction/confirmation to NVIDIA, but an independent vendor record was not located in this pass. No key bytes, proprietary boot-ROM artifacts or exploit implementation are retained.
Stated claim
The original research reports re-enabling a fuse-disabled manufacturer bootloader using voltage fault injection, gaining high-privilege code execution and extracting bootloader material.
Evidence status
Original research manuscript controlled demonstration (original-research-manuscript-controlled-demonstration)
Device, firmware & configuration

Soc: NVIDIA Tegra X2 / T186, Parker Platform: Jetson TX2 module with Jetson TX2 developer-kit carrier board Target processor: Boot and Power Management Processor / boot-ROM trust boundary Scope: Development-module laboratory experiment; no production vehicle, deployed robot or flight controller tested.

Access required

Physical access to the Jetson module/carrier and laboratory voltage-fault equipment. Claimed recurring implant use is an impact scenario, not an operational deployment established here.

Scope / hardware boundary
Physical voltage fault against the tested Tegra X2 boot processor. It does not establish results on the original Switch Tegra X1, later Tegra generations or an integrated autonomous system.
Dates
Published: 16 August 2021 · Reviewed: 1 November 2026 — Reviewed arXiv v2 is dated 2021-08-16. The separate Switch event is dated 2018-06-28 and is not the same experiment. Exact experimental dates were not established.
Mechanisms
voltage fault injection; hidden bootloader activation

Sources

  • The Forgotten Threat of Voltage Glitching:A Case Study on Nvidia Tegra X2 SoCs (opens original source in a new tab) · Original author research manuscript · Partially read 1 November 2026
    • Full HTML manuscript was returned; review focused on platform, threat model, result, applicability/disclosure and prior-generation sections.
    • This is an author manuscript version. Vendor confirmation is attributed by the authors, not independently re-observed.
    • Paper refers to leaked/proprietary boot-ROM repositories; those were not retrieved or copied.

    Supports: Sections on threat model, exact platform, results/applicability and conclusion support the bounded Tegra X2 laboratory claim; prior-generation section contextualizes the Switch lead.

  • Glitching the Switch - media.ccc.de (opens original source in a new tab) · Original conference event metadata · Partially read 1 November 2026
    • The 92-minute recording was not watched/transcribed. No technical outcome is scored from metadata alone.

    Supports: Confirms the separate 2018 Switch event, author and recording identity; event text is not a reviewed technical transcript.

Shared citation with different roles: this CCC event is primary source for the T210 development-board record and historical context in the Tegra X2 study. The shared link is not independent corroboration or evidence that either study reproduced the other. Shared with LRRK-20261101-FR-001.

Limitations

  • This is a related new original-source case discovered while following the Switch lead; it does not close the original recording-review gap.
  • Manufacturer-reproduction statements in the paper are not independently verified corroboration.
  • Same-author historical citations are not independent reproductions of the 2018 Switch result.
  • No physical actuation, hardware implant installation or device test was performed.

Follow-up

Performed

  • Searched for original Switch slides/transcripts and author artifacts.
  • Checked the publicly linked subtitle route; it returns a dataset-not-present response and was not bypassed or retried.
  • Read the related original Tegra X2 paper coauthored by the Switch speaker.
  • Searched official NVIDIA domains for an independent matching confirmation.

Results

  • The accessible later paper documents its own Jetson TX2 setup and keeps earlier Switch history separate.
  • The original Switch recording remains unreviewed; no subtitle dataset was available through the linked service.
  • No matching independent vendor confirmation was verified; generic search hits were excluded.

Open questions

  • Original 2018 Switch recording/slides/transcript and exact silicon/boot stage still require review.
  • An accessible independent vendor record and exact tested build/revision for Tegra X2.
  • No evidence of the tested method in a deployed drone or robot.

Evidence confidence · 74/100

Confidence components for LRRK-20261101-FI-004
ComponentScoreReason
Provenance20/20Original technical manuscript with named authors and a separate original event record were inspected.
Technical evidence31/35Manuscript reports concrete privileged execution and readout/decryption outcomes with technical platform analysis; no raw artifacts were independently reproduced.
Configuration specificity15/20T186/Jetson TX2 module and carrier are specific; exact board, fuse and firmware build pins remain incomplete.
Independent corroboration0/15Vendor reproduction is only attributed in the author's report; no independent confirmation was retrieved, so no corroboration points are awarded.
Follow-up resolution8/10Separated the 2018 and 2021 experiments and excluded generic vendor hits; original recording and vendor/build gaps remain.

Overall rationale 74/100 applies to the tested Jetson TX2 account. It is not evidence of a flight-controller or robotics compromise.

Framework mappings

Original record: https://arxiv.org/html/2108.06131v2 (opens original source in a new tab) · Share: link to this record

HardwarePrimary hardware researchDemonstrationLRRK-20261101-FI-003STM32-TraceRip: conditional firmware recovery from debug-visible processor state, without electrical fault injection69/100
Bounded outcome
Slides report recovery of the complete application partition in their target, while also stating that early boot-region bytes are missed by the current collection startup delay. Repository describes target-program-specific analysis and incomplete/ambiguous ranges when capture data is insufficient.
Stated claim
Authors report reconstructing protected application bytes by analyzing debug-visible execution states of the target's integrity calculation.
Evidence status
Original author presentation and analysis artifact (original-author-presentation-and-analysis-artifact)
Device, firmware & configuration

Primary family: STM32G0, exact part/revision not established from the reviewed text Context: Refrigerator-controller research, not a drone or robot test Flash capacity: 128 kB described in the presentation Firmware prerequisite: Running application/boot code performs a startup integrity calculation whose inputs/derivatives become visible in CPU state Debug prerequisite: Relevant core-register/SRAM observations remain available under the tested protection behavior Cross family claim: Slides state tests on F0/F1/G0/C0 but do not provide a complete model/revision/configuration matrix. Collection tool availability: Public repository covers analysis; collection repository is still marked TBA in the inspected README.

Access required

Physical access to the hardware debug connection and repeated processor-state captures on a target with the required debug and firmware behavior.

Scope / hardware boundary
Debug-interface information leakage and target-specific program analysis. Clock jitter is an observation problem/future-work topic, not a demonstrated clock-injection attack.
Dates
Published: 2025 · Reviewed: 1 November 2026 — Original authors identify Hardwear.io USA 2025 as the presentation. PDF v1.1 contains a 6/10/2025 footer whose date formatting was not resolved. The inspected analysis repository has a public-release commit dated 2026-03-27. Upload-path dates are not experiment dates.
Mechanisms
hardware debug processor-state observation; target-specific integrity-calculation data recovery

Sources

Limitations

  • Do not describe normal clock drift, controlled timing or the suggested future clock control as clock fault injection.
  • No physical capture, binary validation, firmware execution, robot motion or drone flight was performed.
  • Multiple author links, slides and code are one research lineage, not independent experiments.
  • Penthertz's proposed mechanism for a commercial STM32 dongle remains speculative and is not admitted as a scored attack case.

Follow-up

Performed

  • Read all six Penthertz posts and followed the core TraceRip claim to its original repository.
  • Recorded the obsolete PDF link's 404, then resolved a current PDF through original-author links.
  • Reviewed primary result/limitation slides and the analysis repository.
  • Searched for an independent reproduction tied to the published analysis implementation.

Results

  • Narrowed '100% flash' to the reported application-partition recovery; early boot bytes remain a stated limitation.
  • The authors qualify unsuccessful prior methods as methods they could not get working on their STM32G0 setup, not proof of universal resistance.
  • Current analysis release is not a complete public acquisition toolchain.
  • This is not evidence that the published COM-004 unsuccessful voltage attempt actually succeeded.

Contradictions

  • Penthertz's unqualified complete-flash/family language is broader than the target-dependent result and collection limitations in the original sources.

Open questions

  • Exact primary MCU part, firmware/revision and reproducible capture pin.
  • Complete collection artifact availability and independently validated recovered image.
  • Exact applicability to each listed family and to any deployed drone/robot remains unestablished.

Evidence confidence · 69/100

Confidence components for LRRK-20261101-FI-003
ComponentScoreReason
Provenance20/20Original authors' conference slides, repository and project index were inspected.
Technical evidence27/35Primary sources describe a concrete recovery result and retain missed-region/insufficient-data limitations; no recovered binary or capture was independently validated.
Configuration specificity12/20Family, capacity, CRC/program prerequisite and debug boundary are described, but exact part/revision and target program pin are absent.
Independent corroboration0/15Forum posts and author artifact releases do not independently reproduce the experiment; no such reproduction was verified.
Follow-up resolution10/10Broken-link, complete-flash, method-classification and incomplete-toolchain ambiguities were resolved into explicit limits.

Overall rationale 69/100 supports the specific author-reported conditional recovery, not universal STM32 firmware extraction or an electrical-glitch claim.

Framework mappings

Original record: https://github.com/Marcus-Engineering/tracerip-analysis (opens original source in a new tab) · Share: link to this record

HardwarePrimary hardware researchDemonstrationprimary-prado-jtag-2020JTAG firmware extraction from a Linksys WRT54G67/100
Bounded outcome
The original researcher demonstrates reading a firmware image and inspecting its structure.
Stated claim
JTAG firmware extraction from a Linksys WRT54G
Evidence status
Author demonstration (author_demonstration)
Device, firmware & configuration

Description: Linksys WRT54G research target Configuration: MIPS/EJTAG-accessible target with demonstrated firmware readout; exact hardware/firmware revision is not established here.

Access required

Physical board/debug-interface access.

Scope / hardware boundary
MIPS/EJTAG-accessible target with demonstrated firmware readout; exact hardware/firmware revision is not established here.
Dates
Published: 20 February 2020 · Reviewed: 1 November 2026 — Publication date precision: day.
Mechanisms
Firmware/Data Extraction via Hardware Interface

Sources

Limitations

  • A worked tutorial on a selected router, not a report that every production JTAG interface is unprotected.
  • No independent dump or file-integrity comparison was performed by LrrK.
  • Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Performed

  • Read the original public evidence and compared its scope to the official threat reference.

Result

  • Source review supports the bounded account; no LrrK physical reproduction was performed.

Unresolved / next

  • Confirm exact target hardware, firmware, access and mitigation state before any separate authorized assessment.

Evidence confidence · 67/100

Confidence components for primary-prado-jtag-2020
ComponentScoreReason
Provenance20/20Original source and provenance inspected.
Technical evidence26/35Technical evidence read; methods and outcome limits retained.
Configuration specificity14/20Device and configuration details are bounded; missing revisions remain unknown.
Independent corroboration3/15Independent corroboration is limited; taxonomy citation and same-team artifacts are not independent reproduction.
Follow-up resolution4/10Follow-up source checks performed; unresolved items remain explicit.

Framework mappings

Original record: https://sergioprado.blog/2020-02-20-extracting-firmware-from-devices-using-jtag/ (opens original source in a new tab) · Share: link to this record

HardwareCommunity discussionDemonstrationLRRK-COM-011STM32F401CC dummy-firmware readout: Anvil Secure laboratory demonstration78/100
Bounded outcome
A first-party lab demonstration reports firmware recovery after substantial setup work. The article also records configuration corruption, unintended protection changes and temporarily unusable targets.
Stated claim
The author reports bypassing configured readout protection and extracting the complete dummy firmware from the tested STM32F401CC.
Evidence status
Author demonstration (author_demonstration)
Device, firmware & configuration

Target: STM32F401CC developer board Test firmware: Dummy firmware installed for the experiment Tool: CW1173 ChipWhisperer-Lite Scope: Author explicitly limits observations to the tested STM32F401CC product; this is not an operational drone/robot compromise.

Access required

Physical laboratory access to the development board, power circuitry and bootloader communications; invasive preparation described in the original is not reproduced in the library.

Scope / hardware boundary
Author explicitly limits observations to the tested STM32F401CC product; this is not an operational drone/robot compromise.
Dates
Published: 18 April 2025 · Reviewed: 1 November 2026 — Article published 2025-04-18 and modified 2025-04-19; experiment date is not stated.
Mechanisms
voltage fault injection; protected firmware readout

Sources

Shared source; these records are not independent experiments. Shared with LRRK-COM-004.

Shared source; these records are not independent experiments. Shared with LRRK-COM-004.

Limitations

  • No independent reproduction of the exact board, firmware and die revision was verified.
  • Linked figures and code were reviewed as reported artifacts; no device was acted on or tested.
  • The article's potential secrets consequence is not evidence that real customer secrets were extracted.

Follow-up

Actions performed

  • Detected that Firecrawl main-content extraction returned only the heading and publication metadata.
  • Retrieved the same public URL with main-content filtering disabled to recover the actual article.
  • Read the actual target/result sections and followed the linked repository.
  • Compared the article with the STM32G0 forum attempt.

Results

  • Confirmed exact STM32F401CC target and dummy-firmware laboratory scope.
  • Confirmed accessible author-linked artifacts.
  • No successful STM32G0 transfer was shown in the forum.

Contradictions

  • A successful STM32F401CC experiment does not establish the same outcome for STM32G0 or every STM32 part.

Follow-up limitations

  • No independent reproduction of the exact board, firmware and die revision was verified.
  • Linked figures and code were reviewed as reported artifacts; no device was acted on or tested.
  • The article's potential secrets consequence is not evidence that real customer secrets were extracted.

Evidence confidence · 78/100

Confidence components for LRRK-COM-011
ComponentScoreReason
Provenance20/20Unavailable — no separate reason was recorded.
Technical evidence29/35Unavailable — no separate reason was recorded.
Configuration specificity20/20Unavailable — no separate reason was recorded.
Independent corroboration0/15Unavailable — no separate reason was recorded.
Follow-up resolution9/10Unavailable — no separate reason was recorded.

Overall rationale Strong first-party technical lab report with an exact part, test-firmware context and accessible source artifact; exact-configuration independent reproduction remains unverified.

Framework mappings

Original record: https://www.anvilsecure.com/blog/glitching-stm32-read-out-protection-with-voltage-fault-injection.html (opens original source in a new tab) · Share: link to this record

HardwareCommunity discussionDemonstrationLRRK-COM-001STM32F1 protected-flash readout: original author demonstration74/100
Bounded outcome
Authors report a protected-firmware readout demonstration and a replacement ST-LINK controller operating with the recovered firmware. They separately report that their STM32F303 test did not yield the expected content.
Stated claim
The article reports reading protected flash from specific STM32F1 parts using voltage faults during the bootloader protection decision.
Evidence status
Author demonstration (author_demonstration)
Device, firmware & configuration

Primary: STM32F103RBT6 development board Additional author test: ST-LINK-V2.1 using STM32F103CBT6 Negative transfer test: STM32F303RCT7 returned data inconsistent with the expected firmware Scope: Modified laboratory hardware, not a drone or a robot assessment.

Access required

Direct physical access to a laboratory board and its power/programming connections; invasive preparation is described by the author but not reproduced here.

Scope / hardware boundary
Modified laboratory hardware, not a drone or a robot assessment.
Dates
Published: 16 January 2020 · Reviewed: 1 November 2026 — Article displays 16 January 2020; experiments occurred before publication, exact event dates not provided.
Mechanisms
voltage fault injection; protected firmware readout

Sources

Shared source; these records are not independent experiments. Shared with LRRK-COM-002.

Limitations

  • Linked video and images were discovered in the article; no physical reproduction was performed.
  • No independent reproduction of the exact parts/configuration was verified.
  • Do not reuse the article's broad family or protection-level statements without vendor-specific checking.

Follow-up

Actions performed

  • Read the source linked by the NewAE success claim instead of relying on the forum summary.
  • Checked the article's results and explicit unsuccessful experiment on another STM32 family.

Results

  • Article supplies concrete part numbers, bootloader analysis and an author-reported replacement-controller validation.

Contradictions

  • The article's success does not transfer to its tested STM32F303 configuration.

Follow-up limitations

  • Linked video and images were discovered in the article; no physical reproduction was performed.
  • No independent reproduction of the exact parts/configuration was verified.
  • Do not reuse the article's broad family or protection-level statements without vendor-specific checking.

Evidence confidence · 74/100

Confidence components for LRRK-COM-001
ComponentScoreReason
Provenance18/20Unavailable — no separate reason was recorded.
Technical evidence28/35Unavailable — no separate reason was recorded.
Configuration specificity20/20Unavailable — no separate reason was recorded.
Independent corroboration0/15Unavailable — no separate reason was recorded.
Follow-up resolution8/10Unavailable — no separate reason was recorded.

Overall rationale Strong first-party technical report with exact parts and a reported functional check, but no independently verified reproduction; forum cross-post is the same claim.

Framework mappings

Original record: https://habr.com/ru/companies/ntc-vulkan/articles/483732/ (opens original source in a new tab) · Share: link to this record

HardwareCommunity discussionReported resultLRRK-20261101-COM-001STM32F401CCU6 RDP1: FEV Secure Lab reports validated full-flash readout73/100
Bounded outcome
The article reports eventual full-flash acquisition and comparison with the original sample. Earlier positive acknowledgements yielded all-zero data, attributed by the authors to an unintended PCROP setting. RDP2 was not tested.
Stated claim
The original FEV Secure Lab authors report circumventing RDP1 on their STM32F401CCU6 board and reading full internal flash, compared with the sample firmware captured before enabling protection.
Evidence status
Author demonstration with validation limits (author_demonstration_with_validation_limits)
Device, firmware & configuration

Description: STM32F401CCU6 minimum-system development board, Cortex-M4, 256 KB internal flash. Configuration: Sample firmware was captured before enabling RDP1. The laboratory used custom physical voltage faulting and a hardware-connected ROM bootloader. Silicon stepping and a retained raw acquisition artifact were not established.

Access required

Physical possession, board modification, power and bootloader communication access in a controlled laboratory.

Scope / hardware boundary
Physical power-fault injection at an MCU protection decision followed by firmware readout over a hardware-connected bootloader.
Dates
Published: Not stated · Reviewed: 1 November 2026 — Article date is not exposed in the capture. The EEVblog link is dated 2025-08-05; that is a reference date, not an inferred publication date.
Mechanisms
Voltage fault injection against readout protection; Firmware readout via hardware-connected bootloader

Sources

Limitations

  • Only author-reported validation was inspected; no independent raw-byte comparison.
  • The protection-bypass fault model and PCROP explanation remain the authors' interpretations.
  • AI-assisted desk review; no LrrK physical reproduction or independent human verification of the experiment is claimed.
  • No drone, robot, flight controller, PLC or operational deployment is demonstrated by this record.

Follow-up

Performed

  • Read the entire original FEV article linked from EEVblog.
  • Separated RDP1 from the thread's RDP2 topic and preserved unsuccessful reads.
  • Compared authors, artifacts and claimed experiment against all 67 cases.

Result

  • A distinct original-lab RDP1 account is supported; same-family research is not independent replication of this experiment.

Unresolved / next

  • Require retained original/recovered data, exact silicon revision and protection-state evidence for stronger validation.
  • Do not apply this result to RDP2 or a drone/robot without new device-specific evidence.

Evidence confidence · 73/100

Confidence components for LRRK-20261101-COM-001
ComponentScoreReason
Provenance20/20Named original researchers and lab-attributed article inspected.
Technical evidence28/35Baseline comparison and failed outcomes reported, without independently checked raw images.
Configuration specificity18/20MCU model, flash size and RDP1 explicit; silicon stepping/reproducibility incomplete.
Independent corroboration0/15No independent reproduction of this exact FEV experiment inspected.
Follow-up resolution7/10Protection-level ambiguity resolved and raw-artifact limits retained.

Overall rationale Analyst evidence strength for the bounded claim, not severity, probability, untested-device applicability or an official MITRE rating.

Framework mappings

Original record: https://jerinsunny.github.io/stm32_vglitch/ (opens original source in a new tab) · Share: link to this record

HardwareCommunity discussionDemonstrationLRRK-COM-003PicoGlitcher STM32F4 result and a separately documented STM32F401 example66/100
Bounded outcome
The log itself establishes an author-reported positive protocol response, not a verified complete firmware dump. The separate F401 documentation claims a memory dump and documents unintended erasure and invalid-data outcomes.
Stated claim
An original project log reports a positive bootloader response under readout protection; current author documentation separately shows a STM32F401 readout example and supplied implementation.
Evidence status
Author demonstration limited result (author_demonstration_limited_result)
Device, firmware & configuration

Log test: STM32F4 microcontroller, exact part unspecified, RDP level 1 reported Separate documentation example: STM32F401 Black Pill board Tool: PicoGlitcher Scope: The generic F4 log must not be silently equated to the later F401 documentation example.

Access required

Physical laboratory access to target board and fault-injection hardware.

Scope / hardware boundary
The generic F4 log must not be silently equated to the later F401 documentation example.
Dates
Published: 5 August 2024 · Event: 8 July 2024 · Reviewed: 1 November 2026 — The log title says July 8; its displayed posting timestamp is August 5. Event date follows the title and is author-asserted, not independently verified. Current documentation has no verified publication date.
Mechanisms
voltage fault injection; protected firmware readout

Sources

Limitations

  • No independent reproduction was verified.
  • Linked figures were not validated as raw captures or as complete binary artifacts.
  • Versionless documentation can change; exact target firmware and die revision remain unknown.

Follow-up

Actions performed

  • Read the dated log instead of treating the whole project page as one experiment.
  • Followed the author documentation to the actual linked STM32F401 artifact.
  • Checked for independent follow-up and explicit failure cases.

Results

  • Author documentation distinguishes successful protocol response from returned memory data and records possible erasure/invalid data.
  • A guessed repository directory was absent; the actual source link was resolved from the documentation.

Contradictions

  • The log's generic F4 identity and the documentation's F401 identity are not evidence of one identical test.

Follow-up limitations

  • No independent reproduction was verified.
  • Linked figures were not validated as raw captures or as complete binary artifacts.
  • Versionless documentation can change; exact target firmware and die revision remain unknown.

Evidence confidence · 66/100

Confidence components for LRRK-COM-003
ComponentScoreReason
Provenance18/20Unavailable — no separate reason was recorded.
Technical evidence25/35Unavailable — no separate reason was recorded.
Configuration specificity14/20Unavailable — no separate reason was recorded.
Independent corroboration0/15Unavailable — no separate reason was recorded.
Follow-up resolution9/10Unavailable — no separate reason was recorded.

Overall rationale First-party log, detailed project documentation and retrieved artifact support a scoped laboratory claim; generic and exact-part experiments remain separate.

Framework mappings

Original record: https://hackaday.io/project/196357/log/231745-july-8-2024-later-this-day-glitches (opens original source in a new tab) · Share: link to this record

HardwareCommunity discussionReported resultLRRK-COM-002STM32F2/F4 readout reports with unintended flash erasure52/100
Bounded outcome
Reported partial readouts are accompanied by destructive side effects, unstable behavior and configuration-dependent results. No exact-part repeatability or complete verified firmware image was independently established.
Stated claim
A participant reports reading protected flash in blocks from STM32F2/F4 targets while also triggering unintended erasure. A different participant later reports obtaining needed firmware material through a combined hardware/software investigation.
Evidence status
Community author reported result (community_author_reported_result)
Device, firmware & configuration

Reported families: STM32F2; STM32F4 Scope: Community laboratory reports; no drone/robot model identified.

Access required

Physical access to target boards and laboratory fault-injection equipment.

Scope / hardware boundary
Community laboratory reports; no drone/robot model identified.
Dates
Published: 4 November 2021 · Reviewed: 1 November 2026 — Thread began 2020-02-07; selected first-person F2/F4 result is post 20 dated 2021-11-04. Later replies were checked through 2024-08-03.
Mechanisms
voltage fault injection; protected firmware readout

Sources

  • forum.newae.com (opens original source in a new tab) · Public forum original discussion · Partially read 1 November 2026
    • First 20 of 24 public topic-stream posts; four remaining IDs retrieved separately.

    Supports: Posts 7, 13, 19 and 20 describe partial readout, instability and erasure.

  • forum.newae.com (opens original source in a new tab) · Public forum later replies · Partially read 1 November 2026
    • All four previously omitted post IDs retrieved, including late updates.

    Supports: Post 22 reports obtaining firmware material; posts 23–25 retain unresolved repeatability and artifact questions.

Shared source; these records are not independent experiments. Shared with LRRK-COM-001.

Limitations

  • Pseudonymous first-person reports; exact parts, target firmware and recovered artifacts are not independently verified.
  • A second poster's related result is not a controlled reproduction of the first configuration.
  • No claim that this method applies to all STM32F2/F4 devices.

Follow-up

Actions performed

  • Used the forum's public JSON endpoint because the HTML scrape omitted post bodies.
  • Retrieved all four remaining post IDs and checked the end of the discussion.

Results

  • Reviewed 24 visible posts represented in the topic stream, including late follow-ups.
  • Success reports do not remove the reported erasure/data-integrity risks.

Contradictions

  • A positive protocol response or returned bytes alone does not establish a valid complete dump.

Follow-up limitations

  • Pseudonymous first-person reports; exact parts, target firmware and recovered artifacts are not independently verified.
  • A second poster's related result is not a controlled reproduction of the first configuration.
  • No claim that this method applies to all STM32F2/F4 devices.

Evidence confidence · 52/100

Confidence components for LRRK-COM-002
ComponentScoreReason
Provenance14/20Unavailable — no separate reason was recorded.
Technical evidence19/35Unavailable — no separate reason was recorded.
Configuration specificity10/20Unavailable — no separate reason was recorded.
Independent corroboration0/15Unavailable — no separate reason was recorded.
Follow-up resolution9/10Unavailable — no separate reason was recorded.

Overall rationale Detailed historical first-person results and failure modes, but no exact configuration or artifact validation; all independent-reproduction points are withheld.

Framework mappings

Original record: https://forum.newae.com/t/breaking-crp-level-1-stm32f103/1799/20 (opens original source in a new tab) · Share: link to this record

Lead registry

Leads are sources not yet admitted as reviewed records. They carry no confidence score — null, not zero risk. 5 are pending or unresolved; 20 lead reviews are closed and listed separately.

Closed lead reviews

Pending or unresolved leads (5)
  • primary-lead-iommu-2010 Exploiting an I/OMMU vulnerability (opens original source in a new tab)

    Source review gap retained · Confidence: not scored

    Companion original-source evidence materially narrows the mechanism, but neither the SSTIC paper nor the existing 2018 Dell paper silently resolves the unread IEEE 5665798 original.

    Next check: Compare a normally accessible original IEEE manuscript with the SSTIC account if one becomes available. Retain publication/experiment lineage and avoid counting both venues as independent proof without distinct outcomes.

  • DR-L06 2011 Predator/Reaper support-computer malware: conflicting public accounts (opens original source in a new tab)

    Source review gap retained · Confidence: not scored

    Read additional contemporary Dark Reading coverage quoting the Air Force account: malware was described as a nuisance on a standalone mission-support network, with aircraft control reportedly unaffected. Repeated quotations are one statement chain, not independent forensic evidence. The original AF Space Command press record remains unlocated.

    Next check: Locate a normal public original AF Space Command record or authenticated official archival copy before resolving the competing accounts; retain as context, not a hardware-attack demonstration.

  • LRRK-COM-LEAD-001 STM32F103 voltage-glitch Reddit discussion (opens original source in a new tab)

    Source review gap retained · Confidence: not scored

    Three new targeted public origin-discovery queries, in addition to the three retained follow-up01 queries, did not establish a public original-author artifact attributable to the supplied Reddit post. The known unsupported Reddit URL was not resubmitted and no mirror was used. Search snippets and unrelated STM32-family studies remain discovery only.

    Next check: A normally accessible original-author artifact with a defensible identity connection to this post is required before claim review. Do not retry or mirror the restricted source.

  • LRRK-COM-LEAD-002 EEVblog STM32F4 level-2 protection discussion (opens original source in a new tab)

    Source review gap retained · Confidence: not scored

    New captures of the first three forum pages were reviewed with the reused last-page capture. Earlier success assertions do not establish F4 RDP2: one contributor explicitly says F4 was untested and cannot identify the F3 model involved. The later RDP2 assertion still lacks an exact tested F4 part/revision, protection-state evidence and a retained validated result. Searches returned only the known assertion and the already published FEV RDP1 article.

    Next check: Require an original F4/RDP2 configuration and validated result, or a normally accessible original correction. Reconcile the uncertain ST operation before any decision to retry it; no bypass or unrequested paid repeat.

  • LRRK-LEAD-HOBOT-2026 HOBOT S7 Pro: author-reported OTA data writes need an installation-boundary follow-up (opens original source in a new tab)

    Source reviewed installation boundary gap · Confidence: not scored

    The original paper reports unauthenticated OTA data writes using non-destructive payloads. A data-transfer characteristic accepting writes does not by itself prove firmware-image installation, activation or bypass of a later signature check. Official TID-211 requires an installation/authentication boundary, so no admitted TID-211 case is proposed.

    Next check: Review a normally accessible original artifact or follow-up documenting the on-device verification/installation state, or a vendor security response; do not operate a robot or attempt firmware writes.

How to read evidence confidence

LRRK analyst evidence confidence, 0–100. Evidence strength for the narrowly stated claim, not probability, severity, present-device applicability, safety or an official MITRE score. It is an analyst rubric, not a MITRE rating.

  • Provenance · up to 20
  • Technical evidence · up to 35
  • Configuration specificity · up to 20
  • Independent corroboration · up to 15
  • Follow-up resolution · up to 10

Null means the source strand provided no separate component reason. Overall rationale is retained; no reasons are invented.

Multiple citations, reposts, same-team artifacts or shared reports are not independent reproduction.

Method, attribution and licenses

Edition
2026-11-01.3 · schema 1 · reviewed through 1 November 2026
Review
AI-assisted public-source desk research. No LRRK physical reproduction, device actuation or independent human acceptance is asserted.
Read status
Reviewed means the research strand inspected the returned source material. Partial-page reads, targeted passages, omitted forum replies and blocked content remain explicit.
Classification
evidenceStatus preserves each strand's original label. evidenceGroup is a coarse compiler grouping and never upgrades the stated outcome.
Mechanisms
Community mechanism labels are preserved. When a strand supplied no separate list, mapped EMB3D threat names are used; an empty list is not proof of no mechanism.
Mapping attribution
officialCaseAttribution=false means no verified direct MITRE attribution of this exact case is asserted. Ambiguous official-evidence inventory labels are displayed as analyst inference and their original wording is retained in mapping provenance. Only source-reviewed direct references or explicitly labeled analyst inferences. No forced EMB3D-to-ATT&CK/ICS crosswalk or MITRE endorsement.
Coverage and gaps
A documented seed corpus with open gaps, not an exhaustive census of the internet. Normal interfaces, search excerpts, HTTP success and code availability do not themselves prove attacks.
Shared sources
Records describe distinct claims or contexts. Shared papers, reports, forum topics and related artifacts do not establish independent experiments. 16 shared-source groups are flagged on their records.
What this does not establish
This snapshot does not establish exploitation on any current LRRK device. Operational reports, advisories, demonstrations, unverified reports and discussions remain distinct.
Updates
Research is reviewed weekly (Mondays, 9 AM Pacific) into private drafts. Only meaningful changes are prepared, and nothing is published automatically; this page changes only when a new reviewed edition is released. It is not a live feed.
Pinned versions
MITRE EMB3D™ site 2.0.2, model 2.0.1, commit 0d7c25bb4e2928c516fb5811aaab9ff8bab2896c (repository (opens original source in a new tab)). MITRE ATT&CK® v20.0 (13 October 2026), verified through 1 November 2026 (ATT&CK (opens original source in a new tab)).
Independence
An independent LrrK implementation. Not produced, reviewed or endorsed by The MITRE Corporation. Original sources retain their own rights; this library links to them and summarises bounded findings.
MITRE EMB3D license and disclaimers

©2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. Terms of Use LICENSE The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use, copy, and create derivative works of EMB3D™ for internal business purposes or commercial use. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy and provide MITRE notice of such use at EMB3D@mitre.org. “©2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.” For all other uses of EMB3D™, contact MITRE at techtransfer@mitre.org. All rights not expressly granted are hereby reserved. Portions of EMB3D™ were produced for the U.S. Government under various contracts or funded by internal research and development funds and the U.S. Government retains certain rights in EMB3D™. You agree that you shall not include a charge for EMB3D™ in any sales or license of derivative products or services to the U.S. Government. Your use of MITRE’s website and EMB3D™ will comply with all relevant laws, regulations, Executive Orders, and other obligations. DISCLAIMERS MITRE does not claim EMB3D™ enumerates all possibilities for the types of actions and behaviors documented as part of EMB3D™’s adversary model and framework of techniques. Using the information contained within EMB3D™ to address or cover full categories of techniques will not guarantee full defensive coverage as there may be undisclosed techniques or variations on existing techniques not documented by EMB3D™. EMB3D™ AND ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN “AS IS” BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE MITRE CORPORATION, ITS BOARD OF TRUSTEES, OFFICERS, AGENTS, AND EMPLOYEES, DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF ACCURACY, NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.

https://emb3d.mitre.org/subtabs/terms-of-use.html (opens original source in a new tab)
MITRE ATT&CK license

MITRE ATT&CK® Terms of Use Source: https://attack.mitre.org/resources/legal-and-branding/terms-of-use/ Retrieved: 2026-11-01 The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use ATT&CK® for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. "© 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation." #### [DISCLAIMERS](https://attack.mitre.org/resources/legal-and-branding/terms-of-use/\#disclaimers) MITRE does not claim ATT&CK enumerates all possibilities for the types of actions and behaviors documented as part of its adversary model and framework of techniques. Using the information contained within ATT&CK to address or cover full categories of techniques will not guarantee full defensive coverage as there may be undisclosed techniques or variations on existing techniques not documented by ATT&CK. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE MITRE CORPORATION, ITS BOARD OF TRUSTEES, OFFICERS, AGENTS, AND EMPLOYEES, DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. See our [FAQ](https://attack.mitre.org/resources/faq) for more information on how to use and represent the ATT&CK name.

https://attack.mitre.org/resources/legal-and-branding/terms-of-use/ (opens original source in a new tab)