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 9 of 89 reviewed records for EMB3D TID-110 Hardware Fault Injection – Data Manipulation. Default order: hardware, then device interface, then context; within each, drones and robotics first, then fault-injection learning.

Full archived edition (JSON) ↓
HardwarePrimary hardware researchDemonstrationprimary-gpuhammer-2025GPUHammer GDDR6 model-degradation demonstration92/100
Bounded outcome
Researchers demonstrate GPU-memory bit flips and model-accuracy degradation under their proof-of-concept conditions.
Stated claim
GPUHammer GDDR6 model-degradation demonstration
Evidence status
Published research demonstration (published_research_demonstration)
Device, firmware & configuration

Description: NVIDIA RTX A6000 with48 GB GDDR6; separate A100/RTX3080 tests reported no flips Configuration: User-level CUDA, ECC disabled and a suitable shared/time-sliced memory placement. The paper reports8 unique flips across4 tested banks.

Access required

Ability to run CUDA workloads on the susceptible GPU and satisfy memory co-location assumptions.

Scope / hardware boundary
User-level CUDA, ECC disabled and a suitable shared/time-sliced memory placement. The paper reports8 unique flips across4 tested banks.
Dates
Published: 2025 · Reviewed: 1 November 2026 — Publication date precision: year.
Mechanisms
Hardware Fault Injection – Data Manipulation

Sources

Shared source; these records are not independent experiments. Shared with primary-gputhor-2026.

Limitations

  • The paper's negative results on other tested GPUs are retained.
  • The2025 NVIDIA notice supports enabling system ECC for that threat; the2026 GPUThor preprint prevents treating ECC as a universal guarantee.
  • Artifact presence was checked but the code was not executed.
  • Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Performed

  • Read complete 20-page paper, author site and NVIDIA's July2025 notice.
  • Checked current artifact availability and later GPUThor limitations.

Result

  • Bounded the claim to tested GDDR6/ECC conditions and preserved later counterevidence to universal mitigation claims.

Unresolved / next

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

Evidence confidence · 92/100

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

Framework mappings

Original record: https://gururaj-s.github.io/assets/pdf/SEC25_GPUHammer.pdf (opens original source in a new tab) · Share: link to this record

HardwarePrimary hardware researchDemonstrationprimary-geforge-2026GeForge GPU page-table and configuration-dependent host compromise89/100
Bounded outcome
The paper demonstrates GPU-context confidentiality/integrity compromise and host-root escalation under the stated isolation conditions.
Stated claim
GeForge GPU page-table and configuration-dependent host compromise
Evidence status
Published research demonstration (published_research_demonstration)
Device, firmware & configuration

Description: NVIDIA RTX 3060 and RTXA6000 test GPUs Configuration: Stock driver, ordinary CUDA APIs and ECC disabled. Host-memory escalation requires IOMMU disabled or not enforcing GPU/host isolation.

Access required

A nonprivileged local account with CUDA execution and sufficient GPU memory allocation opportunity.

Scope / hardware boundary
Stock driver, ordinary CUDA APIs and ECC disabled. Host-memory escalation requires IOMMU disabled or not enforcing GPU/host isolation.
Dates
Published: May 2026 · Reviewed: 1 November 2026 — Publication date precision: month.
Mechanisms
Hardware Fault Injection – Data Manipulation

Sources

Shared source; these records are not independent experiments. Shared with primary-gddrhammer-2026.

Limitations

  • GPU-local and host-directed outcomes have different boundaries.
  • An enabled/enforcing IOMMU changes the demonstrated host path.
  • The repository is currently accessible; a historical404 report would not prove current unavailability.
  • Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Performed

  • Read full 19-page paper, especially its threat-model distinction.
  • Verified the current public repository returned substantive content.

Result

  • Retained the host-isolation prerequisite and current artifact evidence.

Unresolved / next

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

Evidence confidence · 89/100

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

Framework mappings

Original record: https://gddr.fail/files/GeForge.pdf (opens original source in a new tab) · Share: link to this record

HardwarePrimary hardware researchDemonstrationprimary-rowhammer-2014Original experimental DRAM disturbance study88/100
Bounded outcome
Repeated accesses cause corruption in other DRAM rows on susceptible modules; the paper establishes the physical disturbance phenomenon.
Stated claim
Original experimental DRAM disturbance study
Evidence status
Published research demonstration (published_research_demonstration)
Device, firmware & configuration

Description: 129 tested DDR3 modules from three manufacturers and Intel/AMD test systems Configuration: The study reports disturbance errors in110 of 129 modules; those historical sample results do not describe every current memory generation.

Access required

Suitable local memory-access execution; characterization also uses laboratory FPGA equipment.

Scope / hardware boundary
The study reports disturbance errors in110 of 129 modules; those historical sample results do not describe every current memory generation.
Dates
Published: 2014 · Reviewed: 1 November 2026 — Publication date precision: year.
Mechanisms
Hardware Fault Injection – Data Manipulation

Sources

Limitations

  • The original disturbance demonstration should not be relabeled as proof of every later privilege-escalation exploit.
  • Refresh, memory-controller, cell and configuration differences matter.
  • Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Performed

  • Read original characterization results.
  • Compared the historical phenomenon with later GPU-specific primary studies.

Result

  • Kept the foundational result separate from later exploit and device configurations.

Unresolved / next

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

Evidence confidence · 88/100

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

Framework mappings

Original record: https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf (opens original source in a new tab) · Share: link to this record

HardwarePrimary hardware researchDemonstrationprimary-gddrhammer-2026GDDRHammer GPU-to-host memory compromise research87/100
Bounded outcome
Authors demonstrate GPU page-table corruption and GPU-to-CPU memory read/write in their end-to-end experiment.
Stated claim
GDDRHammer GPU-to-host memory compromise research
Evidence status
Published research demonstration (published_research_demonstration)
Device, firmware & configuration

Description: GDDR6NVIDIA GPUs in the author's25-plus-device characterization; tested RTXA6000 exploitation Configuration: The threat model uses unprivileged CPU/CUDA execution, default 2 MB GPU pages and ECC disabled; driver and memory topology matter.

Access required

Local user-mode workload execution, including CUDA; no physical access is assumed.

Scope / hardware boundary
The threat model uses unprivileged CPU/CUDA execution, default 2 MB GPU pages and ECC disabled; driver and memory topology matter.
Dates
Published: May 2026 · Reviewed: 1 November 2026 — Publication date precision: month.
Mechanisms
Hardware Fault Injection – Data Manipulation

Sources

Shared source; these records are not independent experiments. Shared with primary-geforge-2026.

Limitations

  • Characterization of many GPUs does not establish full host takeover on every characterized GPU.
  • Do not infer an unexamined IOMMU state or extend the outcome to all isolated cloud configurations.
  • The separate GeForge study is related independent research, not a byte-for-byte reproduction of this setup.
  • Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Performed

  • Read full 19-page paper and threat model, then inspected linked public artifact repository.
  • Compared the outcome and prerequisites against GeForge and GPUHammer.

Result

  • Separated broad bit-flip characterization from the tested end-to-end exploit.

Unresolved / next

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

Evidence confidence · 87/100

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

Framework mappings

Original record: https://gddr.fail/files/gddrhammer.pdf (opens original source in a new tab) · Share: link to this record

HardwarePrimary hardware researchDemonstrationprimary-plundervolt-2020Plundervolt privileged-software fault injection against SGX86/100
Bounded outcome
Authors demonstrate corruption of SGX computations, including cryptographic and memory-safety consequences under the tested conditions.
Stated claim
Plundervolt privileged-software fault injection against SGX
Evidence status
Published research demonstration (published_research_demonstration)
Device, firmware & configuration

Description: Tested Intel SGX-capable Core processors from Skylake onward Configuration: Original table includes i7-6700K, i7-7700HQ, i3-7100U and related tested systems, with microcode-specific conditions.

Access required

Privileged software access to a voltage-management interface; physical access is not required for this threat model.

Scope / hardware boundary
Original table includes i7-6700K, i7-7700HQ, i3-7100U and related tested systems, with microcode-specific conditions.
Dates
Published: 2020 · Reviewed: 1 November 2026 — Publication date precision: year.
Mechanisms
Hardware Fault Injection – Data Manipulation

Sources

Limitations

  • An existing privileged foothold is required; this is not unprivileged remote entry.
  • Current microcode and locked voltage-control configurations can change applicability.
  • Author disclosure/advisory links were read on the author site, but a separate current Intel advisory was not inspected.
  • Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Performed

  • Read full primary paper and its exact CPU/microcode table.
  • Read disclosure/mitigation context and verified that the author artifact repository is accessible.

Result

  • Access and microcode boundaries remain explicit; artifact presence is not execution proof.

Unresolved / next

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

Evidence confidence · 86/100

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

Framework mappings

Original record: https://plundervolt.com/doc/plundervolt.pdf (opens original source in a new tab) · Share: link to this record

HardwarePrimary hardware researchDemonstrationprimary-clkscrew-2017CLKSCREW software-controlled energy-management faults80/100
Bounded outcome
Researchers demonstrate extracting protected AES material and loading self-signed code into TrustZone in the evaluated scenarios.
Stated claim
CLKSCREW software-controlled energy-management faults
Evidence status
Published research demonstration (published_research_demonstration)
Device, firmware & configuration

Description: Commodity Nexus 6 Armv7 / Android platform Configuration: The demonstrated SoC and TrustZone implementation with controllable energy-management behavior.

Access required

A malicious kernel driver; neither ordinary application access nor physical injection is assumed.

Scope / hardware boundary
The demonstrated SoC and TrustZone implementation with controllable energy-management behavior.
Dates
Published: August 2017 · Reviewed: 1 November 2026 — Publication date precision: month.
Mechanisms
Hardware Fault Injection – Data Manipulation

Sources

Limitations

  • Privilege in the normal-world kernel is a prerequisite, not an outcome established from an unprivileged app.
  • The paper's Nexus 6 result does not prove a current autonomous controller is affected.
  • 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 · 80/100

Confidence components for primary-clkscrew-2017
ComponentScoreReason
Provenance20/20Original source and provenance inspected.
Technical evidence34/35Technical evidence read; methods and outcome limits retained.
Configuration specificity18/20Device and configuration details are bounded; missing revisions remain unknown.
Independent corroboration4/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://www.usenix.org/system/files/conference/usenixsecurity17/sec17-tang.pdf (opens original source in a new tab) · Share: link to this record

HardwarePrimary hardware researchDemonstrationLRRK-20261101-PRI-006Blacksmith: measured DDR4/LPDDR4X faults with exploitability analysis kept separate79/100
Bounded outcome
The paper reports faults on all 40 tested DDR4 DIMMs and on 16 of 19 LPDDR4X devices. It then analyzes measured fault locations for compatibility with earlier page-table, RSA and code-corruption attacks. These fault-location/exploitability results are not represented here as completed end-to-end attacks on all devices or all DDR4 memory.
Stated claim
Non-uniform memory access patterns can defeat the tested proprietary in-DRAM refresh mitigations and expose susceptible memory faults.
Evidence status
Published research characterization and exploitability analysis (published_research_characterization_and_exploitability_analysis)
Device, firmware & configuration

Description: Forty DDR4 DIMMs characterized on ten Intel i7-8700K machines; nineteen LPDDR4X devices on a development board Configuration: PC tests used Ubuntu 18.04 LTS/Linux 4.15.0 and DIMMs anonymously grouped A–D. The LPDDR4X tests used an in-house JEDEC-compliant board. The public tool's address-mapping assumptions include Intel Coffee Lake; arbitrary platform compatibility is not established.

Access required

Local memory-intensive test execution on a suitably configured host or the study's development platform. This review establishes characterization conditions, not a demonstrated generic remote entry or a privilege-free packaged exploit.

Scope / hardware boundary
The actual DDR4/LPDDR4X test pools, platform and mappings only. Three tested LPDDR4X devices had no observed faults under this evaluation; this does not establish permanent safety.
Dates
Published: 15 November 2021 · Reviewed: 1 November 2026 — Authors report public disclosure on 15 November 2021; the paper appeared at IEEE S&P 2022. DIMMs were acquired beginning July 2020, not all manufactured in 2021.
Mechanisms
Hardware Fault Injection – Data Manipulation

Sources

Limitations

  • Forty of forty is a result for this acquired pool, not a global vulnerability rate.
  • Observed faults and fault-location analysis differ from a complete exploit delivery chain.
  • Author page, paper, repository and press coverage describe one study and earn no independent-reproduction points.
  • No blanket ECC, DDR5, GPU, robot or drone conclusion follows.
  • Source page-count partial-read status is retained even though core results were available.

Follow-up

Performed

  • Read the Ars lead, then the original author page and paper instead of relying on the broad secondary headline.
  • Separated actual memory faults from derived exploitable-bit analysis and conditional end-to-end claims.
  • Read the LPDDR4X negative boundary and tool platform assumptions.
  • Compared against the already indexed 2014 Rowhammer and later GPU studies; Blacksmith is a distinct historical study.

Result

  • The original DDR4 study is admitted with measured sample counts and a separate exploitability boundary; no universal DDR4/ECC/drone claim is supported.

Unresolved / next

  • Any separate device applicability claim requires exact memory/controller/firmware/isolation state and a separately authorized validation; no current product inference is made.

Evidence confidence · 79/100

Confidence components for LRRK-20261101-PRI-006
ComponentScoreReason
Provenance20/20Original author page/paper and original linked repository inspected; the secondary source was only the discovery route.
Technical evidence32/35Measured faults and exploitability calculations were inspected and kept distinct; PDF extraction remains partial by count.
Configuration specificity18/20CPU, operating system, kernel, anonymized DIMM pool and development-board context are stated; full arbitrary-target delivery conditions are not proven.
Independent corroboration0/15Same-team artifacts and press copies are not independent reproduction.
Follow-up resolution9/10The underlying study, measured boundaries, negative LPDDR4X results and broad headline qualification were resolved.

Overall rationale LrrK analyst confidence in this bounded public evidence account; not probability, severity, device applicability, an official MITRE score, or LrrK bench verification.

Framework mappings

Original record: https://comsec.ethz.ch/wp-content/files/blacksmith_sp22.pdf (opens original source in a new tab) · Share: link to this record

HardwarePrimary hardware researchDemonstrationprimary-gputhor-2026GPUThor preprint: ECC-enabled GPU Rowhammer qualifications78/100
Bounded outcome
Authors report ECC-enabled A6000 denial of service and privilege-escalation demonstrations. Host escalation additionally requires disabled/nonenforcing IOMMU; the paper's broader threat model includes enabled-IOMMU GPU-local scenarios.
Stated claim
GPUThor preprint: ECC-enabled GPU Rowhammer qualifications
Evidence status
Preprint author demonstration (preprint_author_demonstration)
Device, firmware & configuration

Description: Tested GA10x GDDR6 GPUs A4000/A4500/A5000/A6000; ECC-enabled experiments on A6000 Configuration: arXiv2609.16546 updated2026-09-16. Other cloud GPU ECC-on outcomes include estimates, which are not counted as measured ECC-on experiments.

Access required

Unprivileged CUDA execution; GPU-local and host-directed scenarios have different isolation requirements.

Scope / hardware boundary
arXiv2609.16546 updated2026-09-16. Other cloud GPU ECC-on outcomes include estimates, which are not counted as measured ECC-on experiments.
Dates
Published: 15 September 2026 · Reviewed: 1 November 2026 — Publication date precision: day.
Mechanisms
Hardware Fault Injection – Data Manipulation

Sources

Shared source; these records are not independent experiments. Shared with primary-gpuhammer-2025.

Limitations

  • Targeted in-body passages and canonical metadata were read; this strand did not review every appendix or independently reproduce the preprint.
  • The authors report no flips on tested HBM / GDDR6X/newer-generationGDDR6; those negatives are retained.
  • A5000 ECC-on estimates are not promoted into observed experiments.
  • Prior2025 vendor advice is not proof that ECC universally prevents later attacks.
  • Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Performed

  • Read canonical metadata and six targeted body passages covering methods, results, threat model and limitations.
  • Compared those claims with NVIDIA's2025 notice and the originalGPUHammer configuration.

Result

  • Identified material newer evidence that narrows a blanketECC-mitigation statement, while preserving preprint and configuration limits.

Unresolved / next

  • Read the complete versioned preprint and any later vendor response or independent reproduction before strengthening confidence.

Evidence confidence · 78/100

Confidence components for primary-gputhor-2026
ComponentScoreReason
Provenance19/20Original source and provenance inspected.
Technical evidence29/35Technical evidence read; methods and outcome limits retained.
Configuration specificity19/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 resolution8/10Follow-up source checks performed; unresolved items remain explicit.

Framework mappings

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

HardwarePrimary hardware researchDemonstrationLRRK-20261101-PRI-0052015 Project Zero Rowhammer exploits and bounded non-ECC DDR3 laptop measurements72/100
Bounded outcome
The authors report two working exploits: a Native Client sandbox escape and an x86-64 Linux page-table corruption exploit yielding access to physical memory. Their characterization table recorded faults on 15 of 29 non-ECC DDR3 laptops and no faults in the remaining fourteen under that test; neither count establishes a population prevalence or universal safety.
Stated claim
Repeatable DRAM disturbance can be turned into privilege or isolation failures in specified susceptible systems.
Evidence status
Original author research demonstration (original_author_research_demonstration)
Device, firmware & configuration

Description: Anonymized x86-64 Linux/Native Client targets and a 29-laptop non-ECC DDR3 characterization set Configuration: Laptop table spans 2010–2014 model years with anonymized models, CPU families and memory vendors. The physical disturbance test found bit flips on 15 of 29 laptops; this count is not a count of successful end-to-end privilege escalations.

Access required

Execution of local unprivileged x86-64 code on a susceptible memory configuration; the separate Native Client experiment ran inside the then-current sandbox. No physical access is required by the reported software-induced exploit path.

Scope / hardware boundary
Historical, anonymized susceptible DDR3 systems and the reported software environments; all tested bit-flip-positive devices are not established as successfully exploited.
Dates
Published: March 2015 · Reviewed: 1 November 2026 — Original Project Zero report is dated March 2015 by its canonical path and the linked original repository; the exact day was not established in this read. Individual experiment dates remain unknown.
Mechanisms
Hardware Fault Injection – Data Manipulation

Sources

Limitations

  • The retrospective and the original researchers' repository are not independent reproduction of the original exploit.
  • The nonrepresentative laptop table measures fault observations, not successful privilege escalations on all fifteen devices.
  • A negative test does not establish absence of vulnerability; the paper's ECC desktop observation is not an ECC-immunity proof.
  • The original report also states expectations for other systems; those are not promoted to demonstrated outcomes.

Follow-up

Performed

  • Identified arXiv 1904.09724 as a retrospective rather than a new 2019 exploit.
  • Read four relevant retrospective passages and followed its historical account to the original Project Zero report.
  • Counted the 29-row results table as 15 observed-fault and 14 no-observed-fault entries, retaining its nonrepresentative-sample warning.
  • Compared against primary-rowhammer-2014, which is a distinct foundational disturbance study.

Result

  • The 2019 reference receives a bibliographic correction; the actual original 2015 exploitation evidence becomes a separately dated case.

Unresolved / next

  • Exact target identities and current platform applicability remain unknown; do not extrapolate the historical table into a drone, GPU or present-day DRAM prevalence claim.

Evidence confidence · 72/100

Confidence components for LRRK-20261101-PRI-005
ComponentScoreReason
Provenance20/20Original Project Zero institutional report and linked original repository inspected.
Technical evidence32/35Working exploit claims and numerical characterization are distinct and supported in the authored report.
Configuration specificity11/20Memory type and software context are explicit, but target identities and exact revisions are anonymized.
Independent corroboration0/15A later survey/citation and the original team's repository do not constitute independent reproduction.
Follow-up resolution9/10Wrong-year/new-exploit ambiguity resolved by following the retrospective to the dated original.

Overall rationale LrrK analyst confidence in this bounded public evidence account; not probability, severity, device applicability, an official MITRE score, or LrrK bench verification.

Framework mappings

Original record: https://projectzero.google/2015/03/exploiting-dram-rowhammer-bug-to-gain.html (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)