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 3 of 89 reviewed records for EMB3D TID-116 Latent Privileged Access Port. Default order: hardware, then device interface, then context; within each, drones and robotics first, then fault-injection learning.

Full archived edition (JSON) ↓
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 researchDemonstrationprimary-bhis-uart-2019Linksys E2500 v3 UART root-shell account with retained uncertainty63/100
Bounded outcome
The author reports reaching a root shell on the E2500v3, while acknowledging uncertainty about credential entry. Earlier JTAG data were erratic and not a validated firmware extraction.
Stated claim
Linksys E2500 v3 UART root-shell account with retained uncertainty
Evidence status
Author demonstration with uncertainty (author_demonstration_with_uncertainty)
Device, firmware & configuration

Description: Linksys E2500 v3; earlier unsuccessful/erratic JTAG work on a used BEFSR41 is separate Configuration: Specific serial access points and BusyBox shell behavior reported by the original author; firmware version is unspecified.

Access required

Physical access to the internal UART interface.

Scope / hardware boundary
Specific serial access points and BusyBox shell behavior reported by the original author; firmware version is unspecified.
Dates
Published: 2019 · Reviewed: 1 November 2026 — Publication date precision: year.
Mechanisms
Latent Privileged Access Port

Sources

Limitations

  • The authentication-bypass explanation is not conclusively established by the account.
  • A root prompt report is not independent proof of complete firmware extraction.
  • The failed/erratic work on another board must not be counted as a successful JTAG result.
  • Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Performed

  • Read the author's explicit caveats about the used board, erratic dump and possible credential-entry error.

Result

  • Preserved the successful shell observation separately from uncertain causal explanation and failed extraction.

Unresolved / next

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

Evidence confidence · 63/100

Confidence components for primary-bhis-uart-2019
ComponentScoreReason
Provenance20/20Original source and provenance inspected.
Technical evidence21/35Technical evidence read; methods and outcome limits retained.
Configuration specificity13/20Device and configuration details are bounded; missing revisions remain unknown.
Independent corroboration2/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://www.blackhillsinfosec.com/how-to-hack-hardware-using-uart/ (opens original source in a new tab) · Share: link to this record

HardwarePrimary hardware researchReported resultLRRK-20261101-PRI2-002Security Innovation's 2018 UART example: author-reported root shell on a TP-Link TL-WR841N60/100
Bounded outcome
The archived article explicitly identifies the TL-WR841N and labels its final outcome as root-shell access, linking two screenshots. This review confirms the authored claim and target in the retained text; the screenshots and underlying console/privilege evidence were not independently inspected or reproduced. Firmware extraction and secret recovery are discussed as possible consequences, not reported results retained here.
Stated claim
The original author reports reaching a privileged shell through the router's UART interface.
Evidence status
Archived original author reported privileged console access (archived_original_author_reported_privileged_console_access)
Device, firmware & configuration

Description: TP-Link TL-WR841N home router in the original author's UART access example Configuration: Article identifies an Attify-Badge 2.0 interface, but does not establish the tested router's exact hardware revision or firmware build. It references FCC photos for TE7WR841NXV9; that reference alone does not prove the demonstrated unit is revision v9.

Access required

Physical access to the router's internal UART/service interface and local serial-observation equipment; no remote route or device actuation was performed in this review.

Scope / hardware boundary
A historical, physically accessed TL-WR841N example with missing revision/build information; not a general property of every router, UART interface, robot or drone.
Dates
Published: 30 August 2018 · Reviewed: 1 November 2026 — Original archived page byline names Satish S and displays 30 August 2018; a separate public referral agrees. The reviewed archive capture is 23 October 2020 at 09:15:51 UTC, not the publication or experiment date. No claim of continuous content stability or present-day vulnerability is made.
Mechanisms
Latent Privileged Access Port; UART service-console access

Sources

  • IoT Devices - The Not-So-Hidden Risk of UART Interface (opens original source in a new tab) · Archived original publisher article · Partially read 1 November 2026
    • Main article text/metadata reviewed. Embedded terminal screenshots are linked but were not visually inspected; underlying raw console bytes, authentication sequence and privilege validation are not established in this pass.
    • Archive capture date is 2020-10-23T09:15:51Z; the page's displayed publication date is 2018-08-30.
    • The current original HTTPS route previously failed TLS and was not retried or bypassed.

    Supports: Original title, byline/date, named device and explicit final privileged-shell claim recovered at the original publisher URL's public capture.

  • web.archive.org (opens original source in a new tab) · Public archive capture index · Reviewed 1 November 2026
    • Capture metadata confirms an archival route, not the technical outcome or original publication date.

    Supports: Supplies the exact archived URL/timestamp selected through normal public access.

  • cbr-doc/posts/cc/Router_post_sort_by_cc_cnt.md at master · WilsonHuha/cbr-doc · GitHub (opens original source in a new tab) · Third party public bibliographic referral · Reviewed 1 November 2026
    • Bibliographic agreement is not independent replication of the root-shell claim.

    Supports: Links the exact publisher URL/title and lists 2018-08-30, supporting identification of the recovered article.

Limitations

  • No successful LrrK UART connection or hardware test is implied.
  • The article's general claims about what a root shell could enable are not firmware-extraction or credential-recovery demonstrations.
  • The pinned MITRE page also cites a different TL-WR840N EU v6.20 vulnerability reference; it is not assigned to this TL-WR841N record.
  • The pre-existing BHIS case concerns a Linksys E2500 v3 and remains separate.
  • The archive, referral and official taxonomy citation are not independent technical corroboration.
  • AI-assisted public-source desk review; exact build, authentication behavior, raw console evidence and underlying screenshot validation remain incomplete.

Follow-up

Performed

  • Retained the known original TLS failure without retrying, weakening TLS or changing provider policy.
  • Inspected a public referral and the publisher's normal homepage redirect without treating an unrelated current page as the original article.
  • Queried the public archive index, then read the exact 2020 capture of the original article.
  • Separated its explicit reported shell result from generic consequences, screenshot proof not reviewed, and missing device/firmware revision.
  • Verified the exact canonical article reference on pinned MITRE TID-116.

Result

  • The original source identity, named target and bounded author-reported result are now reviewed through an archival original. This closes the missing-article lead for this scored record, without establishing independently verified root access or current product applicability.

Unresolved / next

  • Any stronger privilege/firmware outcome claim would require review of the retained screenshots or a separately available original console artifact, and exact hardware/firmware identification; no physical test or source-author contact is authorized.

Evidence confidence · 60/100

Confidence components for LRRK-20261101-PRI2-002
ComponentScoreReason
Provenance19/20A public capture retains the exact original publisher article, title, byline and displayed date; current original access is still unavailable.
Technical evidence21/35The article explicitly reports the shell result but its visual/raw proof was not independently inspected, limiting technical strength.
Configuration specificity12/20Router family and local interface are named; actual hardware revision, firmware and authentication behavior remain unknown.
Independent corroboration0/15Archive/referral/taxonomy references support source identity only and do not reproduce the experiment.
Follow-up resolution8/10The missing original article and generic-versus-specific result distinction were resolved; screenshot and build-level questions remain explicit.

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://blog.securityinnovation.com/iot_uart (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)