Hardware Attack Library (HAL)

Bounded outcome

Bench results report absent or altered failsafe responses. In Gazebo Classic SITL, manually forcing the selected action to None produced Hold instead of RTL for RC-loss and critical-battery scenarios; the emergency-battery scenario still landed. This does not demonstrate a hijacked or crashed flying UAV.

Stated claim

Authors report that physical voltage faults altered failsafe outputs on a simplified STM32 test setup. The separately instrumented SITL experiment altered return-to-launch behavior in two scenarios but retained emergency-battery landing.

Evidence status

Author reported controlled demonstration (author-reported-controlled-demonstration)

Device, firmware & configuration

Description: STM32F407-Discovery running PX4-derived failsafe code; separate ARMORY and Gazebo Classic software experiments Configuration: The paper explicitly removed the PX4 API layer for the physical bench experiment. No PX4 commit, release pin, assembled flight-controller model or flown-aircraft configuration was established.

Access required

Physical bench access to the development board and laboratory voltage-fault instrumentation; software simulation is a separate access/evidence mode.

Scope / hardware boundary

Direct voltage disturbance of an STM32 development board; control-logic proxy, not a tested autonomous implant or production drone.

Dates

Published: 17 April 2026 · Reviewed: 1 November 2026 — Canonical v1 submission: 2026-04-17. The paper-index update date is not a new experiment date. Canonical page labels this a Technical Report.

Mechanisms

Voltage fault injection; Control-flow/failsafe decision disturbance; Separate software fault simulation

Sources

• Glitch in the Sky, arXiv:2604.16699v1 ↗ (opens original source in a new tab) · Primary source · Reviewed 1 November 2026

  Supports: Bench setup, explicit API-layer removal, physical results, and the SITL emergency-landing counterexample.

• Canonical arXiv record and version history ↗ (opens original source in a new tab) · Primary source · Reviewed 1 November 2026

  Supports: Technical Report; v1 submitted 17 April 2026; no later version or withdrawal notice displayed in the retrieved record.

Limitations

• Technical-report/preprint evidence; no independent physical reproduction reviewed.
• Clock glitching is background discussion, not the demonstrated fault mechanism in this study.
• The autonomous concealed implant and supply-chain scenario are proposed threat-model elements, not experimentally validated deployments.
• Board-level failures cannot be generalized to a current PX4 release or every STM32 flight controller.
• The emergency-battery SITL result retained Land; do not claim all failsafes were bypassed.
• No LrrK hardware experiment or flight test was performed.

Follow-up

Evidence confidence · 71/100

Overall rationale Confidence in this bounded evidence claim; not probability, severity, device applicability or a MITRE rating.

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  Physical voltage disturbance changed reported decisions/control behavior; the official threat covers physical fault-induced execution changes.

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

Bounded outcome

IOActive reports a process crash with attacker-controlled values in registers after EM fault injection. Its separate EM side-channel key-recovery attempt was impractical; a reliable code-execution payload was described as future work.

Stated claim

DJI Mavic Pro: EM fault injection produced controlled memory corruption during firmware update

Evidence status

Controlled demonstration partial outcome (controlled-demonstration-partial-outcome)

Device, firmware & configuration

Vendor: DJI Models: Mavic Pro Configuration: Physically accessed board and firmware-update processing; exact tested firmware revision not disclosed in the inspected blog.

Access required

Class: physical-hardware Requirements: Physical possession, board access and specialized EM fault-injection instrumentation; laboratory iteration.

Scope / hardware boundary

Direct physical perturbation of the processor during update handling.

Dates

Published: 13 June 2023 · Reviewed: 1 November 2026 — Source update metadata: 2025-05-15; this is not an event date.

Mechanisms

Hardware Fault Injection – Control Flow Modification

Sources

• Applying Fault Injection to the Firmware Update Process of a Drone - IOActive ↗ (opens original source in a new tab) · Original research · Reviewed 1 November 2026

  Supports: Observed memory corruption, attempted but impractical key recovery, and the explicit remaining code-execution step.

Limitations

• No independently reproduced code execution, full drone control, extracted encryption key, or operational exploitation established.
• Exact firmware version absent; modified blog metadata is not a new experiment date.
• Do not map this EMFI result to software-induced Rowhammer TID-110 merely because both alter data.

Follow-up

• Resolved Did the researchers demonstrate full code execution? No: the article makes payload design the next step after observed corruption. source ↗ (opens original source in a new tab)
• Open Can a current owner device be declared vulnerable? No exact tested firmware pin or independent replication; owner-specific validation remains unperformed.

Evidence confidence · 68/100

Overall rationale Original instrumented research with explicit negative and partial outcomes; no independent reproduction or precise firmware revision.

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  Physical EM glitching is the researched mechanism. Fit does not extend the observed result beyond a crash and controlled register corruption.

Original record: https://www.ioactive.com/applying-fault-injection-to-the-firmware-update-process-of-a-drone/ ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

CISA reports deterministic communication keys and lack of base-station firmware validation, permitting malicious updates/code execution. Vendor lists fixed versions; CISA Update A says mitigation is available for all listed devices.

Stated claim

ECOVACS robot/base-station link permits malicious firmware updates

Evidence status

Vendor and government confirmed vulnerability (vendor-and-government-confirmed-vulnerability)

Device, firmware & configuration

Description: Vendor: ECOVACS Models: X1S PRO; X1 PRO OMNI; X1 OMNI; X1 TURBO; T10 Series; T20 Series; T30 Series Firmware versions: X1S PRO/X1 PRO OMNI before 2.5.38; X1 OMNI/X1 TURBO before 2.4.45; T10 before 1.11.0; T20 before 1.25.0; T30 before 1.100.0 Configuration: Vacuum/base-station local Wi-Fi link and firmware update verification. Reported cves: CVE-2025-30198; CVE-2025-30199; CVE-2025-30200

Access required

Class: adjacent-radio/firmware-update Requirements: Ability to access or forge the insecure vacuum/base link under reported credential and firmware-update prerequisites; CVE-2025-30199 also has a high-privilege CVSS prerequisite.

Scope / hardware boundary

Direct firmware trust boundary on an embedded robot peripheral/base station; not evidence of malicious operational exploitation.

Dates

Published: 15 May 2025 · Reviewed: 1 November 2026 — Source update metadata: 2025-07-10; this is not an event date.

Mechanisms

Device Allows Unauthenticated Firmware Installation; Predictable Cryptographic Key

Sources

• ECOVACS DEEBOT Vacuum and Base Station (Update A) | CISA ↗ (opens original source in a new tab) · Government advisory · Reviewed 1 November 2026

  Supports: Mechanisms, CVEs, affected versions, update history.

• Security Advisory - Base station communication security issues of DEEBOT series products - ECOVACS GLOBAL ↗ (opens original source in a new tab) · Vendor advisory · Reviewed 1 November 2026

  Supports: Product-specific fixed firmware list and update dates.

Limitations

• The advisory groups related weaknesses; do not flatten every CVE into an unauthenticated Internet RCE.
• CISA and vendor coordinated disclosure are corroboration of acknowledgement, not independent experimental replication.
• No owner-device test or incident attribution performed.

Follow-up

• Resolved Does the base station validate its updates? CISA explicitly identifies download without integrity checking in CVE-2025-30199. source ↗ (opens original source in a new tab)
• Resolved Was remediation later available? Vendor updated July 1 and CISA Update A July 10 supplies fixes for all listed products. source ↗ (opens original source in a new tab) source ↗ (opens original source in a new tab)

Evidence confidence · 81/100

Overall rationale Government/vendor agreement, clear mechanism, versions and later fix; no independent reproduction.

Framework mappings

• Analyst inference EMB3D TID-211 Device Allows Unauthenticated Firmware Installation ↗ (opens original source in a new tab)

  Base-station update packages are not validated on-device, matching the official unauthenticated-installation trust boundary.

• Analyst inference EMB3D TID-317 Predictable Cryptographic Key ↗ (opens original source in a new tab)

  Communication keys are derived predictably from the serial number.

• Analyst inference ATT&CK ICS T1693.001 Modify Firmware: System Firmware ↗ (opens original source in a new tab)

  Analyst cross-reference to unauthorized firmware installation on the embedded base device; not a MITRE-observed campaign.

Original record: https://www.cisa.gov/news-events/ics-advisories/icsa-25-135-19 ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

The controller completes the communication protocol despite the withheld instruction. The paper separately evaluates response-timing detection of the inserted module under its tested message sequences and latency conditions.

Stated claim

The authors implemented an inline FPGA module that can forward, suppress or alter actuator communication. The illustrated suppression experiment returns fabricated status while withholding the controller instruction from the actuator.

Evidence status

Author reported controlled demonstration (author-reported-controlled-demonstration)

Device, firmware & configuration

Description: Dynamixel AX-12A servomotor using protocol 1.0 and FPGA controller/interposer logic on an Artix-7 XC7A100T Configuration: Half-duplex UART actuator chain and a laboratory FPGA attack module. The concrete illustrated suppression/status trace uses an LED instruction; the complete hybrid hexapod is future work.

Access required

Physical insertion of an active module between the low-level controller and actuator communication chain.

Scope / hardware boundary

Physical peripheral-bus interposition; no processor clock fault, demonstrated supply-chain implant, full-hexapod takeover or drone attack.

Dates

Published: 14 December 2025 · Reviewed: 1 November 2026 — Publisher date: 14 December 2025; experiment dates not separately established.

Mechanisms

Peripheral-bus interposition; Command suppression; Status spoofing

Sources

• Exploring Hardware Vulnerabilities in Robotic Actuators: A Case of Man-in-the-Middle Attacks ↗ (opens original source in a new tab) · Primary source · Selected sections reviewed 1 November 2026
  • Full HTML retained; relevant methods/results, table text and figure captions reviewed. Figure images were not independently visually inspected.

  Supports: Named actuator/FPGA setup, illustrated suppression/status exchange, timing-defense limits and explicit full-platform future work.

Limitations

• Do not generalize the AX-12A/protocol-1.0 experiment to every Dynamixel product or an assembled operational robot.
• The clearest illustrated suppression experiment concerns an LED command; unsafe physical movement or gait takeover is not established.
• No independent reproduction or original implementation repository reviewed.
• The reported 100% true-positive result applies to the tested sequences, including a transparent interposer; it is not universal detection accuracy. Table 6 reports material LED false positives (21.4%), versus 1.2% for Move and 0.25% for Ping.
• A miniaturized concealed implant is proposed, not an observed deployment.
• No ATT&CK/ICS procedure mapping is asserted for this bench study.

Follow-up

Evidence confidence · 77/100

Overall rationale LRRK evidence strength for the narrowly stated claim; not severity, exploitation probability, current-device applicability, safety or an official MITRE score.

Framework mappings

• Analyst inference EMB3D TID-114 Peripheral Data Bus Interception ↗ (opens original source in a new tab)

  An inline physical module suppresses or changes controller-to-actuator data and returns fabricated peripheral status over the UART bus.

Original record: https://www.mdpi.com/2079-9292/14/24/4909 ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

Real motors retained preceding speed commands; encoder-fed virtual navigation deviated from the planned roundabout path. A proposed frequency-sensor defense stopped the motors during the disturbance and resumed the path afterward.

Stated claim

The authors disrupted the I2C SCL bus clock so selected motor commands were suppressed while acknowledgments kept the controller believing communication had succeeded.

Evidence status

Author reported controlled demonstration (author-reported-controlled-demonstration)

Device, firmware & configuration

Description: MD23 motor-driver/controller and real motors/encoders, FPGA communication modules and a MATLAB path controller Configuration: Hardware-in-the-loop bench emulating a differential-drive robot. Encoder measurements update a virtual trajectory; no freely navigating assembled robot or UAV was tested. Section 3.4 implements sensor VHDL for a Spartan3AN700 FPGA and separately uses post-route simulation for oscillator behavior. Exact bitstream and controller/firmware revision were not established.

Access required

Physical control of an added module on the I2C communication path.

Scope / hardware boundary

Peripheral-bus clock/protocol manipulation; no processor instruction-clock or CPU control-flow fault was demonstrated.

Dates

Published: 25 March 2017 · Reviewed: 1 November 2026 — PMC publication date and citation metadata are 25 March 2017; April is the collection month, not the experiment date.

Mechanisms

I2C bus-clock interference; Command suppression; False acknowledgment

Sources

• A Smart Sensor for Defending against Clock Glitching Attacks on the I2C Protocol in Robotic Applications ↗ (opens original source in a new tab) · Primary source · Selected sections reviewed 1 November 2026
  • Full HTML retained; relevant text and figure captions reviewed. Waveforms/figures were not independently visually inspected.

  Supports: Experimental hardware, virtual-motion boundary, command suppression, encoder results and bounded sensor-defense result.

Limitations

• Virtual trajectory reconstructed from real encoder speeds; no physical robot navigation, crash or flown drone compromise was demonstrated.
• No independent reproduction or original experiment repository reviewed.
• Earlier and later papers by the same research group do not count as independent corroboration.
• The frequency-sensor motor-stop observation is a bounded bench result; separate post-route sensor simulations do not establish fabricated-CMOS validation or a safety guarantee.
• No ATT&CK/ICS procedure mapping is asserted; the study did not establish an industrial-control intrusion.

Follow-up

Evidence confidence · 76/100

Overall rationale LRRK evidence strength for the narrowly stated claim; not severity, exploitation probability, current-device applicability, safety or an official MITRE score.

Framework mappings

• Analyst inference EMB3D TID-114 Peripheral Data Bus Interception ↗ (opens original source in a new tab)

  An inserted module manipulates messages and acknowledgments between the controller and a peripheral motor driver; the official description explicitly includes I2C.

Original record: https://pmc.ncbi.nlm.nih.gov/articles/PMC5419790/ ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

The preprint reports repeated, matching full-size external-flash reads for HS175D and HS720 and successful structural analysis of their contents. This establishes reported firmware readability on the tested units, not execution of a malicious image or flight control.

Stated claim

Holy Stone HS175D and HS720: validated external-flash acquisition under physical access

Evidence status

Original preprint hardware acquisition (original-preprint-hardware-acquisition)

Device, firmware & configuration

Vendor: Holy Stone Models: HS175D; HS720 Configuration: HS175D external XT25F128F-W flash, 16 MiB; HS720 XM25QH64C flash, 8 MiB. Paper reports extracted software structures, but not a vendor firmware release or board revision.

Access required

Class: physical-hardware/acquisition Requirements: Physical board access to external nonvolatile storage and suitable readout equipment; this is a laboratory acquisition experiment.

Scope / hardware boundary

Direct in-circuit reading of nonvolatile storage, crossing a physical firmware-confidentiality boundary.

Dates

Published: 11 May 2026 · Reviewed: 1 November 2026

Mechanisms

ROM/NVRAM Data Extraction or Modification

Sources

• A Multi-Interface Firmware Acquisition and Validation Methodology for Low-Cost Consumer Drones: A Case Study on Three Holy Stone Platforms ↗ (opens original source in a new tab) · Original preprint · Reviewed 1 November 2026

  Supports: Tables I–VI identify chips, extraction sizes, repeatability and structural checks; limitations separate dump consistency from vendor-authenticated ground truth.

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

Limitations

• Preprint prepared for submission; peer review and independent reproduction are not established.
• Exact vendor firmware version and board revision absent.
• Consistency, entropy and recognizable structures are not cryptographic authenticity or proof the entire boot chain lacks enforcement.
• Static package/CVE identification is not a demonstrated exploitable vulnerability.

Follow-up

• Resolved Were readable firmware contents distinguished from tool success? Yes: HS175D and HS720 reads had matching hashes and recognized boot/filesystem structures; HS360S was separately rejected as incomplete. source ↗ (opens original source in a new tab)
• Resolved Did the study demonstrate secure-boot bypass or flight manipulation? No. Runtime integrity, anti-rollback and other subsystems were out of scope. source ↗ (opens original source in a new tab)
• Open Are vendor-authenticated reference images available for comparison? The paper says none were available; physical readback was not independently repeated by LrrK.

Evidence confidence · 72/100

Overall rationale Original preprint supplies chips, sizes, hash consistency and validation tables; no independent replication or vendor reference image.

Framework mappings

• Analyst inference EMB3D TID-108 ROM/NVRAM Data Extraction or Modification ↗ (opens original source in a new tab)

  The observed report is physical readout of external nonvolatile memory. Only the extraction portion is supported; modification is not demonstrated.

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

Bounded outcome

Tool-level reads returned nominally full-size data, but repeat hashes diverged and the retained dump lacked meaningful firmware structures. The paper classifies the HS360S extraction as incomplete despite successful size/tool checks.

Stated claim

Holy Stone HS360S: full-size SPI reads failed firmware-content validation

Evidence status

Original preprint inconclusive hardware acquisition (original-preprint-inconclusive-hardware-acquisition)

Device, firmware & configuration

Vendor: Holy Stone Models: HS360S Configuration: Macronix MX25L6433F external flash, nominal 8 MiB; unstable in-circuit reads under the paper's fixture conditions.

Access required

Class: physical-hardware/acquisition-negative-result Requirements: Physical flash access and the tested acquisition fixture; no successful functional image assumed.

Scope / hardware boundary

Negative physical acquisition/validation result that prevents promoting connection or byte count into valid firmware evidence.

Dates

Published: 11 May 2026 · Reviewed: 1 November 2026

Sources

• A Multi-Interface Firmware Acquisition and Validation Methodology for Low-Cost Consumer Drones: A Case Study on Three Holy Stone Platforms ↗ (opens original source in a new tab) · Original preprint · Reviewed 1 November 2026

  Supports: Tables II–VI and failure analysis separate full byte count from repeatable meaningful content.

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

Limitations

• This is not a successful exploit, a demonstrated protection mechanism or evidence the device cannot be read by another method.
• Paper notes contact/signal instability and ambiguity; causes are not independently resolved.
• Only approximate operator-recorded attempt counts were reported; no reliability percentage is generalized.

Follow-up

• Resolved Does the extraction tool's success flag prove a valid firmware image? No: hash and structural checks rejected the apparent HS360S success. source ↗ (opens original source in a new tab)
• Open Was the cause resolved? No. Stable independently validated readout or a vendor reference would be needed.

Evidence confidence · 68/100

Overall rationale Clearly scoped reported negative outcome, with actual chip and validation evidence; mechanism of failure unresolved.

Framework mappings

Unmapped. No specific EMB3D or ATT&CK mapping assigned; that is not evidence of no mechanism.

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

Bounded outcome

Researchers report successful readout of MCU internal flash and SRAM through SWD. They do not report malicious code installation, modified motor outputs or a runtime safety bypass.

Stated claim

Holy Stone HS175D: unprotected SWD permits internal MCU flash and SRAM reads

Evidence status

Original preprint hardware debug readout (original-preprint-hardware-debug-readout)

Device, firmware & configuration

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

Access required

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

Scope / hardware boundary

Actual privileged hardware debug readout, beyond mere boot-console discovery.

Dates

Published: 11 May 2026 · Reviewed: 1 November 2026

Mechanisms

Firmware/Data Extraction via Hardware Interface

Sources

• A Multi-Interface Firmware Acquisition and Validation Methodology for Low-Cost Consumer Drones: A Case Study on Three Holy Stone Platforms ↗ (opens original source in a new tab) · Original preprint · Reviewed 1 November 2026

  Supports: Section IV-E and Table VI state SWD access, no readout protection and flash/SRAM readability.

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

Limitations

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

Follow-up

• Resolved Was SWD success actually reported rather than inferred from pads? Yes: the paper explicitly reports a successful connection with internal flash/SRAM reads. source ↗ (opens original source in a new tab)
• Resolved Does UART visibility establish the same capability on other units? No: HS720 is reported only as boot-log output; other-model debug access was not evaluated. source ↗ (opens original source in a new tab)

Evidence confidence · 66/100

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

Framework mappings

• Analyst inference EMB3D TID-115 Firmware/Data Extraction via Hardware Interface ↗ (opens original source in a new tab)

  Unprotected SWD readout directly matches firmware/data extraction through a hardware debug interface. No code-write outcome is implied.

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

Bounded outcome

The company publicly describes lack of proper firmware-signature verification, low-entropy Wi-Fi authentication and a BusyBox-related path affecting a debug flag. This row records those attributed public findings without endorsing the claimed total of more than 130 flaws.

Stated claim

Alias Robotics DJI Mavic Pro: publicly reported firmware-verification and debug-access weaknesses

Evidence status

Researcher case study limited public detail (researcher-case-study-limited-public-detail)

Device, firmware & configuration

Vendor: DJI Models: Mavic Pro Configuration: Public commercial case study discloses six findings from a broader claimed private assessment; exact tested firmware absent.

Access required

Class: reported-embedded-firmware Requirements: Varies by finding. Public case discusses firmware installation/downgrade and a service path affecting a debug flag; precise full-chain prerequisites not established here.

Scope / hardware boundary

Embedded update/debug privilege boundaries, not proof a publicly accessible boot port already gives root.

Dates

Published: Not stated · Reviewed: 1 November 2026

Mechanisms

Faulty FW/SW Update Integrity Verification

Sources

• Case Study - DJI ↗ (opens original source in a new tab) · Original commercial research summary · Reviewed 1 November 2026

  Supports: Six public finding descriptions; no private vulnerability archive retrieved.

Limitations

• No source date or exact affected revision verified.
• No independent reproduction or vendor acknowledgement inspected.
• Do not treat the company's claimed aggregate vulnerability count as individually verified cases.
• Publicly described signature-check weakness does not establish a current unsigned-image installation result on every Mavic Pro.

Follow-up

• Resolved Are all claimed private findings inspectable? No: only the six public descriptions were used; private archive was neither accessed nor requested. source ↗ (opens original source in a new tab)
• Open Which exact version and corrected release apply? Unresolved; obtain an authoritative public advisory or version-pinned original record.

Evidence confidence · 46/100

Overall rationale Original public summary with plausible mechanisms, but dates, exact firmware and full validation artifacts missing.

Framework mappings

• Analyst inference EMB3D TID-213 Faulty FW/SW Update Integrity Verification ↗ (opens original source in a new tab)

  Analyst semantic reference to the publicly alleged firmware-signature verification weakness; this is not independent confirmation it was exploitable on a pinned build.

Original record: https://aliasrobotics.com/case-studies/case-study-pentesting-dji.php ↗ (opens original source in a new tab) · Share: link to this record

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

• gururaj-s.github.io ↗ (opens original source in a new tab) · Primary research paper · Reviewed 1 November 2026
• GPUHammer ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026
• Security Notice: Rowhammer - July 2025 | NVIDIA ↗ (opens original source in a new tab) · Vendor security advisory · Reviewed 1 November 2026
• GitHub - sith-lab/gpuhammer · GitHub ↗ (opens original source in a new tab) · Author artifact repository · Reviewed 1 November 2026

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

Evidence confidence · 92/100

Framework mappings

• Analyst inference EMB3D TID-110 Hardware Fault Injection – Data Manipulation ↗ (opens original source in a new tab)

  Mechanism-level analyst cross-reference; this case is not asserted to be named by EMB3D.

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

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

• gddr.fail ↗ (opens original source in a new tab) · Primary research paper · Reviewed 1 November 2026
• GPU Memory Exploits ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026
• GitHub - stefan1wan/GeForge · GitHub ↗ (opens original source in a new tab) · Author artifact repository · Reviewed 1 November 2026

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

Evidence confidence · 89/100

Framework mappings

• Analyst inference EMB3D TID-110 Hardware Fault Injection – Data Manipulation ↗ (opens original source in a new tab)

  Mechanism-level analyst cross-reference; this case is not asserted to be named by EMB3D.

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

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

• users.ece.cmu.edu ↗ (opens original source in a new tab) · Primary research paper · Reviewed 1 November 2026

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

Evidence confidence · 88/100

Framework mappings

• Analyst inference EMB3D TID-110 Hardware Fault Injection – Data Manipulation ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

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

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

• gddr.fail ↗ (opens original source in a new tab) · Primary research paper · Reviewed 1 November 2026
• GPU Memory Exploits ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026
• GitHub - heelsec/GDDRHammer: GDDRHammer: Greatly Disturbing DRAM Rows — Cross-Component Rowhammer Attacks from Modern GPUs · GitHub ↗ (opens original source in a new tab) · Author artifact repository · Reviewed 1 November 2026

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

Evidence confidence · 87/100

Framework mappings

• Analyst inference EMB3D TID-110 Hardware Fault Injection – Data Manipulation ↗ (opens original source in a new tab)

  Mechanism-level analyst cross-reference; this case is not asserted to be named by EMB3D.

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

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

• plundervolt.com ↗ (opens original source in a new tab) · Primary research paper · Reviewed 1 November 2026
• Plundervolt ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026
• GitHub - KitMurdock/plundervolt · GitHub ↗ (opens original source in a new tab) · Author artifact repository · Reviewed 1 November 2026

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

Evidence confidence · 86/100

Framework mappings

• Analyst inference EMB3D TID-110 Hardware Fault Injection – Data Manipulation ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

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

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

• www.usenix.org ↗ (opens original source in a new tab) · Primary research paper · Reviewed 1 November 2026

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

Evidence confidence · 80/100

Framework mappings

• Analyst inference EMB3D TID-110 Hardware Fault Injection – Data Manipulation ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

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

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

• Blacksmith – Computer Security Group ↗ (opens original source in a new tab) · Original author research page · Reviewed 1 November 2026
  • The author page's broad headline is narrowed to its measured test pool; it is the same team/study, not independent corroboration.

  Supports: Connects the supplied secondary lead to the original study, disclosure date, paper and code; reports test pool and mitigation discussion.

• Blacksmith: Scalable Rowhammering in the Frequency Domain ↗ (opens original source in a new tab) · Primary author paper · Partially read 1 November 2026
  • Parser reports 16 of 19 PDF pages. Core methods/results and appendix test-pool text were returned; a complete 19-page review is not claimed.
  • The section's conditional exploitability language is not promoted to completed attacks on every test-pool device.

  Supports: Hardware setup, DDR4 and LPDDR4X results, section V-C exploitability analysis, limitations and test-pool appendix content inspected.

• GitHub - comsec-group/blacksmith: Next-gen Rowhammer fuzzer that uses non-uniform, frequency-based patterns (IEEE S&P '22). · GitHub ↗ (opens original source in a new tab) · Original research repository · Reviewed 1 November 2026
  • README inspection only; no dependency installation, source audit, compilation or memory-fault execution.

  Supports: README confirms study/tool identity, tested Ubuntu/kernel environment and Coffee Lake mapping assumption.

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

Evidence confidence · 79/100

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

• Analyst inference EMB3D TID-110 Hardware Fault Injection – Data Manipulation ↗ (opens original source in a new tab)

  The pinned official page links the 2021 Ars article; that article resolves to this Blacksmith study. The mechanism-level mapping is explicit analyst inference, without claiming MITRE directly reviewed this case.

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

Bounded outcome

SYSS-2025-033 reports recovery of the sample firmware. The detailed blog separately says its conventional bootloader voltage-glitch attempts did not work on the tested STM32L051 setup. Failed erase-suppression attempts can destroy the data sought.

Stated claim

The author reports reducing readout protection while suppressing the associated flash erase, then reading the retained test firmware.

Evidence status

Original author demonstration and advisory (original-author-demonstration-and-advisory)

Device, firmware & configuration

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

Access required

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

Scope / hardware boundary

Voltage perturbation during a protection-downgrade/erase operation on a laboratory MCU. No clock-glitch, deployed flight-controller, robot or customer-secret extraction result is established.

Dates

Published: 23 May 2025 · Event: 4 April 2025 · Reviewed: 1 November 2026 — Advisory reports discovery 2025-04-04, vendor notification 2025-04-07 and public disclosure 2025-05-23. Detailed blog is dated 2025-06-06. These are source-reported dates, not LRRK experiments.

Mechanisms

voltage fault injection; flash-erase suppression

Sources

• www.syss.de ↗ (opens original source in a new tab) · Original research advisory · Reviewed 1 November 2026
  • The PGP-signed-text wrapper was observed, but its signature was not independently verified. No personal contact/key fields are copied into the record.

  Supports: Exact tested K8 part, LED test program, bounded recovery claim and disclosure timeline.

• STM32L05 Voltage Glitching | SySS Tech Blog ↗ (opens original source in a new tab) · Original author technical report · Reviewed 1 November 2026

  Supports: Distinguishes unsuccessful bootloader attempts from the successful erase-suppression method and describes data-loss failure modes.

• fault-injection-library/projects/stm32l05x at master · MKesenheimer/fault-injection-library · GitHub ↗ (opens original source in a new tab) · Author linked source artifact · Reviewed 1 November 2026
  • Availability is not independent reproduction. Code/binaries were not executed or copied.

  Supports: Linked STM32L05x project exists; current project metadata includes later double-fault improvements.

• stm32-test-programs/rdp-downgrade at master · MKesenheimer/stm32-test-programs · GitHub ↗ (opens original source in a new tab) · Author linked source artifact · Reviewed 1 November 2026
  • Same author as the blog/advisory and PicoGlitcher project; not independent corroboration.

  Supports: Linked downgrade test-program project exists.

• Unlock the Door to my Secrets, but don't Forget to Glitch ↗ (opens original source in a new tab) · Peer reviewed research method follow up · Partially read 1 November 2026
  • All 42 PDF pages were returned. Review focused on target tables, methodology, voltage/EMFI results and limitations; implementation details were not reproduced.
  • The study does not list STM32L051 and does not independently reproduce this exact K8 result.

  Supports: Earlier flash-erase-suppression study supports the attack-class context and method-dependent positive/negative results on different parts.

Limitations

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

Follow-up

Evidence confidence · 78/100

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

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  A voltage fault defeats a hardware-enforced readout decision/critical erase operation. The precise physical fault model is not independently verified as instruction skipping.

• Analyst inference EMB3D TID-115 Firmware/Data Extraction via Hardware Interface ↗ (opens original source in a new tab)

  After the reported downgrade, retained test firmware is read through a physical debug interface.

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

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

• GPUThor: Amplifying Rowhammer Attacks via Non-Uniform Patterns to Exploit ECC-Protected GPUs ↗ (opens original source in a new tab) · Preprint targeted body passages · Partially read 1 November 2026
  • Firecrawl canonical paper metadata plus six targeted in-body passages
• Security Notice: Rowhammer - July 2025 | NVIDIA ↗ (opens original source in a new tab) · Vendor security advisory · Reviewed 1 November 2026

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

Evidence confidence · 78/100

Framework mappings

• Analyst inference EMB3D TID-110 Hardware Fault Injection – Data Manipulation ↗ (opens original source in a new tab)

  Mechanism-level analyst cross-reference; this case is not asserted to be named by EMB3D.

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

Bounded outcome

Cases 1, 3 and 4 are reported to have similar pre/post-silicon effects; case 2 differs in register values and program-counter behavior. One instruction-skip path raises an illegal-instruction flag and depends on exception handling, while other reported corruption cases lack that flag.

Stated claim

The authors report instruction skips and register-data corruption under clock faults, and physically validate selected pre-silicon fault cases on the FPGA core.

Evidence status

Author reported controlled demonstration (author-reported-controlled-demonstration)

Device, firmware & configuration

Description: cv32e40x RISC-V soft core deployed on a SAKURA-X Xilinx Kintex-7 XC7K160T FPGA Configuration: Vivado 2020.2 pre-silicon/netlist experiments and a separate instrumented physical FPGA implementation running an embedded MNIST inference workload. Internal clock-generation and trigger instrumentation were part of the research setup; exact core commit/bitstream was not established.

Access required

Control of laboratory clock-generation/trigger instrumentation in the FPGA implementation; not a demonstrated remote vector on a deployed device.

Scope / hardware boundary

Physical FPGA clock faults plus separately labeled simulation; no manufactured RISC-V ASIC, production robot, drone or measured flight/control takeover.

Dates

Published: 18 October 2025 · Reviewed: 1 November 2026 — ACM publication history: 18 October 2025, HASP 2025. arXiv v1: 5 March 2025; reviewed latest displayed v4: 22 October 2025. No withdrawal displayed in the retained canonical record.

Mechanisms

Processor clock fault injection; Instruction skip; Register-data corruption

Sources

• CRAFT, HASP 2025, DOI 10.1145/3768725.3768726 ↗ (opens original source in a new tab) · Primary source · Selected sections reviewed 1 November 2026
  • Full publisher HTML retained; relevant methods/results and textual figure/table descriptions reviewed, not independent visual waveform measurement.

  Supports: Published-workshop metadata, exact core/FPGA names, physical setup and bounded validation results.

• CRAFT, arXiv:2503.03877v4 ↗ (opens original source in a new tab) · Primary source · Selected sections reviewed 1 November 2026
  • Full HTML retained. Some mathematical text duplicates characters in extraction; core/FPGA names were cross-checked against publisher HTML.
  • This is the same author study, not independent replication.

  Supports: Latest displayed author version, case-by-case pre/post-silicon differences and explicit drawing/measurement caveat.

• Canonical arXiv version history ↗ (opens original source in a new tab) · Primary source · Selected sections reviewed 1 November 2026

  Supports: Submission and version dates.

Limitations

• An FPGA implementation is physical hardware, but is not a fabricated RISC-V ASIC or a fielded robot controller.
• Case 2 does not match between simulation and FPGA; do not describe all simulated faults as physically reproduced.
• The Figure 7 glitched-clock depiction in v4 is hand drawn because the logic analyzer could not resolve that clock shape; it is not an independently measured waveform.
• The instruction-skip example involves exception-handling behavior; no secure-boot/authentication bypass is established by this case.
• Simulation search-space reduction is not a measured physical success rate.
• No independent reproduction, exact implementation pin or deployed-system exploit reviewed.
• No ATT&CK/ICS technique or memory-disturbance/Rowhammer mapping is inferred from register corruption alone.

Follow-up

Evidence confidence · 77/100

Overall rationale LRRK evidence strength for the narrowly stated claim; not severity, exploitation probability, current-device applicability, safety or an official MITRE score.

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  Physical clock faults changed intended instruction execution in the FPGA core; mapping does not imply a tested security-check bypass or applicability to a deployed controller.

Original record: https://dl.acm.org/doi/10.1145/3768725.3768726 ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

Authors demonstrate that coordinated multiple faults can undermine the tested protections and expose secure memory from nonsecure execution.

Stated claim

µ-Glitch multiple-fault demonstrations against TrustZone-M protections

Evidence status

Published research demonstration (published_research_demonstration)

Device, firmware & configuration

Description: NXP LPC55SXX / RT6XX, STM32L5 and Atmel SAML11 families evaluated in the paper Configuration: Four tested TrustZone-M chip families with different fault defenses; exact board and firmware revisions require consultation of the paper before transfer.

Access required

Physical voltage-fault laboratory access plus target instrumentation; no flight-system authorization is implied.

Scope / hardware boundary

Four tested TrustZone-M chip families with different fault defenses; exact board and firmware revisions require consultation of the paper before transfer.

Dates

Published: August 2023 · Reviewed: 1 November 2026 — Publication date precision: month.

Mechanisms

Hardware Fault Injection – Control Flow Modification

Sources

• www.usenix.org ↗ (opens original source in a new tab) · Primary research paper · Reviewed 1 November 2026

Limitations

• A targeted multi-fault research result, not a guarantee of compromise across all revisions.
• The paper's NXP acknowledgement is author-reported; a separate current vendor fix was not verified.
• A targeted artifact search did not establish a unique public µ-Glitch release.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 77/100

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

Original record: https://www.usenix.org/system/files/usenixsecurity23-sass.pdf ↗ (opens original source in a new tab) · Share: link to this record

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

Evidence confidence · 74/100

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

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  The reported voltage fault changes the boot processor's security-control execution and enables an otherwise disabled boot path.

• Analyst inference EMB3D TID-116 Latent Privileged Access Port ↗ (opens original source in a new tab)

  The reported privileged UART bootloader is a latent manufacturer access path whose availability is changed by the fault.

• Analyst inference EMB3D TID-115 Firmware/Data Extraction via Hardware Interface ↗ (opens original source in a new tab)

  The reported enabled bootloader permits firmware/data readout through a physical interface.

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

Bounded outcome

Authors report escapes from controlled branch/loop workloads and configuration-dependent defense results. Neither a drone nor robot compromise nor universal immunity from fault injection was established.

Stated claim

The DSN2021 study reports real clock-induced control-flow faults on a named STM32 test target and evaluates software defense patterns, separately from its instruction-set emulation.

Evidence status

Author reported controlled demonstration (author-reported-controlled-demonstration)

Device, firmware & configuration

Description: STM32F071RBT6 Cortex-M0 in clock-fault experiments; Nucleo64 STM32F303RE in a separate defense-overhead exercise Configuration: The attack experiments deliberately use test-equipment-driven clocking and a precisely instrumented trigger on synthetic branch/loop workloads. These are explicitly ideal attacker conditions, not a production drone/robot firmware test.

Access required

Physical laboratory control over a target clock and instrumented execution; generic embedded benchmark access.

Scope / hardware boundary

Physical clock manipulation on an instrumented MCU benchmark; no operational aircraft/robot applicability established.

Dates

Published: 2021 · Reviewed: 1 November 2026 — IEEE publication year2021; author repository view shows latest commit03fe4fb dated2020-01-31. Review date is not an experiment date.

Mechanisms

Clock glitching; Control-flow disturbance; Compiler/software fault-injection defenses

Sources

• Glitching Demystified, complete author-hosted DSN2021 paper ↗ (opens original source in a new tab) · Primary source · Reviewed 1 November 2026
  • Some PDF table extraction is damaged; no precise table-derived success-rate claim is adopted.

  Supports: Physical target, ideal attacker assumptions, distinction from emulation, and defense evaluation.

• IEEE Computer Society DSN2021 publication record ↗ (opens original source in a new tab) · Primary source · Reviewed 1 November 2026

  Supports: Bibliographic identity: 2021, pages400–412, DOI10.1109/DSN48987.2021.00051.

• Authors' GLITCHRESISTOR repository ↗ (opens original source in a new tab) · Primary source · Reviewed 1 November 2026

  Supports: Public code/tree and README observed at03fe4fb8cced4c00b27357ca8faba085fa5b0841; neither built nor executed in this review.

Limitations

• Idealized attacker clock/trigger control and synthetic code; no sealed product or aircraft was tested.
• Internal-clock devices and other fault mechanisms are not equivalent to the experimental setup.
• The M4 overhead board must not be substituted for the M0 attack target.
• No independent hardware reproduction or LrrK bench experiment was performed.
• Avoid transferring numerical rates from damaged extracted tables or applying a benchmark success rate to arbitrary firmware.

Follow-up

Evidence confidence · 74/100

Overall rationale Confidence in this bounded evidence claim; not probability, severity, device applicability or a MITRE rating.

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  The study's physical clock faults change intended execution/control flow; clock-glitch protection is also referenced through CWE-1247 on the official threat page.

Original record: https://gzs715.github.io/pubs/GLITCHING_DSN21.pdf ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

Experiments show changes to instruction behavior and Flash-loaded data, supporting a constrained fault model rather than a universal instruction-skip assumption.

Stated claim

Electromagnetic fault-model study of a 32-bit Cortex-M3 microcontroller

Evidence status

Published research demonstration (published_research_demonstration)

Device, firmware & configuration

Description: 130nm Arm Cortex-M3 microcontroller; exact commercial part not disclosed in the inspected passage Configuration: Cacheless 32-bit research target with basic clock/voltage protections; original paper version mirrored as arXiv1402.6421.

Access required

Close physical electromagnetic injection and observation access in a laboratory.

Scope / hardware boundary

Cacheless 32-bit research target with basic clock/voltage protections; original paper version mirrored as arXiv1402.6421.

Dates

Published: 2013 · Reviewed: 1 November 2026 — Publication date precision: year.

Mechanisms

Hardware Fault Injection – Control Flow Modification

Sources

• Electromagnetic fault injection: towards a fault model on a 32-bit microcontroller ↗ (opens original source in a new tab) · Primary research paper · Reviewed 1 November 2026

Limitations

• Physical setup and target architecture determine the induced fault.
• The source does not establish an end-to-end drone compromise.
• The original2013 publication and2014 arXiv deposit are versions of one study.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 73/100

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

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

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

• Exploiting the DRAM rowhammer bug to gain kernel privileges - Project Zero ↗ (opens original source in a new tab) · Original researcher institutional report · Reviewed 1 November 2026
  • Exact exploited device/model/kernel revisions remain undisclosed in the inspected account; no execution by LrrK.

  Supports: Original mechanism, two reported exploits, 29-row results table, negative-test caution and mitigation discussion inspected.

• GitHub - google/rowhammer-test: Test DRAM for bit flips caused by the rowhammer problem · GitHub ↗ (opens original source in a new tab) · Original research repository · Reviewed 1 November 2026
  • Repository/README inspection only, not an audit, execution or independent reproduction.

  Supports: The linked public rowhammer-test repository exists and its README identifies the memory disturbance test artifact.

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

Evidence confidence · 72/100

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

• Analyst inference EMB3D TID-110 Hardware Fault Injection – Data Manipulation ↗ (opens original source in a new tab)

  The reported software-induced hardware disturbance and memory corruption fit TID-110. The official page cites the later retrospective, while this original 2015 case is an analyst-resolved historical reference.

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

Bounded outcome

Slides report recovery of the complete application partition in their target, while also stating that early boot-region bytes are missed by the current collection startup delay. Repository describes target-program-specific analysis and incomplete/ambiguous ranges when capture data is insufficient.

Stated claim

Authors report reconstructing protected application bytes by analyzing debug-visible execution states of the target's integrity calculation.

Evidence status

Original author presentation and analysis artifact (original-author-presentation-and-analysis-artifact)

Device, firmware & configuration

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

Access required

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

Scope / hardware boundary

Debug-interface information leakage and target-specific program analysis. Clock jitter is an observation problem/future-work topic, not a demonstrated clock-injection attack.

Dates

Published: 2025 · Reviewed: 1 November 2026 — Original authors identify Hardwear.io USA 2025 as the presentation. PDF v1.1 contains a 6/10/2025 footer whose date formatting was not resolved. The inspected analysis repository has a public-release commit dated 2026-03-27. Upload-path dates are not experiment dates.

Mechanisms

hardware debug processor-state observation; target-specific integrity-calculation data recovery

Sources

• community.penthertz.com ↗ (opens original source in a new tab) · Public community discussion · Reviewed 1 November 2026
  • Secondary synthesis and speculative dongle mechanisms are not independent demonstrations.

  Supports: Discovery and follow-up assertions; complete six-post public topic read. Its broad flash-recovery wording is checked against original sources.

• GitHub - Marcus-Engineering/tracerip-analysis: Analysis code from "Tracing the Untraceable: Extracting Protected Flash with STM32-TraceRip". · GitHub ↗ (opens original source in a new tab) · Original author analysis repository · Reviewed 1 November 2026

  Supports: Target-dependent recovery model, analysis-only release, insufficient-data limitations and original presentation links.

• TraceRip-STM32 ↗ (opens original source in a new tab) · Original author conference slides · Partially read 1 November 2026
  • All 95 PDF pages were returned. Review focused on target architecture, prior-method failures, result and limitation slides, including pages 84–95; this is not independent validation of every implementation/figure.
  • The old 2025 presentation-path URL returned 404. This current URL was explicitly linked by the original repository; it is not an independent source.

  Supports: Architecture/prerequisites, unsuccessful earlier methods, application-partition result and missed early bytes.

• Home | Mark Omo ↗ (opens original source in a new tab) · Original author project index · Reviewed 1 November 2026

  Supports: Independent URL route from the author confirms the presentation's current location; not independent technical reproduction.

Limitations

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

Follow-up

Evidence confidence · 69/100

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

Framework mappings

• Analyst inference EMB3D TID-115 Firmware/Data Extraction via Hardware Interface ↗ (opens original source in a new tab)

  The bounded report concerns firmware/data extraction through a hardware debug interface, using permitted processor-state observations rather than direct flash reads.

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

Bounded outcome

Author-narrated development-board ROM readout. The transcript describes newly readable non-placeholder content and a saved dump after the fault. This review did not watch every video frame, inspect the dump, verify its contents or reproduce the electrical result.

Stated claim

The presenter reports using voltage fault injection on a Tegra X1/T210 development board to prevent the protected boot-ROM region from becoming unreadable to later code, then reading and saving previously protected ROM content.

Evidence status

Author reported hardware result in recording transcript (author_reported_hardware_result_in_recording_transcript)

Device, firmware & configuration

Processor: NVIDIA Tegra X1 / T210 Platform: Development module and carrier board; exact commercial development-kit model and board revision not established by the reviewed transcript. Security configuration: Development-board boot flow already permits unsigned custom user code; the presenter explicitly distinguishes this from the retail Nintendo Switch boot flow. Firmware: Exact bootloader/board build and protected-ROM binary version not established. Not established: Physical voltage glitch demonstrated on a retail Nintendo Switch; Applicability to later Tegra revisions, flight controllers, drones or robots

Access required

Local physical/electrical access to the development board for voltage fault injection, plus the development configuration's existing ability to run custom code and inspect memory. No remote-only path is claimed.

Scope / hardware boundary

A boot-time hardware/firmware read-protection transition on the stated development board, despite user code already being allowed to execute.

Dates

Published: 28 June 2018 · Reviewed: 1 November 2026 — The canonical CCC recording is dated 2018-06-28. Exact dates of the narrated laboratory experiments are not established. The public YouTube mirror was uploaded 2022-04-02; that upload is not a new experiment.

Mechanisms

voltage fault injection; boot-ROM read-protection bypass as reported by the presenter

Sources

• Glitching the Switch ↗ (opens original source in a new tab) · Original conference record · Metadata and abstract reviewed; prior capture reused 1 November 2026
  • Original event page is not a transcript. No original-media checksum comparison with the mirror was performed.

  Supports: Original title, named speaker Andreas Galauner, date, rounded 92-minute duration and abstract; canonical identity used to attribute the mirrored talk.

• Glitching the Switch - CCC ↗ (opens original source in a new tab) · Public recording mirror · Targeted transcript sections; no full audiovisual review 1 November 2026
  • Uploaded by Gereon on 2022-04-02, not the original conference publisher. Automatic transcription has errors; speaker identity is attributed through the linked event rather than biometric or byte-for-byte verification. No frame/output/binary validation.

  Supports: Mirror explicitly links the exact CCC event. Its 1:32:40 duration is consistent with CCC's rounded 92 minutes. Transcript distinguishes T210 development-board voltage fault/readout from a separate retail-console USB recovery exploit discussion.

• TID-105: Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab) · Official framework case reference · Official threat and case-evidence sections reviewed 1 November 2026
  • A framework citation is curated support, not independent reproduction or endorsement of this record, score or retail-console applicability.

  Supports: MITRE's evidence section explicitly links this exact CCC event and describes Tegra X1 power glitching to avoid enabling ROM readout protection.

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-FI-004.

Limitations

• Transcript-based review of relevant sections, with automatic-transcription and mirror-provenance limitations; not a full audiovisual watch.
• An already permissive development-board code-execution environment is a material prerequisite; this is not evidence of a retail Switch voltage-glitch bypass.
• No physical or numerical result was independently reproduced. No raw ROM or operational glitch parameters are retained.
• The separate USB software exploit and later Tegra X2 study must not be counted as confirmations of this physical experiment.
• This result does not establish an effect on a drone, robot or LRRK-owned device.

Follow-up

Evidence confidence · 67/100

Overall rationale Confidence in the narrowly attributed evidence claim, not probability, severity, device applicability or an official MITRE rating.

Framework mappings

• Direct official reference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  The official TID-105 evidence section explicitly links the same canonical CCC event and describes its Tegra X1 power-glitch/readout-protection result. The development-board scope is preserved from the reviewed recording transcript; MITRE does not validate this record's score or a retail-console generalization.

Original record: https://media.ccc.de/v/c4.openchaos.2018.06.glitching-the-switch ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

Original research describes boot-image replacement and protected-boot bypass; Siemens confirms the hardware root-of-trust issue and identifies newer fixed hardware for selected CPU types.

Stated claim

Siemens S7-1500 immutable-root-of-trust weakness and hardware revisions

Evidence status

Published research demonstration (published_research_demonstration)

Device, firmware & configuration

Description: Affected Siemens SIMATIC/SIPLUS S7-1500 CPU product variants Configuration: CVE-2022-38773. Vendor SSA-482757 V1.5, updated 2025-01-14, enumerates product-specific affected versions and replacement hardware.

Access required

Physical tampering with affected PLC hardware and storage/peripheral trust paths.

Scope / hardware boundary

CVE-2022-38773. Vendor SSA-482757 V1.5, updated 2025-01-14, enumerates product-specific affected versions and replacement hardware.

Dates

Published: 10 January 2023 · Reviewed: 1 November 2026 — Publication date precision: day.

Mechanisms

ROM/NVRAM Data Extraction or Modification; Peripheral Data Bus Interception

Sources

• Siemens SIMATIC S7-1500 Boot Bypass Vulnerabilities ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026
• SSA-482757_V1.5 ↗ (opens original source in a new tab) · Vendor security advisory · Reviewed 1 November 2026
• Modify Firmware: System Firmware, Sub-technique T1693.001 - ICS | MITRE ATT&CK® ↗ (opens original source in a new tab) · Official taxonomy · Reviewed 1 November 2026

Limitations

• Affected product lists are not interchangeable with the entire S7-1500 family.
• Hardware replacement/fix availability is product-specific; a firmware-only repair should not be assumed.
• No evidence of field exploitation is established by this research.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 91/100

Framework mappings

• Analyst inference EMB3D TID-108 ROM/NVRAM Data Extraction or Modification ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

• Analyst inference EMB3D TID-114 Peripheral Data Bus Interception ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

• Analyst inference ATT&CK ICS T1693.001 Modify Firmware: System Firmware ↗ (opens original source in a new tab)

  The documented PLC boot-image modification is consistent with the technique definition; MITRE is not asserted to name this specific laboratory case.

Original record: https://redballoonsecurity.com/siemens-discovery/ ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

Authors demonstrate volatile-memory extraction and reconstruction from the selected PLC, enabling inspection of runtime content.

Stated claim

Cryo-mechanical extraction from a Siemens S7-1511 PLC

Evidence status

Published research demonstration (published_research_demonstration)

Device, firmware & configuration

Description: Siemens S7-1511-1 PN CPU module 6ES7511-1AK02-0AB0 Configuration: Custom embedded memory layout with LPDDR1 / DDR2 handling in the study; FPGA readout and a dedicated cryo-mechanical apparatus.

Access required

Invasive physical memory-chip handling and specialized laboratory equipment; prior device code execution is not required for the demonstrated approach.

Scope / hardware boundary

Custom embedded memory layout with LPDDR1 / DDR2 handling in the study; FPGA readout and a dedicated cryo-mechanical apparatus.

Dates

Published: 2023 · Reviewed: 1 November 2026 — Publication date precision: year.

Mechanisms

RAM Chip Contents Readout

Sources

• wootconference.org ↗ (opens original source in a new tab) · Primary research paper · Reviewed 1 November 2026

Limitations

• The paper discusses drones as possible external-DRAM environments; it does not demonstrate extraction from every quadcopter.
• CiscoDDR3 work is described as preliminary; DDR4/DDR5 transfer is a research expectation, not a completed result.
• Hardware manipulation can be destructive and is not authorized by a library entry.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 84/100

Framework mappings

• Analyst inference EMB3D TID-109 RAM Chip Contents Readout ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

Original record: https://wootconference.org/papers/woot23-paper3.pdf ↗ (opens original source in a new tab) · Share: link to this record

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

• Memory Lane - Direct Memory Access Attacks | Eclypsium ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026

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

Evidence confidence · 82/100

Framework mappings

• Analyst inference EMB3D TID-107 Unauthorized Direct Memory Access (DMA) ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

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

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

• eclypsium.com ↗ (opens original source in a new tab) · Primary research paper · Reviewed 1 November 2026
• Eclypsium and NVIDIA Collaborate to Address Emerging AI Infrastructure Attack Surface and Strengthen AI Trust ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026

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

Evidence confidence · 81/100

Framework mappings

• Analyst inference EMB3D TID-107 Unauthorized Direct Memory Access (DMA) ↗ (opens original source in a new tab)

  Mechanism-level analyst cross-reference; this case is not asserted to be named by EMB3D.

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

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

• IOMMU protection against I/O attacks: a vulnerability and a proof of concept | Journal of the Brazilian Computer Society | Springer Nature Link ↗ (opens original source in a new tab) · Primary open access research article · Reviewed 1 November 2026
  • The original 2010 IEEE methods remained inaccessible. The 2018 paper describes that older work in related work, which does not replace reading the 2010 original.

  Supports: Full accessible article identity, target configuration, assumptions, separate simulation/FPGA implementations, reported outcome and limitations inspected.

• [AC] Actes de colloques Conference proceedings (102) ↗ (opens original source in a new tab) · Original 2010 author bibliography · Reviewed 1 November 2026
  • Bibliography only; not original 2010 methods or configuration.

  Supports: Confirms identity and conference metadata of the separate unresolved 2010 lead.

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

Evidence confidence · 78/100

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

• Analyst inference EMB3D TID-107 Unauthorized Direct Memory Access (DMA) ↗ (opens original source in a new tab)

  The measured malicious-peripheral DMA outcome fits TID-107. MITRE directly cites the separate 2010 paper; this 2018 case is explicitly a supplemental analyst inference.

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

Bounded outcome

Kaspersky reports recovered modules capable of replacing drive firmware and accessing hidden storage; this supports a reported adversarial capability, not a claim that every listed drive was observed infected.

Stated claim

Equation hard-drive firmware-reprogramming modules

Evidence status

Malware analysis report (malware_analysis_report)

Device, firmware & configuration

Description: HDD firmware targeted by recovered EquationDrug/GrayFish modules; supported manufacturers vary Configuration: Kaspersky report V1.5 identifies firmware-reprogramming modules 3.0.1 and 4.2.0; PE compilation dates are explicitly uncertain.

Access required

A prior software compromise with device-specific firmware reprogramming capability; exact initial access is not established by this artifact account.

Scope / hardware boundary

Kaspersky report V1.5 identifies firmware-reprogramming modules 3.0.1 and 4.2.0; PE compilation dates are explicitly uncertain.

Dates

Published: February 2015 · Reviewed: 1 November 2026 — Publication date precision: month.

Mechanisms

Unverified Peripheral Firmware Loaded

Sources

• media.kasperskycontenthub.com ↗ (opens original source in a new tab) · Primary research paper · Partially read 1 November 2026
  • Only 30 of 44 parsed pages were read.
• Pre-OS Boot: Component Firmware, Sub-technique T1542.002 - Enterprise | MITRE ATT&CK® ↗ (opens original source in a new tab) · Official taxonomy · Reviewed 1 November 2026

Limitations

• Recovered-code capability and proven deployment on a specific drive are different claims.
• The single vendor investigation and MITRE citation are not independent physical reproduction.
• Module PE timestamps are not treated as confirmed event dates.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 78/100

Framework mappings

• Analyst inference EMB3D TID-113 Unverified Peripheral Firmware Loaded ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

• Direct official reference ATT&CK Enterprise T1542.002 Pre-OS Boot: Component Firmware ↗ (opens original source in a new tab)

  The current MITRE technique page directly lists Equation's hard-drive firmware capability and cites this Kaspersky report.

Original record: https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2018/03/08064459/Equation_group_questions_and_answers.pdf ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

Authors demonstrate remote key extraction from the tested constant-time SIKE implementation through data-dependent frequency effects.

Stated claim

Hertzbleed remote timing leakage and subsequent corrections

Evidence status

Published research demonstration (published_research_demonstration)

Device, firmware & configuration

Description: Tested Intel Core and AMD Ryzen x86 systems; original SIKE implementation Configuration: Authors tested Intel Core generations 8–11 and AMD Zen2/Zen3 families. The original SIKE target is deprecated; later work discusses other cryptography and browser contexts.

Access required

Remote timing observations against a suitable workload; no physical power probe is required for the reported remote variant.

Scope / hardware boundary

Authors tested Intel Core generations 8–11 and AMD Zen2/Zen3 families. The original SIKE target is deprecated; later work discusses other cryptography and browser contexts.

Dates

Published: 14 June 2022 · Reviewed: 1 November 2026 — Publication date precision: day.

Mechanisms

Microarchitectural Side Channels

Sources

• Hertzbleed Attack ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026
• GitHub - FPSG-UIUC/hertzbleed · GitHub ↗ (opens original source in a new tab) · Author artifact repository · Reviewed 1 November 2026

Limitations

• Frequency leakage is not equivalent to a universally exploitable library.
• SIKE's later cryptanalytic break is separate from Hertzbleed.
• The same-team follow-up and repository do not count as independent reproduction.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 78/100

Framework mappings

• Analyst inference EMB3D TID-103 Microarchitectural Side Channels ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

Original record: https://www.hertzbleed.com/ ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

Researchers demonstrate reading protected memory through transient execution; the paper evaluates KAISER page-table separation as a defense.

Stated claim

Meltdown kernel-memory disclosure demonstrations

Evidence status

Published research demonstration (published_research_demonstration)

Device, firmware & configuration

Description: Affected out-of-order processor configurations evaluated in the original Meltdown paper Configuration: Original pre-mitigation test systems; processor families and address-space-isolation defenses matter.

Access required

Local unprivileged execution on a susceptible configuration.

Scope / hardware boundary

Original pre-mitigation test systems; processor families and address-space-isolation defenses matter.

Dates

Published: 2018 · Reviewed: 1 November 2026 — Publication date precision: year.

Mechanisms

Microarchitectural Side Channels

Sources

• meltdownattack.com ↗ (opens original source in a new tab) · Primary research paper · Reviewed 1 November 2026

Limitations

• Distinct mechanism and affected set from Spectre.
• Historical demonstration; no claim that every current processor or patched system remains vulnerable.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 78/100

Framework mappings

• Analyst inference EMB3D TID-103 Microarchitectural Side Channels ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

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

Bounded outcome

The paper demonstrates recovering sensitive application behavior/data from memory-access patterns visible off chip.

Stated claim

MEMBUSTER off-chip memory-bus leakage from SGX applications

Evidence status

Published research demonstration (published_research_demonstration)

Device, firmware & configuration

Description: Intel SGX test platform including an i5-8400 and external DDR4 Configuration: Hunspell and Memcached enclaves, exposed address-bus observations; advanced experiments also use a modified SGX driver.

Access required

Physical memory-bus observation; some enhancement scenarios additionally assume privileged host control.

Scope / hardware boundary

Hunspell and Memcached enclaves, exposed address-bus observations; advanced experiments also use a modified SGX driver.

Dates

Published: 2020 · Reviewed: 1 November 2026 — Publication date precision: year.

Mechanisms

Data Bus Interception

Sources

• www.usenix.org ↗ (opens original source in a new tab) · Primary research paper · Reviewed 1 November 2026

Limitations

• This is address-pattern leakage, not automatically plaintext recovery from every encrypted bus.
• External-memory topology, application behavior and optional privileged enhancements constrain transfer.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 78/100

Framework mappings

• Analyst inference EMB3D TID-106 Data Bus Interception ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

Original record: https://www.usenix.org/system/files/sec20summer_lee-dayeol_prepub.pdf ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

The paper demonstrates a hardware platform for observing and replaying PCIe transactions in the tested setup.

Stated claim

FPGA PCIe man-in-the-middle emulator demonstration

Evidence status

Published research demonstration (published_research_demonstration)

Device, firmware & configuration

Description: Research host with PCIe3.0 and Stratix5 FPGA endpoint Configuration: Proof-of-concept emulator with protocol/timing constraints, rather than a demonstrated compromise of every smartphone interconnect.

Access required

Physical insertion/control of a specialized PCIe interposer/emulation platform.

Scope / hardware boundary

Proof-of-concept emulator with protocol/timing constraints, rather than a demonstrated compromise of every smartphone interconnect.

Dates

Published: 2020 · Reviewed: 1 November 2026 — Publication date precision: year.

Mechanisms

Peripheral Data Bus Interception

Sources

• Toward a hardware man-in-the-middle attack on PCIe bus ↗ (opens original source in a new tab) · Primary research paper · Reviewed 1 November 2026
• Toward a hardware man-in-the-middle attack on PCIe bus - Archive ouverte HAL ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026

Limitations

• Generic architectural reach and a concrete deployed-device exploit are different claims.
• HAL deposit date2022 is not the2020 publication date.
• No independent reproduction was found in the bounded source follow-up.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 78/100

Framework mappings

• Analyst inference EMB3D TID-114 Peripheral Data Bus Interception ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

Original record: https://hal.science/hal-03228978v1/file/S0141933120303653.pdf ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

The authors report recovering the complete 16-byte test key with both methods; CPA produced clearer interpretation in their comparison. The article identifies alignment and implementation knowledge as barriers when transferring the result to black-box devices.

Stated claim

DPA and CPA can recover the test AES-128 key from power leakage of the specified implementation.

Evidence status

Published research demonstration white box (published_research_demonstration_white_box)

Device, firmware & configuration

Description: Arduino Uno using an ATmega328P and author-controlled AES round-1 code Configuration: AddRoundKey and SubBytes operations implemented for the experiment; instrumented power observation with Keysight MSOX4104A. This is a white-box target with an author-controlled capture trigger, rather than a tested commercial black-box cryptographic product.

Access required

Physical power-observation instrumentation and repeated operations on an author-programmed device; the white-box trigger and known implementation are prerequisites of this demonstration.

Scope / hardware boundary

Arduino Uno/ATmega328P, the tested round-1 implementation and laboratory observability only; no arbitrary AES product, complete deployed protocol, robot or drone compromise is demonstrated.

Dates

Published: 19 September 2016 · Reviewed: 1 November 2026 — Published online 19 September 2016; the publisher PDF cites the 2017 journal issue 1(2), pages 88–107. No separate experiment date established.

Mechanisms

Power Consumption Analysis Side Channel

Sources

• Power analysis attacks on the AES-128 S-box using differential power analysis (DPA) and correlation power analysis (CPA) ↗ (opens original source in a new tab) · Author institutional repository · Reviewed 1 November 2026
  • Repository metadata/abstract only; it is the same study and not independent reproduction.

  Supports: Corroborates title, authors, DOI, publication dates and abstract claim; no attached manuscript was exposed by this repository read.

• Power analysis attacks on the AES-128 S-box using differential power analysis (DPA) and correlation ↗ (opens original source in a new tab) · Primary research paper mirrored · Partially read 1 November 2026
  • Public third-party PDF mirror; identity matched against the institutional repository and DOI. Publisher original route did not previously return substantive body.
  • Parser reports 20 of 21 PDF pages; methods, results and limitations were available, but a complete-page review is not claimed.

  Supports: Original article identity, setup, results sections 4.1–4.3 and section 6 limitations inspected.

Limitations

• No independent replication was reviewed; the repository abstract and mirror are two access routes to one study.
• The experiment implements two first-round operations and supplies capture assistance; black-box transfer was discussed rather than demonstrated.
• No circuit, firmware or production-device version beyond the source's stated platform was established.
• Partial PDF extraction is recorded rather than promoted to a complete-paper read.

Follow-up

Evidence confidence · 77/100

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

• Direct official reference EMB3D TID-101 Power Consumption Analysis Side Channel ↗ (opens original source in a new tab)

  The pinned official TID-101 page explicitly cites this exact Arduino DPA/CPA paper and its round-1 implementation.

Original record: https://doi.org/10.1080/23742917.2016.1231523 ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

The authors report restoring placed memory images after cooled cold boots using descrambling and, where required, channel deinterleaving. At operating temperature their captured data had completely decayed and no usable image was obtained. Recovery was near the original image with occasional errors, rather than evidence of arbitrary secret recovery.

Stated claim

Intel memory scrambling does not by itself rule out cold-boot recovery on the tested DDR3 configurations.

Evidence status

Published research demonstration with negative boundary (published_research_demonstration_with_negative_boundary)

Device, firmware & configuration

Description: Predominantly Intel Core i3-3225/MSI B75MA-P45; additional reported CPU/mainboard combinations Configuration: The paper also lists i5-760/MSI H55M-P33, i5-2520M/Dell 03PH4G and i5-2400/Esprimo P900 E90+. It distinguishes constant from randomized Intel memory scrambling and single/dual-channel layouts. DDR3 DIMMs are described as produced in 2013, 666/833 MHz types, without exact module part numbers in the inspected results. Reported usable trials used cooling to about −30 °C; operating-temperature trials at about +30 °C produced no usable image.

Access required

Physical RAM access and controlled cold-boot acquisition; usable recovery in this study depended on substantial cooling, retained data, address/layout information and known-plaintext/related-data assumptions.

Scope / hardware boundary

Specified older Intel DDR3 systems and the documented cooled acquisition conditions; neither DDR4 support nor uncooled DDR3 recovery was established.

Dates

Published: 2016 · Reviewed: 1 November 2026 — Author-hosted 2016 DFRWS Europe paper; no separate experiment date established.

Mechanisms

RAM Chip Contents Readout

Sources

• Lest We Forget: Cold-Boot Attacks on Scrambled DDR3 Memory ↗ (opens original source in a new tab) · Primary author paper · Reviewed 1 November 2026
  • Known-plaintext/layout assumptions apply; exact DIMM identities are not established in the inspected results.

  Supports: Ten-page author-hosted paper; investigated machines, measured recovery, negative operating-temperature result and conclusions inspected.

• coldboot-2013-paper ↗ (opens original source in a new tab) · Prior primary study · Reviewed 1 November 2026
  • Shared author and different test conditions; not an independent confirmation of the 2016 result.

  Supports: Earlier five-configuration DDR3 negative result is the comparison being qualified.

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

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

Limitations

• No current Intel platform, different memory encryption design, DDR4/DDR5 system, robot or drone is demonstrated by this paper.
• The reported software/tool link is anonymized in this author PDF; no runnable descrambling artifact was verified or executed.
• Near-complete placed-image recovery is distinct from independently extracting a live production cryptographic secret.
• Later paper and earlier evaluation share an author, so they earn no independent-reproduction points here.

Follow-up

Evidence confidence · 77/100

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

• Analyst inference EMB3D TID-109 RAM Chip Contents Readout ↗ (opens original source in a new tab)

  Physical recovery of RAM contents fits TID-109. This 2016 study is a supplemental analyst cross-reference and is not claimed to be named on the pinned MITRE page.

Original record: https://www.johannes-bauer.com/personal/publications/2016-03-Bauer-DFRWS-EU.pdf ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

DDR1/DDR2 measurements broadly reproduced earlier recovery behavior. The five DDR3 configurations retained usable contents through warm reset but yielded noise rather than placed data after the tested cold reboots, including cooled trials. This is a negative result for those methods/configurations, not proof that DDR3 cannot retain data.

Stated claim

The study tested whether previously reported cold-boot memory recovery transferred across its specified systems and memory generations.

Evidence status

Published research evaluation with negative results (published_research_evaluation_with_negative_results)

Device, firmware & configuration

Description: Seventeen non-ECC SDRAM system/configuration combinations, including five DDR3 combinations M–Q Configuration: DDR3 configurations: ASRock H77M-ITX/CMX8GX3M2A1600C9 (8192 MiB); Fujitsu ESPRIMO P900 E90+/M378B5773CHO-CK0 (2048 MiB); ASRock Z77 Pro4/HMT351U6BFR8C-H9 (4096 MiB); Asus PBP67LE/M378B5773DHO-CH9 (2048 MiB); ASRock Z77 Pro3/KHX2133C8D3T1K2/4G (4096 MiB), as transcribed by the PDF extraction. BIOS/CPU revisions for these rows are not supplied in the inspected table. The reported unsuccessful cooled DDR3 trials included cooling to about −10 °C; this temperature does not establish a universal retention threshold.

Access required

Physical access to the running system or its RAM; the paper evaluates reset, power-cycle and RAM-transplantation conditions. Cooling and boot behavior materially affect outcomes.

Scope / hardware boundary

Distinguish warm reset (successful on the five tested DDR3 configurations) from the tested power-cycle cold-reboot path (unsuccessful). Seventeen configurations do not mean seventeen distinct computer models.

Dates

Published: 2013 · Reviewed: 1 November 2026 — Conference 2–6 September 2013; IEEE indexing date 7 November 2013 is not the experiment date.

Mechanisms

RAM Chip Contents Readout

Sources

• coldboot-2013-paper ↗ (opens original source in a new tab) · Primary research paper mirrored · Reviewed 1 November 2026
  • Public mirror, with identity matched to the previously reviewed IEEE bibliographic record. Model strings above retain extraction uncertainty.

  Supports: Eight-page authored study; table I configuration set, reset/cold-reboot results and cautious conclusion inspected.

• Lest We Forget: Cold-Boot Attacks on Scrambled DDR3 Memory ↗ (opens original source in a new tab) · Primary author followup · Reviewed 1 November 2026
  • This later paper shares author Michael Gruhn with the 2013 study and uses different configurations/conditions. It is not an independent reproduction of the same five failures.

  Supports: Later authors demonstrate that Intel DDR3 scrambling and remanence require a more specific explanation; it limits any universal reading of the 2013 negative result.

Shared source; these records are not independent experiments. Shared with LRRK-20261101-PRI-003.

Shared source; these records are not independent experiments. Shared with LRRK-20261101-PRI-003.

Limitations

• The original explanation of DDR3 noise was uncertain; later work demonstrates usable cold-boot recovery on particular scrambled DDR3 systems.
• No secret-key extraction or modern embedded/drone applicability follows from these placed-data measurements alone.
• The mirror's extracted hardware spelling is not an independent board-identity verification.
• A failed cold-reboot test and a successful warm-reset read are separate observations.

Follow-up

Evidence confidence · 76/100

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

• Direct official reference EMB3D TID-109 RAM Chip Contents Readout ↗ (opens original source in a new tab)

  The official TID-109 cold-boot evidence quotes this 2013 study's DDR1/DDR2 evaluation. The five DDR3 negatives are retained from the original paper.

Original record: https://doi.org/10.1109/ARES.2013.52 ↗ (opens original source in a new tab) · Share: link to this record

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

• Memory Lane - Direct Memory Access Attacks | Eclypsium ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026

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

Evidence confidence · 76/100

Framework mappings

• Analyst inference EMB3D TID-107 Unauthorized Direct Memory Access (DMA) ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

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

Bounded outcome

The paper demonstrates disclosure of victim-process information through speculative execution and observable microarchitectural side effects.

Stated claim

Spectre speculative-execution disclosure demonstrations

Evidence status

Published research demonstration (published_research_demonstration)

Device, firmware & configuration

Description: Tested speculative-execution processors from Intel, AMD and Arm Configuration: Specific branch-prediction and software contexts described in the original paper; neither all variants nor modern mitigated systems are interchangeable.

Access required

Ability to execute attacker-controlled code or invoke a suitable victim gadget, according to the demonstrated variant.

Scope / hardware boundary

Specific branch-prediction and software contexts described in the original paper; neither all variants nor modern mitigated systems are interchangeable.

Dates

Published: 2018 · Reviewed: 1 November 2026 — Publication date precision: year.

Mechanisms

Microarchitectural Side Channels

Sources

• spectreattack.com ↗ (opens original source in a new tab) · Primary research paper · Reviewed 1 November 2026

Limitations

• A code-execution path and suitable processor/software conditions are prerequisites.
• This read does not establish active exploitation in a drone or the effectiveness of any current mitigation set.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 76/100

Framework mappings

• Analyst inference EMB3D TID-103 Microarchitectural Side Channels ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

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

Bounded outcome

Researchers verified modified USB descriptors being accepted by the device update tool. More extensive malicious HID behavior was described as a potential follow-on, not demonstrated in this specific result.

Stated claim

Unsigned HP/SunplusIT camera-firmware descriptor modification

Evidence status

Published research demonstration (published_research_demonstration)

Device, firmware & configuration

Description: HP Spectre x360 Convertible 13-ap0xxx with HP Wide Vision FHD/SunplusIT USB camera Configuration: Researcher's sp93170.exe update package and camera firmware image; update acceptance lacked authenticity checks.

Access required

Local software access; the author reports that the update tool worked as a normal user.

Scope / hardware boundary

Researcher's sp93170.exe update package and camera firmware image; update acceptance lacked authenticity checks.

Dates

Published: 18 February 2020 · Reviewed: 1 November 2026 — Publication date precision: day.

Mechanisms

Unverified Peripheral Firmware Loaded

Sources

• Perilous Peripherals: The Hidden Dangers Inside Windows & Linux Computers ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026

Shared source; these records are not independent experiments. Shared with primary-perilous-bcm5719-2020.

Limitations

• USB-descriptor modification is not proof of the full proposed malware behavior.
• HP mitigation work is reported by the author; current camera firmware state was not verified.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 74/100

Framework mappings

• Analyst inference EMB3D TID-113 Unverified Peripheral Firmware Loaded ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

Original record: https://eclypsium.com/research/perilous-peripherals-the-hidden-dangers-inside-windows-linux-computers/ ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

The final article demonstrates memory access and firmware dumping, followed by inspection of the recovered image.

Stated claim

Archer C7 exposed JTAG memory and firmware demonstration

Evidence status

Author demonstration (author_demonstration)

Device, firmware & configuration

Description: TP-Link Archer C7 / AC1750 with Qualcomm QCA9558-AT4A Configuration: MIPS EJTAG test platform documented across the three-part RiverLoop series; exact retail firmware revision remains unspecified.

Access required

Physical internal JTAG connection with a compatible debug probe.

Scope / hardware boundary

MIPS EJTAG test platform documented across the three-part RiverLoop series; exact retail firmware revision remains unspecified.

Dates

Published: 8 July 2021 · Reviewed: 1 November 2026 — Publication date precision: day.

Mechanisms

Latent Hardware Debug Port Allows Memory/Code Manipulation

Sources

• Hardware Hacking 101: Communicating with JTAG via OpenOCD ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026
• Hardware Hacking 101: Identifying and Verifying JTAG on a Device ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026
• Hardware Hacking 101: Introduction to JTAG ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026

Limitations

• Identification of pins alone is not counted as memory/code manipulation.
• Board-revision and debug-lock differences constrain transfer to another unit.
• No instructions or command sequences are included in this library record.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 74/100

Framework mappings

• Analyst inference EMB3D TID-119 Latent Hardware Debug Port Allows Memory/Code Manipulation ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

Original record: https://riverloopsecurity.com/blog/2021/07/hw-101-jtag-part3/ ↗ (opens original source in a new tab) · Share: link to this record

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

• Thunderspy - When Lightning Strikes Thrice: Breaking Thunderbolt 3 Security ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026
• GitHub - BjornRuytenberg/spycheck-linux: Verify whether your Thunderbolt-enabled Linux system is vulnerable to the Thunderspy attacks. · GitHub ↗ (opens original source in a new tab) · Author artifact repository · Reviewed 1 November 2026

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

Evidence confidence · 74/100

Framework mappings

• Analyst inference EMB3D TID-107 Unauthorized Direct Memory Access (DMA) ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

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

Bounded outcome

The original research demonstrates using modified NIC firmware to inspect or alter management traffic otherwise outside the host's normal view.

Stated claim

Unsigned Broadcom BCM5719 NIC firmware demonstration

Evidence status

Published research demonstration (published_research_demonstration)

Device, firmware & configuration

Description: Broadcom BCM5719 NIC in the researcher's server configuration Configuration: Unsigned host-loaded NIC firmware; BMC configured to share the NIC with the host.

Access required

Ability to modify firmware loaded to the NIC; initial compromise/firmware-write authority is a prerequisite.

Scope / hardware boundary

Unsigned host-loaded NIC firmware; BMC configured to share the NIC with the host.

Dates

Published: 18 February 2020 · Reviewed: 1 November 2026 — Publication date precision: day.

Mechanisms

Unverified Peripheral Firmware Loaded

Sources

• Perilous Peripherals: The Hidden Dangers Inside Windows & Linux Computers ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026

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

Limitations

• The report lists many potential consequences; only its demonstrated NIC behavior is presented as an observed outcome.
• Shared-NIC BMC topology and firmware acceptance are material prerequisites.
• Do not treat every server using a related component as confirmed affected today.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 73/100

Framework mappings

• Analyst inference EMB3D TID-113 Unverified Peripheral Firmware Loaded ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

Original record: https://eclypsium.com/research/perilous-peripherals-the-hidden-dangers-inside-windows-linux-computers/ ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

Researchers demonstrate differential electromagnetic analysis of the tested parallel AES implementation and recovery of information about targeted key bytes.

Stated claim

Electromagnetic side channels of an FPGA AES implementation

Evidence status

Published research demonstration (published_research_demonstration)

Device, firmware & configuration

Description: Altera Cyclone FPGA running a parallel AES implementation Configuration: Custom research implementation, not an identified drone controller or commercial cryptographic product.

Access required

Close physical electromagnetic measurement access during AES execution.

Scope / hardware boundary

Custom research implementation, not an identified drone controller or commercial cryptographic product.

Dates

Published: 2004 · Reviewed: 1 November 2026 — Publication date precision: year.

Mechanisms

Electromagnetic Analysis Side Channel

Sources

• eprint.iacr.org ↗ (opens original source in a new tab) · Primary research paper · Partially read 1 November 2026
  • Only 12 of 16 parsed pages were read.

Limitations

• Implementation- and probe-location-dependent laboratory result.
• No evidence of operational exploitation or whole-product compromise was established.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 71/100

Framework mappings

• Analyst inference EMB3D TID-102 Electromagnetic Analysis Side Channel ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

Original record: https://eprint.iacr.org/2004/145.pdf ↗ (opens original source in a new tab) · Share: link to this record

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

Evidence confidence · 69/100

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

• Analyst inference EMB3D TID-107 Unauthorized Direct Memory Access (DMA) ↗ (opens original source in a new tab)

  The reported peripheral DMA access to another device's buffers fits TID-107. The official page cites the separate IEEE/MALWARE publication, not this SSTIC paper; this companion-source mapping is explicitly analyst inference.

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

Bounded outcome

SRLabs describes tested malicious device-role emulation, including keyboard and network-interface behaviors; storage-file scanning does not inspect controller firmware.

Stated claim

BadUSB device-class emulation research

Evidence status

Published research demonstration (published_research_demonstration)

Device, firmware & configuration

Description: Reprogrammable USB-controller peripherals studied by SRLabs Configuration: The original research concerns controller firmware and role changes; particular controller/revision support is not universal.

Access required

Connection of a reprogrammed peripheral or prior control over an existing peripheral's firmware.

Scope / hardware boundary

The original research concerns controller firmware and role changes; particular controller/revision support is not universal.

Dates

Published: 31 July 2014 · Reviewed: 1 November 2026 — Publication date precision: day.

Mechanisms

Untrusted External Storage

Sources

• USB peripherals can turn against their users - SRLabs Research ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026

Limitations

• A historical author report, not evidence that every USB device can be reprogrammed.
• The2014 claim that no effective defenses are known is not promoted to a current absolute.
• The event video and archived Android proof of concept were linked but not executed or reviewed as separate artifacts.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 67/100

Framework mappings

• Analyst inference EMB3D TID-111 Untrusted External Storage ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

Original record: https://srlabs.de/blog/usb-peripherals-turn ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

The original researcher demonstrates reading a firmware image and inspecting its structure.

Stated claim

JTAG firmware extraction from a Linksys WRT54G

Evidence status

Author demonstration (author_demonstration)

Device, firmware & configuration

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

Access required

Physical board/debug-interface access.

Scope / hardware boundary

MIPS/EJTAG-accessible target with demonstrated firmware readout; exact hardware/firmware revision is not established here.

Dates

Published: 20 February 2020 · Reviewed: 1 November 2026 — Publication date precision: day.

Mechanisms

Firmware/Data Extraction via Hardware Interface

Sources

• Extracting firmware from devices using JTAG - sergioprado.blog ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026

Limitations

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

Follow-up

Evidence confidence · 67/100

Framework mappings

• Analyst inference EMB3D TID-115 Firmware/Data Extraction via Hardware Interface ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

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

Bounded outcome

The DOJ sentencing release reports an admitted act that damaged college equipment using a USB Killer device.

Stated claim

DOJ-documented USB Killer damage incident at a college

Evidence status

Government reported operational incident (government_reported_operational_incident)

Device, firmware & configuration

Description: 66 college computers plus monitors and computer-enhanced podiums; exact models undisclosed Configuration: Actual equipment identities, port protections and failure analysis are not supplied by the public sentencing release.

Access required

Physical access to device USB ports.

Scope / hardware boundary

Actual equipment identities, port protections and failure analysis are not supplied by the public sentencing release.

Dates

Published: 13 August 2019 · Event: 14 February 2019 · Reviewed: 1 November 2026 — Publication date precision: day.

Mechanisms

Weak Peripheral Port Electrical Damage Protection

Sources

• Northern District of New York | Former Student Sentenced For Destroying Computers at The College of St. Rose | United States Department of Justice ↗ (opens original source in a new tab) · Government incident report · Reviewed 1 November 2026

Limitations

• The official account establishes the reported incident and admission, not electrical waveforms or model-by-model susceptibility.
• No universal USB-C/Lightning bypass claim is imported from product advertising.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 66/100

Framework mappings

• Analyst inference EMB3D TID-118 Weak Peripheral Port Electrical Damage Protection ↗ (opens original source in a new tab)

  Mechanism-level analyst cross-reference; this case is not asserted to be named by EMB3D.

Original record: https://www.justice.gov/usao-ndny/pr/former-student-sentenced-destroying-computers-college-st-rose ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

Authors report recovering secret keys from implementation-dependent power leakage; this establishes a mechanism, not compromise of an arbitrary present-day device.

Stated claim

Differential Power Analysis against DES implementations

Evidence status

Published research demonstration (published_research_demonstration)

Device, firmware & configuration

Description: Smart-card cryptographic implementations; product identities largely undisclosed Configuration: Original paper illustrates DES power traces and differential analysis; exact commercial device revisions are not established.

Access required

Physical power-observation access and repeated cryptographic operations; laboratory instrumentation.

Scope / hardware boundary

Original paper illustrates DES power traces and differential analysis; exact commercial device revisions are not established.

Dates

Published: 1999 · Reviewed: 1 November 2026 — Publication date precision: year.

Mechanisms

Power Consumption Analysis Side Channel

Sources

• dpa.dvi ↗ (opens original source in a new tab) · Primary research paper · Reviewed 1 November 2026

Limitations

• Supplemental foundational primary evidence; the exact Arduino AES paper cited by EMB3D did not return substantive body content.
• No independent reproduction or present-day product applicability was verified.
• Research-strand review status: AI-assisted desk review; no physical reproduction or independent human acceptance claimed.

Follow-up

Evidence confidence · 65/100

Framework mappings

• Analyst inference EMB3D TID-101 Power Consumption Analysis Side Channel ↗ (opens original source in a new tab)

  Mechanism-level analyst cross-reference; this case is not asserted to be named by EMB3D.

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

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

• How to Hack Hardware using UART - Black Hills Information Security, Inc. ↗ (opens original source in a new tab) · Original researcher report · Reviewed 1 November 2026

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

Evidence confidence · 63/100

Framework mappings

• Analyst inference EMB3D TID-116 Latent Privileged Access Port ↗ (opens original source in a new tab)

  Named case or primary replacement for evidence cited by the official EMB3D hardware entry.

Original record: https://www.blackhillsinfosec.com/how-to-hack-hardware-using-uart/ ↗ (opens original source in a new tab) · Share: link to this record

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

Evidence confidence · 60/100

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

• Direct official reference EMB3D TID-116 Latent Privileged Access Port ↗ (opens original source in a new tab)

  The pinned TID-116 page explicitly names Satish S's exact 'IoT Devices - The Not-So-Hidden Risk of UART Interface' article and links its original publisher URL. This is a verified direct case reference; the archival source preserves the same URL/title/byline.

Original record: https://blog.securityinnovation.com/iot_uart ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

A first-party lab demonstration reports firmware recovery after substantial setup work. The article also records configuration corruption, unintended protection changes and temporarily unusable targets.

Stated claim

The author reports bypassing configured readout protection and extracting the complete dummy firmware from the tested STM32F401CC.

Evidence status

Author demonstration (author_demonstration)

Device, firmware & configuration

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

Access required

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

Scope / hardware boundary

Author explicitly limits observations to the tested STM32F401CC product; this is not an operational drone/robot compromise.

Dates

Published: 18 April 2025 · Reviewed: 1 November 2026 — Article published 2025-04-18 and modified 2025-04-19; experiment date is not stated.

Mechanisms

voltage fault injection; protected firmware readout

Sources

• Glitching STM32 Read Out Protection ↗ (opens original source in a new tab) · Original technical article · Reviewed 1 November 2026
  • Same public URL retrieved with main-content filtering disabled; substantive article recovered and reviewed. Distinct extraction-mode follow-up, not an uncertain paid retry.

  Supports: Exact target, dummy test firmware, complete-readout claim, failure modes and explicit product limitation.

• GitHub - giggi0x00/faultinjection-scripts: Set of scripts used during voltage fault injection attacks · GitHub ↗ (opens original source in a new tab) · Author linked source repository · Reviewed 1 November 2026
  • Linked repository availability and target directory names checked; code not executed.

  Supports: Linked repository is accessible and contains STM32F401 and STM32F103 directories.

• forum.newae.com ↗ (opens original source in a new tab) · Public forum follow up attempt · Reviewed 1 November 2026
  • All five visible posts in public topic stream reviewed.

  Supports: A different user cites this article but reports an unsuccessful STM32G0 attempt, which is not a reproduction on the same target.

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

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

Limitations

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

Follow-up

Evidence confidence · 78/100

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

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  The reported voltage fault bypasses a bootloader readout-protection decision.

• Analyst inference EMB3D TID-115 Firmware/Data Extraction via Hardware Interface ↗ (opens original source in a new tab)

  The reported consequence is protected firmware readout via the board's hardware-connected bootloader interface.

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

Bounded outcome

Authors report a protected-firmware readout demonstration and a replacement ST-LINK controller operating with the recovered firmware. They separately report that their STM32F303 test did not yield the expected content.

Stated claim

The article reports reading protected flash from specific STM32F1 parts using voltage faults during the bootloader protection decision.

Evidence status

Author demonstration (author_demonstration)

Device, firmware & configuration

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

Access required

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

Scope / hardware boundary

Modified laboratory hardware, not a drone or a robot assessment.

Dates

Published: 16 January 2020 · Reviewed: 1 November 2026 — Article displays 16 January 2020; experiments occurred before publication, exact event dates not provided.

Mechanisms

voltage fault injection; protected firmware readout

Sources

• Считывание защищенной прошивки из флеш-памяти STM32F1xx с использованием ChipWhisperer / Хабр ↗ (opens original source in a new tab) · Original technical article · Reviewed 1 November 2026
  • Public source reviewed for the scoped claim and/or linked-artifact context.

  Supports: Specific parts, readout outcome, linked demonstration and unsuccessful STM32F303 transfer test.

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

  Supports: A forum participant points to this article as their successful STM32F103 work; this is not independent reproduction.

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

Limitations

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

Follow-up

Evidence confidence · 74/100

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

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  The reported voltage fault bypasses a protection decision in processor control flow.

• Analyst inference EMB3D TID-115 Firmware/Data Extraction via Hardware Interface ↗ (opens original source in a new tab)

  The reported consequence is firmware extraction through a device programming/bootloader interface.

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

Bounded outcome

The article reports eventual full-flash acquisition and comparison with the original sample. Earlier positive acknowledgements yielded all-zero data, attributed by the authors to an unintended PCROP setting. RDP2 was not tested.

Stated claim

The original FEV Secure Lab authors report circumventing RDP1 on their STM32F401CCU6 board and reading full internal flash, compared with the sample firmware captured before enabling protection.

Evidence status

Author demonstration with validation limits (author_demonstration_with_validation_limits)

Device, firmware & configuration

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

Access required

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

Scope / hardware boundary

Physical power-fault injection at an MCU protection decision followed by firmware readout over a hardware-connected bootloader.

Dates

Published: Not stated · Reviewed: 1 November 2026 — Article date is not exposed in the capture. The EEVblog link is dated 2025-08-05; that is a reference date, not an inferred publication date.

Mechanisms

Voltage fault injection against readout protection; Firmware readout via hardware-connected bootloader

Sources

• Voltage glitching on STM32F4 MCUs ↗ (opens original source in a new tab) · Original researcher article · Reviewed 1 November 2026
  • Images/narrative read; no raw recovered image was downloaded or independently compared.

  Supports: Exact target/RDP1, pre-protection baseline, failed all-zero reads and reported eventual full-flash acquisition.

• STM 32F4xx - what hacks are known around Level 2 security? - Page 4 ↗ (opens original source in a new tab) · Public forum discussion · Reviewed 1 November 2026
  • This context does not turn an RDP1 result into an RDP2 bypass.

  Supports: Shows the linked experiment is presented in a thread about RDP2.

Limitations

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

Follow-up

Evidence confidence · 73/100

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

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  The reported fault bypasses a bootloader protection decision. This analyst mechanism relation does not independently verify a particular instruction mutation.

• Analyst inference EMB3D TID-115 Firmware/Data Extraction via Hardware Interface ↗ (opens original source in a new tab)

  The reported consequence is internal firmware readout through the hardware-connected bootloader after faulting RDP1 enforcement.

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

Bounded outcome

Recorded author-reported physical fault and matching-factor recovery in the laboratory test. This review read the transcript and original organizer report; it did not validate screen values, recompute factor equality, watch the entire video frame by frame or reproduce key recovery.

Stated claim

During the larger-injector EMFI segment, the presenter reports a faulty RSA signing output and recovery of factors matching the known test factors on a Raspberry Pi.

Evidence status

Author reported hardware result in original recording transcript (author_reported_hardware_result_in_original_recording_transcript)

Device, firmware & configuration

Recorded target: Raspberry Pi described in the narration as model 3. Linked harness configuration: Previously reviewed author material specifies Raspberry Pi 3 Model B+, 32-bit Raspberry Pi OS release 2021-10-30 and deliberately old PyCryptodome 3.1. Live configuration qualification: The transcript alone does not independently verify that the live demonstration used exactly that board revision, OS image and binary build. Software boundary: Repeated RSA-signing test with known test factors available for comparison; a later pinned PyCryptodome v3.11.0 source has fault-output validation. Injectors: A larger EMFI tool has explicit narrated factor recovery. A later separate low-cost EMFI demonstration has less explicit spoken key-recovery evidence; no identity equivalence with every PicoEMP revision is asserted.

Access required

Local physical access and EMFI equipment positioned near the Raspberry Pi during an attacker-controlled laboratory signing test. No remote-only path or production-key theft is established.

Scope / hardware boundary

Physical EM fault injection during cryptographic computation in a deliberately vulnerable educational Raspberry Pi software configuration.

Dates

Published: 3 February 2022 · Reviewed: 1 November 2026 — Recording and organizer article were published 2022-02-03 and identify Remoticon 2021. Exact session/laboratory date is not established by this review; the upload date is not treated as the experiment date.

Mechanisms

electromagnetic fault injection; faulty RSA computation with presenter-reported factor recovery

Sources

• Remoticon 2021 // Colin O'Flynn Zaps Chips (And They Talk) ↗ (opens original source in a new tab) · Original organizer recording · Transcript reviewed; screen output not validated 1 November 2026
  • Automatic transcript can contain recognition errors. No full visual review, numerical comparison, injector model authentication or independent physical validation.

  Supports: HACKADAY's 29:54 upload narrates loop-fault testing followed by Raspberry Pi RSA faulting. Larger-tool segment explicitly reports matching recovered factors; later cheap-tool speech is less explicit about that outcome.

• Remoticon 2021 // Colin O'Flynn Zaps Chips (And They Talk) ↗ (opens original source in a new tab) · Original organizer event writeup · Article text reviewed 1 November 2026
  • Same event/research lineage, not independent reproduction. Cheap-tool key extraction is an attributed organizer report; it was not separately validated against screen output here.

  Supports: Organizer identifies and embeds the same recording, describes larger and cheaper EM injection and attributes key extraction to the cheap-tool demonstration.

• Remoticon 2021 Raspberry Pi glitching material ↗ (opens original source in a new tab) · Original author repository · Prior static source review reused 1 November 2026
  • Configuration documentation does not prove live binary equivalence or physical success on its own; mutable branch as captured in prior review.

  Supports: Author's documented Pi 3 B+/32-bit OS image/date and deliberately old PyCryptodome version bound the educational setup.

• Remoticon RSA test harness ↗ (opens original source in a new tab) · Original author test code · Prior static source review reused 1 November 2026
  • No test-key file was fetched or printed, no code executed, and code alone was not counted as a physical result.

  Supports: Previously reviewed harness explains the signing test, known-factor comparison and faulty-output detection/recovery context.

• PyCryptodome v3.11.0 RSA implementation ↗ (opens original source in a new tab) · Pinned upstream implementation · Prior static source review reused 1 November 2026
  • This is a historical pinned-version check, not a current-package security assessment or a hardware reproduction.

  Supports: The later pinned implementation contains RSA fault-output validation, qualifying generalization from the deliberately old educational build.

• ChipSHOUTER PicoEMP project README ↗ (opens original source in a new tab) · Original team tool repository · README context and links reviewed 1 November 2026
  • Demonstration image, key files and hardware instructions were not collected; this does not establish which exact low-cost tool/version appears in each recording segment or success on other targets.

  Supports: Author/team README links the Remoticon RSA/Pi material and identifies a related signature-fault demonstration.

Limitations

• Transcript-only review with ASR limitations; no complete visual validation or independently observed physical key recovery.
• Known educational test factors and deliberately old cryptographic software materially bound the result.
• A documented Pi 3 B+ harness is not proof that every live demonstration component matches the documented image/version.
• Same-event recording, article and repositories are shared-source evidence, not multiple independent experiments.
• No operational glitch parameters, coil placement, pin details, keys or code are retained; no device or exploit was executed.
• Original unsuccessful PicoEMP forum outcomes and their confidence scores remain unchanged.
• TID-105 is related context only; no specific EMB3D or ATT&CK/ICS technique is assigned. TID-110 is not inferred from an erroneous value alone.

Follow-up

Evidence confidence · 72/100

Overall rationale Confidence in the bounded recorded author report, not attack probability, severity, general Raspberry Pi applicability or an official MITRE score.

Framework mappings

Unmapped. No specific EMB3D or ATT&CK mapping assigned; that is not evidence of no mechanism.

Mapping decision Source-supported result; specific EMB3D assignment withheld after independent definition review.

Original record: https://www.youtube.com/watch?v=eO-ayS4pbLQ ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

The log itself establishes an author-reported positive protocol response, not a verified complete firmware dump. The separate F401 documentation claims a memory dump and documents unintended erasure and invalid-data outcomes.

Stated claim

An original project log reports a positive bootloader response under readout protection; current author documentation separately shows a STM32F401 readout example and supplied implementation.

Evidence status

Author demonstration limited result (author_demonstration_limited_result)

Device, firmware & configuration

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

Access required

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

Scope / hardware boundary

The generic F4 log must not be silently equated to the later F401 documentation example.

Dates

Published: 5 August 2024 · Event: 8 July 2024 · Reviewed: 1 November 2026 — The log title says July 8; its displayed posting timestamp is August 5. Event date follows the title and is author-asserted, not independently verified. Current documentation has no verified publication date.

Mechanisms

voltage fault injection; protected firmware readout

Sources

• July 8 2024, later this day: Glitches! | Details | Hackaday.io ↗ (opens original source in a new tab) · Original project log · Reviewed 1 November 2026
  • Public source reviewed for the scoped claim and/or linked-artifact context.

  Supports: STM32F4 RDP1 positive-response claim and differing event/posting dates.

• Examples - PicoGlitcher / findus ↗ (opens original source in a new tab) · Author project documentation · Reviewed 1 November 2026
  • Public source reviewed for the scoped claim and/or linked-artifact context.

  Supports: Explicit STM32F401 board, reported memory-dump example and failure cases.

• fault-injection-library/projects/stm32f40x/stm32f4-glitching.py at master · MKesenheimer/fault-injection-library · GitHub ↗ (opens original source in a new tab) · Author source artifact · Reviewed 1 November 2026
  • Source artifact availability checked; operational implementation is not copied into deliverables or executed.

  Supports: Linked implementation exists at the actual stm32f40x path.

• GitHub - MKesenheimer/fault-injection-library: Python library to perform fault-injection attacks on microcontrollers · GitHub ↗ (opens original source in a new tab) · Author repository · Reviewed 1 November 2026
  • Public source reviewed for the scoped claim and/or linked-artifact context.

  Supports: Source repository and project structure exist.

Limitations

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

Follow-up

Evidence confidence · 66/100

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

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  The described voltage fault targets a readout-protection decision.

• Analyst inference EMB3D TID-115 Firmware/Data Extraction via Hardware Interface ↗ (opens original source in a new tab)

  The documentation's claimed consequence is firmware/memory extraction via the bootloader interface.

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

Bounded outcome

Example reports oversized-command acceptance, output-pin changes used to confirm code execution and serial extraction of address space. These are author-reported milestones; no named affected product, raw recovered image or independent reproduction was validated.

Stated claim

Original 31C3 slides report clock faulting of a command-length check on an unnamed production security IC, enabling code execution and code/data extraction.

Evidence status

Original conference author reported result (original_conference_author_reported_result)

Device, firmware & configuration

Description: Undisclosed production security microcontroller communicating with a partner through ISO7816-style serial protocol. Configuration: No exact victim chip, silicon revision, firmware or product identified. FPGA/Arduino boards earlier in the slides are laboratory tools, not established victim models.

Access required

Physical target electrical/communication access and a laboratory clock-fault setup.

Scope / hardware boundary

Clock faults affect a security check followed by a serial-interface code-execution/extraction chain.

Dates

Published: 27 December 2014 · Event: 27 December 2014 · Reviewed: 1 November 2026 — Schedule dates talk 2014-12-27; media page also displays 2014-12-28. Presentation/media dates kept distinct.

Mechanisms

Clock fault injection affecting a security check; Hardware-connected serial extraction

Sources

• 31c3-slides ↗ (opens original source in a new tab) · Original conference slides · Reviewed 1 November 2026
  • 66/66 pages parsed; no raw target image independently validated.

  Supports: Full 66-page presentation, target description and example milestones.

• Schedule 31. Chaos Communication Congress ↗ (opens original source in a new tab) · Original conference schedule · Reviewed 1 November 2026
  • Same talk provenance, not independent reproduction.

  Supports: Talk identity/date, original slides and production-target description.

• Glitching For n00bs - media.ccc.de ↗ (opens original source in a new tab) · Original conference archive · Reviewed 1 November 2026
  • Video itself not watched/transcribed in this Firecrawl-only review.

  Supports: Canonical talk and archived video links.

• IC Glitching Video from 31c3 (CCC) - Page 1 ↗ (opens original source in a new tab) · Public forum discussion · Reviewed 1 November 2026
  • Embedded YouTube account is terminated.

  Supports: Community discovery context dated January 2015.

Limitations

• Architecture guesses in slides do not identify an exact commercial victim.
• No drone/robot result inferred from laboratory-tool boards or possible-target lists.
• AI-assisted desk review; no LrrK physical reproduction or independent human verification of the experiment is claimed.
• No drone, robot, flight controller, PLC or operational deployment is demonstrated by this record.

Follow-up

Evidence confidence · 62/100

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

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  Example explicitly reports clock faults affecting a security check before code execution; analyst mechanism relation, not official case citation.

Original record: https://fahrplan.events.ccc.de/congress/2014/Fahrplan/system/attachments/2540/original/31c3_-_exide_-_Glitching_For_n00bs.pdf ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

Reported partial readouts are accompanied by destructive side effects, unstable behavior and configuration-dependent results. No exact-part repeatability or complete verified firmware image was independently established.

Stated claim

A participant reports reading protected flash in blocks from STM32F2/F4 targets while also triggering unintended erasure. A different participant later reports obtaining needed firmware material through a combined hardware/software investigation.

Evidence status

Community author reported result (community_author_reported_result)

Device, firmware & configuration

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

Access required

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

Scope / hardware boundary

Community laboratory reports; no drone/robot model identified.

Dates

Published: 4 November 2021 · Reviewed: 1 November 2026 — Thread began 2020-02-07; selected first-person F2/F4 result is post 20 dated 2021-11-04. Later replies were checked through 2024-08-03.

Mechanisms

voltage fault injection; protected firmware readout

Sources

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

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

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

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

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

Limitations

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

Follow-up

Evidence confidence · 52/100

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

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  Reported faults alter a read-protection decision; the mapping concerns the mechanism claimed in these reports.

• Analyst inference EMB3D TID-115 Firmware/Data Extraction via Hardware Interface ↗ (opens original source in a new tab)

  Reported consequence is firmware readout through a hardware-connected programming/bootloader interface.

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

Bounded outcome

Some replies report that work succeeded after support, but the public text does not supply a complete artifact proving the titled password bypass. The last success message belongs to a discussion that had shifted to a separate side-channel exercise.

Stated claim

The thread discusses a password-bypass clock-glitch lab, successful glitches in a preceding lab, capture-firmware faults and a later separate side-channel exercise.

Evidence status

Discussion tooling and lab (discussion_tooling_and_lab)

Device, firmware & configuration

Clock lab: CW1200 capture hardware, STM32F303, CW308 target Later distinct experiment: PSOC62 side-channel exercise Scope: Educational labs and capture-firmware troubleshooting, not a production access-control bypass.

Access required

Physical access to the educational target and capture setup.

Scope / hardware boundary

Educational labs and capture-firmware troubleshooting, not a production access-control bypass.

Dates

Published: 14 March 2022 · Reviewed: 1 November 2026 — All 18 visible posts in the topic stream were reviewed through 2022-03-21.

Mechanisms

clock fault injection; educational side-channel analysis

Sources

• forum.newae.com ↗ (opens original source in a new tab) · Public forum original discussion · Reviewed 1 November 2026
  • All 18 visible posts in public topic stream reviewed; absent post numbers are not reconstructed.

  Supports: Complete topic lets the separate glitch, firmware and side-channel conversations be distinguished.

Limitations

• Some post numbers are absent from the public stream; their contents are not reconstructed.
• No exact test firmware, build or independently verified bypass artifact.
• The separate PSOC62 exercise must not be attributed to STM32F303 clock glitching.

Follow-up

Evidence confidence · 47/100

Overall rationale Detailed setup and complete visible context, but outcome wording is ambiguous and the thread mixes separate exercises.

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  Clock-fault control-flow bypass is the intended lab mechanism; this is a conceptual mapping rather than a proven production attack.

Original record: https://forum.newae.com/t/cw1200-stm32f303-cw308t-clock-glitching-to-bypass-password/3091 ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

The retrieved thread does not resolve those users' failed experiments into successful target faults. Later component tests concern tool waveforms, not a demonstrated security bypass.

Stated claim

The original announcement describes beta EMFI hardware; later participants report that they could not induce faults on their educational targets.

Evidence status

Discussion tooling and unsuccessful attempts (discussion_tooling_and_unsuccessful_attempts)

Device, firmware & configuration

Tool: PicoEMP Community targets: CW322 educational EMFI target; XMEGA ChipWhisperer target; STM32F303 ChipWhisperer target Linked distinct demo: Remoticon repository includes Raspberry Pi 3 Model B+ example code; it is a different artifact and not proof these users induced faults.

Access required

Physical laboratory access and proximity to the target; hardware-specific coupling and configuration are material.

Dates

Published: 22 December 2021 · Reviewed: 1 November 2026 — All nine visible posts retrieved; unsuccessful experiments are dated November 2022.

Mechanisms

electromagnetic fault injection

Sources

• forum.newae.com ↗ (opens original source in a new tab) · Public forum original discussion · Reviewed 1 November 2026
  • All nine visible topic-stream posts retrieved; target failures distinguished from tool waveform checks.

  Supports: Complete beta announcement, failed target attempts and later tool-component discussion.

• GitHub - colinoflynn/remoticon-2021-levelup-hardware-hacking: Colin O'Flynn's Hacakday talk at Remoticon 2021 support repo. · GitHub ↗ (opens original source in a new tab) · Linked author repository · Partially read 1 November 2026
  • Parent repository reviewed; target code and talk are a partial-review follow-up lead, not a verified new result.

  Supports: Repository is real and distinguishes demonstration resources; it does not independently reproduce the forum users' tests.

Limitations

• No target-fault raw data or exact repeatable configuration was reviewed.
• Beta status and later revisions must not be treated as one fixed design.
• Unsuccessful reports do not prove EMFI cannot affect those device families.

Follow-up

Evidence confidence · 45/100

Overall rationale Primary tooling announcement and direct reports are authentic public evidence, but no successful target-security result is established here.

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  EMFI is a method for fault-induced control-flow modification, but these posts do not establish the intended security outcome.

Original record: https://forum.newae.com/t/picoemp-low-cost-emfi/2905 ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

No successful readout or bypass is reported in the reviewed thread. Replies discuss hardware differences and other possibilities; none establish success.

Stated claim

A participant reports that an attempted transfer of an STM32 voltage-glitch approach is not working on their STM32G0 configuration.

Evidence status

Discussion unsuccessful attempt (discussion_unsuccessful_attempt)

Device, firmware & configuration

Target: STM32G0 family, exact part unspecified Tool: ChipWhisperer Husky Reported obstacle: Author reports no accessible internal-regulator output pin.

Access required

Physical access to a target microcontroller and laboratory equipment.

Dates

Published: 28 April 2026 · Reviewed: 1 November 2026 — Five visible posts reviewed through 2026-05-13.

Mechanisms

voltage fault injection

Sources

• forum.newae.com ↗ (opens original source in a new tab) · Public forum original discussion · Reviewed 1 November 2026
  • All five visible posts in public topic stream reviewed.

  Supports: Complete five-post topic, including unsuccessful attempt and advice.

• Targets with Internal Regulators — ChipWhisperer Documentation ↗ (opens original source in a new tab) · Tool vendor documentation · Reviewed 1 November 2026
  • Public source reviewed for the scoped claim and/or linked-artifact context.

  Supports: General internal-regulator considerations; not proof of STM32G0 resistance or of a successful attack.

• Glitching STM32 Read Out Protection ↗ (opens original source in a new tab) · Original report linked by forum poster · Reviewed 1 November 2026
  • Same public URL retrieved with main-content filtering disabled; substantive article recovered and reviewed. Distinct extraction-mode follow-up, not an uncertain paid retry.

  Supports: The source experiment is STM32F401CC, not the forum's unspecified STM32G0.

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

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

Limitations

• An unsuccessful attempt does not establish that the device is resistant.
• The cited regulator document primarily discusses measurement access and does not validate this exact attempted fault-injection configuration.
• No exact STM32G0 part or firmware revision is supplied.

Follow-up

Evidence confidence · 41/100

Overall rationale Confidence concerns the narrow fact of an unresolved public attempt, not the feasibility or impossibility of bypass.

Framework mappings

• Analyst inference EMB3D TID-105 Hardware Fault Injection – Control Flow Modification ↗ (opens original source in a new tab)

  The discussed intended mechanism is a voltage-fault bypass of a readout decision.

Original record: https://forum.newae.com/t/stm32g0-rdp-level-1-bypass/6375 ↗ (opens original source in a new tab) · Share: link to this record

Bounded outcome

The discussion is useful background and contains a first-party historical partial-recovery claim, but the later participant does not demonstrate successful key recovery.

Stated claim

Maintainer replies describe attacks on unmasked hardware AES and prior partial key recovery. A later participant's reproduction remains unresolved in the thread.

Evidence status

Discussion maintainer claim and unresolved reproduction (discussion_maintainer_claim_and_unresolved_reproduction)

Device, firmware & configuration

Target: STM32F415 hardware AES discussed; CW308 STM32F4 setup in later posts Scope: Educational/vendor-support context.

Access required

Physical laboratory power-trace acquisition and access to the target test interface.

Scope / hardware boundary

Educational/vendor-support context.

Dates

Published: 12 February 2021 · Reviewed: 1 November 2026 — All 23 visible posts checked, including follow-ups through 2025-02-04.

Mechanisms

power side-channel analysis