{ "archive_path": "archive/1789769086.10138", "base_url": "donjon.ledger.com/blog/rp2350-secure-debug-laser-fault-injection", "basename": "", "bookmarked_date": "2026-09-18 22:04", "canonical": { "archive_org_path": "https://web.archive.org/web/donjon.ledger.com/blog/rp2350-secure-debug-laser-fault-injection", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=donjon.ledger.com", "headers_path": "headers.json", "htmltotext_path": "htmltotext.txt", "index_path": "index.html", "media_path": "media/", "mercury_path": "mercury/content.html", "pdf_path": "output.pdf", "readability_path": "readability/content.html", "screenshot_path": "screenshot.png", "singlefile_path": "singlefile.html", "warc_path": "warc/", "wget_path": "donjon.ledger.com/blog/rp2350-secure-debug-laser-fault-injection/index.html" }, "domain": "donjon.ledger.com", "extension": "", "hash": "QNJMT0KD4EQ8WBGCXH6J", "history": { "archive_org": [], "dom": [], "favicon": [ { "cmd": [ "curl", "--silent", "--location", "--compressed", "--max-time", "120", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://www.google.com/s2/favicons?domain=donjon.ledger.com" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-09-18T22:06:46.718405+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1789769086.10138", "schema": "ArchiveResult", "start_ts": "2026-09-18T22:06:46.139604+00:00", "status": "succeeded" } ], "git": [], "headers": [ { "cmd": [ "curl", "--silent", "--location", "--compressed", "--head", "--max-time", "120", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://donjon.ledger.com/blog/rp2350-secure-debug-laser-fault-injection/" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-09-18T22:06:47.072783+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1789769086.10138", "schema": "ArchiveResult", "start_ts": "2026-09-18T22:06:46.723696+00:00", "status": "succeeded" } ], "htmltotext": [], "media": [], "mercury": [ { "cmd": [ "/app/node_modules/@postlight/parser/cli.js", "https://donjon.ledger.com/blog/rp2350-secure-debug-laser-fault-injection/" ], "cmd_version": "1.0.0", "end_ts": "2026-09-18T22:06:54.663148+00:00", "index_texts": null, "output": "mercury", "pwd": "/data/archive/1789769086.10138", "schema": "ArchiveResult", "start_ts": "2026-09-18T22:06:51.214058+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/app/node_modules/readability-extractor/readability-extractor", "/tmp/tmpm9q91yvv", "https://donjon.ledger.com/blog/rp2350-secure-debug-laser-fault-injection/" ], "cmd_version": "0.0.11", "end_ts": "2026-09-18T22:06:51.207177+00:00", "index_texts": [ "TL;DR\n\u2014 Photon-emission microscopy allowed us to locate a register responsible for the enabling of debug features on the Raspberry Pi microcontroller.\n\u2014 Laser pulses at two nearby positions then restored debugger access to the chip\u2019s Secure world, even though debug had been permanently disabled.\n\u2014 Using that access after a rescue reset, we recovered a secret from one-time-programmable memory. The reset halted the chip before firmware could apply its runtime lock, so the page stayed Secure-readable.\n\u2014 The attack requires physical access, destructive preparation, and approximately $250,000 of laboratory equipment.\nThe RP2350 security model\nThe RP2350 is Raspberry Pi\u2019s dual-core microcontroller: each processor socket can select either an Arm Cortex-M33 or a RISC-V Hazard3 core at boot. Its hardware security features include:\n\nSecure boot, which authenticates signed firmware against public-key fingerprints provisioned in One-Time Programmable memory (OTP)\nThe Armv8-M TrustZone, which separates Secure and Non-secure execution states\nPermanent debug-disable settings\nGlitch detectors intended to detect timing disturbances caused by clock or supply manipulation\n\nRaspberry Pi has actively invited researchers to evaluate these protections through its RP2350 Hacking Challenges. The first challenge ran from August to December 2024 against the original chip. After several findings were addressed, Raspberry Pi released the A4 revision\u2014the version we tested.\nThe permanent security configuration and boot public key fingerprints are stored in one-time-programmable (OTP) memory: each bit can be flipped from 0 to 1 once and never back, so whatever is written there lasts for the lifetime of the chip.\nOTP is organised into 128-byte pages protected by two persistent, or hard, lock rows: for page n, PAGEn_LOCK0 configures optional read and write keys and the behaviour when no key is entered, while PAGEn_LOCK1 contains the hardware-enforced LOCK_S and LOCK_NS permissions. Those states can advance from read-write to read-only or inaccessible but cannot become more permissive.\nThe OTP subsystem uses redundant encodings for security-related fields: critical flags are \u201cencoded with a three-of-eight vote across eight consecutive OTP rows\u201d, and OTP lock bits are \u201ctriple-redundant with a majority vote\u201d, according to the RP2350 datasheet.\nAt an OTP reset, the persistent LOCK_S and LOCK_NS values initialise a per-page runtime lock, also called a soft lock. Firmware can tighten this lock until the next OTP reset, but cannot loosen it. The runtime change does not survive that reset.\nAn external debugger communicates with the RP2350 through Arm\u2019s Serial Wire Debug (SWD) interface. Requests first reach the Serial Wire Debug Port (SW-DP) and are then routed to access ports. In the Cortex-M33 configuration used here, each core has a memory access port (Mem-AP) connected to its system bus; an enabled Mem-AP lets the debugger read and write permitted memory and peripherals. A separate always-on access port, the RP-AP, exposes a small set of reset and recovery controls.\nSecure debug refers to Mem-AP access with Secure attribution. The debugger can then transact with Secure memory-mapped resources the access-control logic permits, and halt or inspect a core running in the Secure state.\nThe permanent CRIT1.DEBUG_DISABLE flag is intended to close this path. When set, it drives the enable signals for both cores\u2019 Mem-APs to zero, which \u201cprevents the APs from performing any bus accesses at all\u201d, and disables the factory-test JTAG interface and the RISC-V debug module\u2019s access port. The SW-DP and RP-AP still respond, but neither core Mem-AP can access the system bus.\nThere is, however, an override: the memory-mapped DEBUGEN register lets Secure software re-enable each core\u2019s Mem-AP and, separately, Secure accesses through it. The datasheet states that DEBUG_DISABLE \u201ccan be fully overridden by setting all bits of this register\u201d.\nThis critical override in the enforcement chain is what made the debug interface our target. Gaining access to Secure debug on a Mem-AP is a general-purpose primitive to read and write Secure memory, halt and single-step a core, and inspect its registers. Whether that register could be set by a fault is the question the rest of this post answers.\nExperimental setup\nTarget configuration\nRaspberry Pi\u2019s RP2350 Hacking Challenge asked participants to extract a 128-bit secret stored in OTP1. At startup, the signed challenge firmware ensures that page 48 has the expected persistent lock, then applies a runtime lock that denies both Secure and Non-secure access to the secret until the next OTP reset.\nWe replicated this vendor-defined configuration on our own revision A4 device:\n\nProgrammed the SHA-256 fingerprint of our public key into BOOTKEY0\nSet BOOT_FLAGS1.KEY_VALID to 0x1 and BOOT_FLAGS1.KEY_INVALID to 0xe\nEnabled secure boot (CRIT1.SECURE_BOOT_ENABLE = 1)\nPermanently disabled debug (CRIT1.DEBUG_DISABLE = 1)\nEnabled the glitch detectors at maximum sensitivity (CRIT1.GLITCH_DETECTOR_ENABLE = 1, CRIT1.GLITCH_DETECTOR_SENS = 3)\nConfigured the persistent locks for pages 1 and 2 according to the challenge configuration\nSet the page 48 persistent lock to PAGE48_LOCK1 = 0x3c3c3c, which denied Non-secure access (LOCK_NS = INACCESSIBLE) while retaining Secure read-write access (LOCK_S = READ_WRITE)\n\nEnabling secure boot permits only the Cortex-M33 cores, so both processor sockets used Arm for these experiments.\nSample preparation and bench\nThe device was backside decapsulated, so that infrared light reaches the transistors through the silicon substrate rather than being blocked by the metal layers on the front. The chip was then soldered back onto a daughterboard connected to Scaffold, Ledger Donjon\u2019s open source platform for driving and monitoring devices under test. Removing the lead frame on the backside of the chip breaks its GND connection, so a copper wire restores it2.\nBackside-decapsulated RP2350 mounted on the analysis daughterboard\nExperimental bench used for the attack\nDEBUGEN: overriding permanent debug disable\nDEBUGEN has five functional bits:\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nBitNameEffect0PROC0Enable core 0\u2019s memory access port1PROC0_SECUREPermit Secure accesses through core 0\u2019s memory access port2PROC1Enable core 1\u2019s memory access port3PROC1_SECUREPermit Secure accesses through core 1\u2019s memory access port8MISCEnable additional debug components, including the cross-trigger interface and the RISC-V debug access port\nSecure debug on a core needs both of its bits: the one that enables the Mem-AP, and the one that permits Secure accesses through it.\nIn contrast to the redundant encoding used for OTP security fields, the datasheet documents no bit redundancy, parity or majority vote for DEBUGEN.\nWe therefore tested whether laser pulses could set DEBUGEN bits on the secured device described above.\nPhoton-emission-guided localization\nThat test first requires knowing where to aim. Setting an individual DEBUGEN bit means hitting the storage of a single register bit, a needle in a haystack. This is a harder targeting problem than the instruction-skip faults common in laser fault injection, where disturbing any of the many flip-flops in a core pipeline can produce the same skip: that spreads the sensitive area widely enough for a random scan to find it. A blind scan for one DEBUGEN bit is impractical.\nSwitching transistors emit faint near-infrared photons correlated with their activity, so collecting that emission over repeated execution can reveal where a selected control changes state. This made photon-emission microscopy (PEM) a good fit for DEBUGEN: as a memory-mapped register, Secure software can toggle exact bits in a loop, driving the repeated state changes the measurement needs. We used it as the first localization stage, and the resulting map constrained the subsequent laser scan to a region of a few micrometres.\nWe compared loops that repeatedly toggled selected DEBUGEN bits on and off, differing only in the bits they targeted. A register\u2019s photon emission is faint next to the camera\u2019s own noise and sensitive to slowly drifting ambient conditions such as temperature, so a single frame reveals nothing. Averaging many frames of each loop suppressed random sensor noise, and subtracting the two mean stacks cancelled everything the loops shared: static background, sensor offset, thermal emission, and switching unrelated to the selected bits. Interleaving the two values during acquisition kept slow drift from biasing that subtraction. What remained was the emission that tracked the selected bits.\n\n \n Mean stacks of all 200 mask 0x3 and mask 0xc acquisitions, followed by their signed difference. Red is positive, indicating greater emission for 0x3; blue is negative, indicating greater emission for 0xc. The localization maps below additionally balance acquisition order before combining matched differences.\n\nRepeated comparisons across different bit masks exposed compact sites associated with DEBUGEN bits 0\u20133 across three regions of the camera field.\n\n \n Infrared overview of the camera field, with three marked regions. Coloured pixels mark sites associated with `DEBUGEN` bits 0-3.\n\nThese zones show switching activity associated with each DEBUGEN bit; they do not directly identify storage cells. The multiple hotspots observed for each bit may arise from the storage element or from related logic. Without layout data, we cannot distinguish between the two. However, these zones still significantly reduce the search space.\nFinding 1 \u2014 faulting DEBUGEN gives Secure debug\nFor laser fault injection (LFI), we used a pulsed laser at 980 nm with 2.97 W maximum optical power, operated at roughly 40% (about 1.2 W), with a 100 ns pulse width through a 50x objective. After each pulse, we probed the debug access ports over SWD.\nWithin the area found from PEM, we ran an LFI scan and used that SWD feedback to calibrate two responsive positions a few micrometres apart. At one position, pulses enabled bus access through core 1\u2019s Mem-AP, indicating that PROC1 was set. At the other, the Mem-AP\u2019s Control/Status Word reported SDeviceEn = 1, a state-guided signal that PROC1_SECURE was likely set. We checked both indicators after every pulse.\n\n \n Left: PEM sites associated with `DEBUGEN` bits. Right: laser-fault points on the LFI infrared view.\n\nA pulse that set one bit could clear the other, so setting both required an iterative sequence. Our script pulsed the PROC1 position until bus access was available, then pulsed the PROC1_SECURE position until SDeviceEn = 1, returning to the first position whenever bus access was lost. Once the positions and pulse parameters were calibrated, the sequence enabled Secure debug within seconds. Interestingly, we could not reproduce this sequence using a 20x objective. Because the two positions are only a few micrometres apart, that wider spot likely hit both the region that sets a bit and the one that clears it, so it was not possible to obtain the correct value.\nOnce both bits were set, they remained set without further pulses or software writes. Reading the Secure-only DEBUGEN register through core 1\u2019s Mem-AP then returned 0xc; because DEBUGEN is Secure-only, that successful read confirms the transaction was Secure-attributed.\nEnabling Secure accesses through core 1\u2019s Mem-AP allows the debugger to read and write memory-mapped resources whose ACCESSCTRL permissions admit the debugger as a bus manager and whose target-specific controls admit Secure AHB transactions. Independently of those direct reads, the debugger can halt and single-step the core and inspect or modify its registers, compromising TrustZone runtime isolation through Secure-core-mediated extraction. This does not make the boot ROM accept unauthenticated firmware: when firmware boots normally, secure boot still authenticates it, but cannot protect runtime state that remains accessible to the debugger after verification.\nApplication to the Hacking Challenge configuration\nThe Secure-attributed Mem-AP access described above exposes Secure runtime state, but the challenge\u2019s page 48 runtime lock still prevents access to the secret after firmware has run. The page\u2019s persistent lock, PAGE48_LOCK1 = 0x3c3c3c, denies Non-secure reads but leaves LOCK_S at READ_WRITE, so it remains readable through Secure-attributed accesses before the runtime lock is tightened.\nDuring each boot, the firmware writes the most restrictive binary value, 0b1111, to the runtime lock otp_hw->sw_lock[48]. That register then makes the page inaccessible to both Secure and Non-secure accesses, including Secure debug, and therefore prevents Secure transactions from the Mem-AP from reading the secret.\nAs documented, software locks \u201care initialised from the OTP lock pages at reset\u201d, and a write only advances the state \u201cuntil next reset\u201d. Resetting the OTP block discards 0b1111 and restores the value derived from PAGE48_LOCK1, for which LOCK_S = READ_WRITE.\nThe remaining question is how to reset a locked chip without allowing firmware to re-apply the runtime lock. The RP-AP remains \u201calways accessible, even when external debug is disabled\u201d. Setting CTRL.RESCUE_RESTART triggers a rescue reset: a full system reset that also flags the boot ROM to halt before any user software runs.\nThe boot ROM checks POWMAN_CHIP_RESET.RESCUE_FLAG before watchdog, flash or USB boot, clears it, then holds core 0 in an interrupt-disabled wait loop and core 1 in its wait-for-vector path.3 The datasheet documents no restriction on CTRL.RESCUE_RESTART.\nWe proceeded in the following sequence:\n\nRescue reset. Set CTRL.RESCUE_RESTART to 1, then clear it to 0 through the RP-AP. The chip resets and remains in boot-ROM wait paths. The signed firmware never runs, so sw_lock[48] is never tightened and stays at the permissive value derived from PAGE48_LOCK1 \u2014 LOCK_S = READ_WRITE.\nFault DEBUGEN to 0xc. With both cores in boot-ROM wait paths, set PROC1 and PROC1_SECURE as described above; these two set bits produce the value 0xc.\nHalt core 1 through its Debug Halting Control and Status Register (DHCSR) over the now-Secure Mem-AP.\nRead the secret from OTP rows 0xc08\u20130xc0f through the guarded read interface.\n\nWe ran this sequence on the tested device and recovered the complete challenge secret.\nDEBUGEN_LOCK does not prevent laser-induced changes\nDEBUGEN_LOCK blocks software writes to the corresponding DEBUGEN bits: each lock bit is \u201cWrite 1 to lock the [\u2026] bit of DEBUGEN. Can\u2019t be cleared once set\u201d. The datasheet presents this as a way \u201cto avoid accidental writes\u201d.\nIn trials with the target DEBUGEN bit at 0 and its lock bit at 1, a pulse could still set DEBUGEN while the lock remained 1. Pulses also set lock bits, with or without a corresponding DEBUGEN change. In successful sequences, all five functional lock bits were 1 by the time PROC1 and PROC1_SECURE were both set. We never saw a lock bit return from 1 to 0, so a later write of DEBUGEN = 0 cannot restore the disabled state once the fault has set the corresponding lock.\nLimits of software-based mitigations\nOnce Secure accesses through the Mem-AP are enabled, Secure attribution alone no longer separates the debugger from Secure firmware. This access does not override hard OTP locks or peripheral-specific controls. ACCESSCTRL can block direct debugger-manager transactions to particular targets, but it does not by itself prevent a debugger controlling the Secure core from causing core-originated accesses or extracting loaded values through core registers. After a rescue reset, ACCESSCTRL returns to its all-open reset-time defaults before firmware can reconfigure it. ACCESSCTRL therefore reduces direct Mem-AP exposure rather than forming a standalone confidentiality boundary.\nFirmware can nevertheless reduce post-boot exposure by denying the debugger access to sensitive targets in ACCESSCTRL, then setting the debugger bit in ACCESSCTRL.LOCK so that debugger transactions cannot reopen those permissions. Secure firmware can also check DEBUGEN periodically and, on an unexpected value, trigger a fail-safe reset that clears the processor-cold reset domain. These measures are best-effort runtime mitigations: an enabled debugger may halt the core before the next check, and rescue reset stops before firmware can configure ACCESSCTRL or run the monitor. They therefore do not prevent the pre-firmware secret read demonstrated here.\nRP2350\u2019s documented encrypted-boot flow illustrates the pre-firmware limitation of runtime locks and the post-boot limitation of debugger-manager filtering in two distinct machine states. After rescue reset, the boot ROM halts before decryption: no plaintext payload exists yet, but the decryption key may be directly readable if the OTP page\u2019s persistent permissions allow Secure access and no other target control blocks the transaction. After normal encrypted boot, plaintext exists in SRAM: direct Mem-AP reads depend on debugger-manager permissions in ACCESSCTRL, while Secure-core control may permit core-mediated extraction even when direct reads are denied. This is architectural analysis, not a tested encrypted-boot result; encrypted boot still protects external flash from offline inspection.\nImpact and attack requirements\nThe demonstrated sequence provides Secure-attributed memory access, control over Secure-world execution, and access to the challenge secret after resetting its runtime page lock. It requires the following resources:\n\nDestructive physical access. Backside decapsulation permanently modifies the package and leaves the die exposed.\nSpecialised laboratory equipment. The complete setup described above costs approximately $250,000.\nHardware-security expertise. The procedure requires sample preparation, die navigation, laser parameter selection, and coordinated laser control, stage positioning, and SWD measurement.\n\nConclusion\nThe RP2350 encodes critical debug-disable flags in OTP with redundant voting, but DEBUGEN can override their effect and has no equivalent protection documented in the datasheet. In our experiments, laser pulses changed DEBUGEN despite DEBUGEN_LOCK and could set a lock bit that prevented firmware from restoring the disabled value. Separately, the RP-AP rescue reset restored the challenge\u2019s runtime page lock to its persistent value while preventing user firmware from executing. The software-visible mechanisms each performed their documented function, but their interaction with the laser fault enabled Secure debug and recovery of the challenge secret. Differential PEM first isolated bit-dependent DEBUGEN activity, and guided LFI converted that spatial lead into persistent Secure debug. The system-level lesson is that security analysis must cover the complete enforcement path, from persistent OTP configuration through mutable control registers and reset behaviour, because system security depends on that path rather than on individual mechanisms in isolation.\nDisclosure and acknowledgements\nWe disclosed this fault to Raspberry Pi on 28 July 2026. We thank the Raspberry Pi team for their engagement in the disclosure discussions and for their transparent approach to security research.\n\nAntoine Plin, Hardware Security Intern at Ledger Donjon\n\n\n\nhttps://github.com/raspberrypi/rp2350_hacking_challenge The RP2350 Hacking Challenge repository, containing the reference lockdown configuration and firmware we replicated. \u21a9\n\n\nCourk, Laser Fault Injection on a Budget: RP2350 Edition. \u21a9\n\n\nThe rescue check is step 1 of the core 0 boot path in src/main/arm/varm_boot_path.c; in src/main/arm/arm8_bootrom_rt0.S, varm_wait_rescue enters the interrupt-disabled varm_dead_quiet WFI loop while core 1 remains in the boot ROM\u2019s wait-for-vector path. \u21a9" ], "output": "readability", "pwd": "/data/archive/1789769086.10138", "schema": "ArchiveResult", "start_ts": "2026-09-18T22:06:49.627076+00:00", "status": "succeeded" } ], "screenshot": [], "singlefile": [], "title": [ { "cmd": [ "curl", "--silent", "--location", "--compressed", "--max-time", "120", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://donjon.ledger.com/blog/rp2350-secure-debug-laser-fault-injection/" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-09-18T22:06:49.622595+00:00", "index_texts": null, "output": "Photon-Emission-Guided Laser Fault Injection Enables RP2350 Secure Debug | Ledger Donjon", "pwd": "/data/archive/1789769086.10138", "schema": "ArchiveResult", "start_ts": "2026-09-18T22:06:49.608320+00:00", "status": "succeeded" } ], "wget": [ { "cmd": [ "wget", "--no-verbose", "--adjust-extension", "--convert-links", "--force-directories", "--span-hosts", "--no-parent", "-e", "robots=off", "--reject=js,mjs,woff,woff2,ttf,otf,eot,mp4,m4v,mov,webm,ogv,mkv,avi,flv", "--timeout=120", "--restrict-file-names=windows", "--page-requisites", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) wget/GNU Wget 1.21.3", "--compression=auto", "--timestamping", "https://donjon.ledger.com/blog/rp2350-secure-debug-laser-fault-injection/" ], "cmd_version": "GNU Wget 1.21.3", "end_ts": "2026-09-18T22:06:49.602190+00:00", "index_texts": null, "output": "donjon.ledger.com/blog/rp2350-secure-debug-laser-fault-injection/index.html", "pwd": "/data/archive/1789769086.10138", "schema": "ArchiveResult", "start_ts": "2026-09-18T22:06:47.079298+00:00", "status": "succeeded" } ] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": null, "dom": null, "favicon": "favicon.ico", "git": null, "media": null, "pdf": null, "screenshot": null, "singlefile": null, "title": "Photon-Emission-Guided Laser Fault Injection Enables RP2350 Secure Debug | Ledger Donjon", "warc": null, "wget": "donjon.ledger.com/blog/rp2350-secure-debug-laser-fault-injection/index.html" }, "link_dir": "/data/archive/1789769086.10138", "newest_archive_date": "2026-09-18T22:06:51.214058+00:00", "num_failures": 0, "num_outputs": 6, "oldest_archive_date": "2026-09-18T22:06:46.139604+00:00", "path": "/blog/rp2350-secure-debug-laser-fault-injection/", "schema": "Link", "scheme": "https", "snapshot_id": "398ad8af-86dc-4622-bb78-f342eca766ba", "sources": [ "/data/sources/1789769086-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1789769086.10138", "title": "Photon-Emission-Guided Laser Fault Injection Enables RP2350 Secure Debug | Ledger Donjon", "updated": "2026-09-18T22:06:46.139113+00:00", "updated_date": "2026-09-18 22:06", "url": "https://donjon.ledger.com/blog/rp2350-secure-debug-laser-fault-injection/" }