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 7 of 89 reviewed records for EMB3D TID-107 Unauthorized Direct Memory Access (DMA). 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-dma-hp-2020HP pre-boot DMA demonstration and configuration-dependent retest82/100
Bounded outcome
Original system permitted boot-time memory modification/code execution. The author retest reports protection on the newer BIOS when configured to cover the relevant devices, while a Thunderbolt-only setting left the internal path exposed.
Stated claim
HP pre-boot DMA demonstration and configuration-dependent retest
Evidence status
Published research demonstration (published_research_demonstration)
Device, firmware & configuration

Description: HP ProBook 640 G4; retest on EliteBook 840 G6 with Sure Start Gen 5 Configuration: Original open-chassis DMA test; retest BIOS 01.04.02 dated 2020-01-20. The pre-boot protection setting changes the result.

Access required

Physical internal DMA-capable interface access before OS boot.

Scope / hardware boundary
Original open-chassis DMA test; retest BIOS 01.04.02 dated 2020-01-20. The pre-boot protection setting changes the result.
Dates
Published: 30 January 2020 · Reviewed: 1 November 2026 — Publication date precision: day.
Mechanisms
Unauthorized Direct Memory Access (DMA)

Sources

Shared source; these records are not independent experiments. Shared with primary-dma-dell-2020.

Limitations

  • The attack and retest involve different hardware generations.
  • The researcher's successful retest is not independent LrrK validation or a blanket statement about all HP systems.
  • Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Performed

  • Read the newer EliteBook BIOS retest and its contrast between protection settings.

Result

  • Retest/counterevidence is preserved alongside the initial success.

Unresolved / next

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

Evidence confidence · 82/100

Confidence components for primary-dma-hp-2020
ComponentScoreReason
Provenance20/20Original source and provenance inspected.
Technical evidence30/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://eclypsium.com/blog/direct-memory-access-attacks-a-walk-down-memory-lane/ (opens original source in a new tab) · Share: link to this record

HardwarePrimary hardware researchDemonstrationprimary-ai-runtime-dma-2026Controlled GH200/BlueField runtime-model modification81/100
Bounded outcome
Eclypsium demonstrates changing runtime model behavior while stored-model integrity checks and previously completed artifact/boot checks remain valid.
Stated claim
Controlled GH200/BlueField runtime-model modification
Evidence status
Controlled vendor research demonstration (controlled_vendor_research_demonstration)
Device, firmware & configuration

Description: Controlled NVIDIA GH200 system with BlueFieldDPU Configuration: Privileged DMA-capable infrastructure component; memory reachability depends on IOMMU,PCIe topology and platform controls.

Access required

Existing access/control over an infrastructure component with sufficient mapped-memory privileges; no unauthenticated remote entry is established.

Scope / hardware boundary
Privileged DMA-capable infrastructure component; memory reachability depends on IOMMU,PCIe topology and platform controls.
Dates
Published: 29 October 2026 · Reviewed: 1 November 2026 — Publication date precision: day.
Mechanisms
Unauthorized Direct Memory Access (DMA)

Sources

Limitations

  • This is a controlled demonstration, not evidence of widespread exploitation.
  • The case establishes one configuration-specific integrity gap, not that all BlueField or GPU deployments are unsafe.
  • The release and report are the same research organization, not independent corroboration.
  • Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Performed

  • Read complete 15-page primary report and dated announcement.
  • Checked the test-platform, privileged-access and runtime-versus-stored-artifact distinctions.

Result

  • Bounded the account to the demonstrated GH200/DPU configuration and avoided a generic model-file or remote-attack claim.

Unresolved / next

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

Evidence confidence · 81/100

Confidence components for primary-ai-runtime-dma-2026
ComponentScoreReason
Provenance20/20Original source and provenance inspected.
Technical evidence32/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 resolution7/10Follow-up source checks performed; unresolved items remain explicit.

Framework mappings

Original record: https://eclypsium.com/wp-content/uploads/Trusted-AI-Requires-Trusted-Infrastructure.pdf (opens original source in a new tab) · Share: link to this record

HardwarePrimary hardware researchDemonstrationLRRK-20261101-PRI-0042018 IOMMU boot-window bypass demonstrated on a Dell Precision T170078/100
Bounded outcome
Following preliminary hypervisor simulation, the authors report a physical FPGA proof of concept that exploited a boot-time DMA protection window and changed Linux kernel behavior so an unprivileged local program gained effective root privileges. This does not establish a universal VT-d failure or an arbitrary post-boot IOMMU bypass.
Stated claim
An IOMMU being enabled after boot does not establish that its configuration was protected throughout boot.
Evidence status
Published research physical proof of concept (published_research_physical_proof_of_concept)
Device, firmware & configuration

Description: Dell Precision T1700 with a malicious PCI Express FPGA peripheral Configuration: Firmware A06 (source renders 12/05/2013 without disambiguating month/day); Intel i7-4770, PCH C220, Linux 4.3.4 with IOMMU_INTEL enabled, GRUB 2.02.beta2. Physical prototype used a Xilinx ML605-based peripheral, after preliminary hypervisor simulation.

Access required

A malicious or already compromised DMA-capable PCIe peripheral, precise knowledge of the target hardware/kernel layout, and the vulnerable firmware-to-kernel protection transition. The demonstrated physical FPGA path is separate from the paper's hypothesized remote peripheral-compromise entry.

Scope / hardware boundary
Tested firmware/boot/kernel sequence and PCIe access conditions only; the 2010 bridge/requester-identity issue is a different study, and modern platform protection state is not inferred.
Dates
Published: 9 January 2018 · Reviewed: 1 November 2026 — Published 9 January 2018; a preliminary version was presented in 2016. This is not the 2010 Sang/Lacombe/Nicomette/Deswarte study.
Mechanisms
Unauthorized Direct Memory Access (DMA)

Sources

Limitations

  • Exact hardware/kernel knowledge and malicious-peripheral access are assumed.
  • The physical proof of concept is distinct from the preliminary hypervisor simulation.
  • Windows/BSD and Intel TXT were discussed as further work, not validated outcomes.
  • The article's broad prevalence statements are not treated as measured evidence for every IOMMU system.
  • No independent reproduction or present-day vendor remediation status was verified.

Follow-up

Performed

  • Checked the IEEE PDF route; it returned a sign-in/purchase page with abstract, not the paper.
  • Checked the original 2010 coauthor's public bibliography and author-manuscript search routes without bypass.
  • Read the accessible 2018 paper and separated its measured boot-window attack from the earlier PCI/PCIe requester-identity discussion.

Result

  • A related 2018 case is admitted. The 2010 lead remains pending for its original methods/configuration, so this record must not silently resolve or rename it.

Unresolved / next

  • Read an ordinarily accessible 2010 author manuscript if one becomes available; do not assume the 2018 machine or boot conditions describe the 2010 exploit.

Evidence confidence · 78/100

Confidence components for LRRK-20261101-PRI-004
ComponentScoreReason
Provenance20/20Original open-access publisher article, authors, date and complete technical account inspected.
Technical evidence32/35Both simulation and subsequent physical FPGA evidence are distinguished; reported kernel outcome retained.
Configuration specificity19/20Machine, firmware, processor, chipset, Linux version, bootloader and assumptions are explicit.
Independent corroboration0/15No independently reproduced experiment was reviewed; a same-team preliminary version is not independent.
Follow-up resolution7/10The accessible related study was resolved, while the original 2010 evidence gap remains held.

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://link.springer.com/article/10.1186/s13173-017-0066-7 (opens original source in a new tab) · Share: link to this record

HardwarePrimary hardware researchDemonstrationprimary-dma-dell-2020Pre-boot DMA exposure from Dell XPS7390 Thunderbolt configuration76/100
Bounded outcome
Researchers demonstrate a closed-chassis DMA attack in the tested configuration despite other boot-security features.
Stated claim
Pre-boot DMA exposure from Dell XPS7390 Thunderbolt configuration
Evidence status
Published research demonstration (published_research_demonstration)
Device, firmware & configuration

Description: Dell XPS 13 7390 2-in-1 Configuration: The tested default enabled Thunderbolt/PCIe pre-boot modules; the report links a Dell advisory and says other platforms had that setting disabled.

Access required

Physical external Thunderbolt connection during the relevant pre-boot state.

Scope / hardware boundary
The tested default enabled Thunderbolt/PCIe pre-boot modules; the report links a Dell advisory and says other platforms had that setting disabled.
Dates
Published: 30 January 2020 · Reviewed: 1 November 2026 — Publication date precision: day.
Mechanisms
Unauthorized Direct Memory Access (DMA)

Sources

Shared source; these records are not independent experiments. Shared with primary-dma-hp-2020.

Limitations

  • The insecure setting is material; presence of Thunderbolt alone is insufficient.
  • The linked Dell advisory itself was not separately read in this strand; vendor remediation is reported by the researchers.
  • Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Performed

  • Read the original attack and vendor-mitigation sections.

Result

  • The demonstrated configuration is bounded; no claim is made about current defaults or firmware.

Unresolved / next

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

Evidence confidence · 76/100

Confidence components for primary-dma-dell-2020
ComponentScoreReason
Provenance20/20Original source and provenance inspected.
Technical evidence28/35Technical evidence read; methods and outcome limits retained.
Configuration specificity18/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 resolution5/10Follow-up source checks performed; unresolved items remain explicit.

Framework mappings

Original record: https://eclypsium.com/blog/direct-memory-access-attacks-a-walk-down-memory-lane/ (opens original source in a new tab) · Share: link to this record

HardwarePrimary hardware researchDemonstrationprimary-thunderspy-2020Thunderspy Thunderbolt security research and protection boundary74/100
Bounded outcome
The author reports multiple controller-protection weaknesses enabling unauthorized DMA paths on tested systems and distinguishes partial protection from Kernel DMA Protection.
Stated claim
Thunderspy Thunderbolt security research and protection boundary
Evidence status
Published research demonstration (published_research_demonstration)
Device, firmware & configuration

Description: Thunderbolt1/2/3 systems investigated by the original researchers Configuration: Attack variants depend on controller firmware and whether Kernel DMA Protection is implemented. Historical2011–2020 product claims are not treated as a2026 inventory.

Access required

Brief physical access, often opening the enclosure; some variants involve a connected peripheral.

Scope / hardware boundary
Attack variants depend on controller firmware and whether Kernel DMA Protection is implemented. Historical2011–2020 product claims are not treated as a2026 inventory.
Dates
Published: 2020 · Reviewed: 1 November 2026 — Publication date precision: year.
Mechanisms
Unauthorized Direct Memory Access (DMA)

Sources

Limitations

  • The homepage's broad device statements require per-system validation.
  • Spycheck is a discovery/checking artifact, not proof of successful exploitation.
  • No current product-wide vulnerability claim is made.
  • Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Performed

  • Read the author's updates and Kernel DMA Protection discussion.
  • Verified the public Spycheck repository exists; did not run it.

Result

  • Availability of a checker is separated from vulnerable-device or exploitation evidence.

Unresolved / next

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

Evidence confidence · 74/100

Confidence components for primary-thunderspy-2020
ComponentScoreReason
Provenance20/20Original source and provenance inspected.
Technical evidence28/35Technical evidence read; methods and outcome limits retained.
Configuration specificity15/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 resolution7/10Follow-up source checks performed; unresolved items remain explicit.

Framework mappings

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

HardwarePrimary hardware researchReported resultLRRK-20261101-PRI2-001SSTIC 2010: shared PCI requester identity and author-reported ARP-cache corruption69/100
Bounded outcome
The authors present a proof of concept with before/after ARP-cache output, reporting modification through the Ethernet receive-memory region shared with the FireWire controller's protection domain. Separately, their direct kernel-code injection control failed with VT-d enabled. The shared-buffer result is not proof of unrestricted kernel-memory access with VT-d active.
Stated claim
Bridge-translated conventional PCI devices sharing one requester/source identity cannot be isolated from each other's authorized DMA buffers by the per-identity VT-d boundary.
Evidence status
Original conference author reported dma proof of concept (original_conference_author_reported_dma_proof_of_concept)
Device, firmware & configuration

Description: Intel VT-d-capable Linux desktop scenario with conventional PCI Ethernet and FireWire devices behind one PCI-to-PCIe bridge Configuration: The Ethernet component is identified as VIA Rhine VT6102. The proof-of-concept assumes identical known host layouts and Intel VT-d enabled in both BIOS and kernel. Exact motherboard, firmware and tested kernel revision are not established. A Q45/ICH10/Core 2 Duo architecture figure is not treated as verified test-unit identity; discussion of Linux support beginning at 2.6.24 is not a tested-version pin.

Access required

A DMA-capable peripheral connected through the victim's FireWire path and the shared legacy PCI topology, plus prior target-layout knowledge. No generic remote entry or access to all host memory is established.

Scope / hardware boundary
Conventional PCI devices sharing a translated requester identity behind one bridge; not arbitrary PCIe, Thunderbolt/USB4, GPU, embedded, drone or robot configurations.
Dates
Published: June 2010 · Reviewed: 1 November 2026 — Author bibliography dates the SSTIC paper to June 2010, pages 189–214. Experiment dates are not established. The separate MALWARE/IEEE paper is listed for October 2010; this record does not substitute its venue or date.
Mechanisms
Unauthorized Direct Memory Access (DMA); Shared requester identity across a legacy PCI bridge

Sources

  • Analyse de l’efficacité du service fourni par une IOMMU (opens original source in a new tab) · Original conference research paper · Reviewed 1 November 2026
    • All 26 pages were returned. Relevant sections 3.2, 4.2, 5 and 6–7 were substantively reviewed; no experiment code was executed.
    • The proof is an author-presented account/output, with no independent capture or reproduction verified.
    • Exact physical victim identifiers and full software/firmware version pins remain missing.

    Supports: The 26-page SSTIC article supplies source-identity analysis, required topology, peer-buffer proof of concept, the successful isolation control and countermeasure discussion.

  • Fernand Lone-Sang - Security Researcher (opens original source in a new tab) · Original author bibliography · Reviewed 1 November 2026
    • Homepage link labels for slides/article are swapped relative to the returned PDF contents; the 26-page article content, not the label, determines this source's type.
    • A personal bibliography and the author's paper are not independent corroboration.

    Supports: The coauthor separately lists the June SSTIC paper and October MALWARE paper, establishing authorship/venue links without proving textual or experimental identity.

Limitations

  • The author lists the two 2010 publications separately. No verified statement that they are identical translations or the same measured experiment was located.
  • The proof-of-concept narrative uses a modified FireWire peripheral/iPod scenario; the exact physical peripheral model used for measurement is not established.
  • Do not generalize the authors' reasoning about other IOMMU implementations into a demonstrated AMD outcome.
  • The enabled-VT-d negative control and successful shared-domain alteration are different results.
  • This companion account and any later IEEE version must not automatically count as independent experiments.
  • AI-assisted public-source desk review only; no LrrK hardware test or independent human verification of the experiment.

Follow-up

Performed

  • Checked the exact DOI and exact-title HAL metadata routes; both returned zero matching records, which is not proof no deposit exists.
  • Read the author's normally accessible bibliography and followed its SSTIC article link.
  • Separated the protected kernel-memory control from the reported shared-buffer outcome and retained requester-identity/topology requirements.
  • Compared with the already published 2018 Dell boot-window case; it is a different mechanism and configuration.

Result

  • A related original 2010 conference account is now source-supported. The exact IEEE 5665798 methods remain unread; that original lead stays pending and unscored.

Unresolved / next

  • If a normally accessible original IEEE manuscript becomes available, compare its methods and lineage with this SSTIC account before resolving the original lead or counting a separate experiment.

Evidence confidence · 69/100

Confidence components for LRRK-20261101-PRI2-001
ComponentScoreReason
Provenance20/20Original conference-hosted article and its coauthor's bibliography were read.
Technical evidence29/35The technical identity-boundary explanation, reported output and negative control were inspected; no raw independent reproduction was verified.
Configuration specificity13/20Relevant bus, bridge, device and IOMMU-state conditions are explicit, but exact host and software revisions are absent.
Independent corroboration0/15The author bibliography, article and later citations are one research lineage, not independently executed corroboration.
Follow-up resolution7/10A useful original companion source was recovered while the exact IEEE identity/methods gap was deliberately left open.

Overall rationale LrrK analyst evidence strength for the bounded source claim, not probability, severity, applicability to another device, a MITRE score, or LrrK physical validation.

Framework mappings

Original record: https://www.sstic.org/media/SSTIC2010/SSTIC-actes/Analyse_de_l_efficacite_du_service_fourni_par_une_/SSTIC2010-Article-Analyse_de_l_efficacite_du_service_fourni_par_une_IOMMU-lacombe_lone-sang_nicomette_deswarte.pdf (opens original source in a new tab) · Share: link to this record

HardwareCommunity discussionDiscussionLRRK-COM-007PCILeech Kernel DMA Protection issue: protection limits and an aged bypass hypothesis46/100
Bounded outcome
The maintainer says enabled DMA protection blocks the original locked-computer use case and that an older preboot blog is less relevant. This is not a demonstrated universal bypass.
Stated claim
The issue asks whether alternative interfaces or firmware changes could bypass DMA protections.
Evidence status
Discussion hypothesis with correction (discussion_hypothesis_with_correction)
Device, firmware & configuration

Scenario: PCILeech FPGA/peripheral against Windows Kernel DMA Protection Protection state: Central to the discussion; no controlled target configuration established.

Access required

Proposed physically connected DMA-capable device; a separate historical firmware-compromise hypothesis has stronger prior-access assumptions.

Dates
Published: 14 July 2021 · Reviewed: 1 November 2026 — Replies read through closure on 2024-06-01; historical claims are not current Windows validation.
Mechanisms
direct memory access; malicious connected peripherals

Sources

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

Limitations

  • No new live test of any operating system was performed.
  • Interface support, IOMMU configuration and boot state cannot be generalized.
  • Closure as completed in the issue tracker is not proof that the proposed attack succeeded.

Follow-up

Actions performed

  • Read the full issue, including 2022 correction and 2024 closure, instead of relying on its bypass title.
  • Separated a prior-firmware-compromise hypothesis from a standalone peripheral bypass.

Results

  • The issue's title overstates what is demonstrated.
  • The historical preboot claim was qualified by its author as less relevant to newer systems.

Contradictions

  • The proposed universal bypass is not supported; maintainer explicitly recognizes effective DMA protections when enabled.

Follow-up limitations

  • No new live test of any operating system was performed.
  • Interface support, IOMMU configuration and boot state cannot be generalized.
  • Closure as completed in the issue tracker is not proof that the proposed attack succeeded.

Evidence confidence · 46/100

Confidence components for LRRK-COM-007
ComponentScoreReason
Provenance18/20Unavailable — no separate reason was recorded.
Technical evidence10/35Unavailable — no separate reason was recorded.
Configuration specificity8/20Unavailable — no separate reason was recorded.
Independent corroboration0/15Unavailable — no separate reason was recorded.
Follow-up resolution10/10Unavailable — no separate reason was recorded.

Overall rationale Verified public maintainer correction resolves a misleading title; actual bypass evidence and a reproducible target configuration are absent.

Framework mappings

Original record: https://github.com/ufrisk/pcileech/issues/172 (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)