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

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

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

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

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

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