MilanLaunchy Attack: Exploit & RF Replay

• MilanLaunchy Attack is a term that defines two distinct methods: a software-only exploit on AMD EPYC Milan ASP via BootROM mis-authentication and an RF replay interference on Orion spacecraft communications.
• The EPYC Milan exploit uses crafted SPI-Flash images and stale SRAM conditions to hijack the ASP bootloader, enabling EL1 execution that facilitates root seed extraction and compromises SEV-SNP protections.
• The RF replay interference attack remixes captured authentic S-band transmissions during spacecraft launch/re-entry to induce synchronization errors and raise bit error rates, challenging secure communication protocols.

MilanLaunchy Attack is an overloaded term in recent arXiv literature. In the most specific and explicitly named usage, it denotes a software-only exploit against the AMD Secure Processor (ASP, formerly PSP) on EPYC Milan (Zen 3), where a design flaw in the BootROM’s encrypted firmware loading and authentication path is abused to obtain arbitrary code execution in the privileged ASP bootloader context (EL1) without physical access; in the full attack chain, this is the enabling primitive for BadFuse, which extracts the hardware root VCEK seed and thereby defeats SEV-SNP’s TCB rollback protection (Shen et al., 13 May 2026). In a separate and explicitly characterized usage, the term is applied to replay-interference against Orion S-band launch and re-entry links, where a HALE-platform adversary re-transmits previously captured RF traffic over an independent propagation path in order to induce synchronization failure, false lock, or capture during high-dynamics flight phases (Benchoubane et al., 20 Jun 2025). A third paper that might be conflated by name association does not use the term at all; it instead describes URL icon fetching as the closest matching injection template in password managers (Fábrega et al., 2024).

1. Terminological scope and disambiguation

The term has two distinct technical referents in the supplied literature. The first is the EPYC Milan exploit introduced in “Insecure Despite Proven Updated: Extracting the Root VCEK Seed on EPYC Milan via a Software-Only Attack,” where MilanLaunchy is the name of the exploit that achieves code execution on the ASP and places attacker code into the privileged ASP bootloader context (EL1) (Shen et al., 13 May 2026). The second is a replay-interference characterization in “Open Sky, Open Threats: Replay Attacks in Space Launch and Re-entry Phases,” where “MilanLaunchy” denotes a HALE-platform replay campaign against Orion-spacecraft S-band traffic during launch or re-entry (Benchoubane et al., 20 Jun 2025).

Usage	Target system	Core mechanism
MilanLaunchy exploit	AMD EPYC Milan ASP / SEV-SNP chain of trust	BootROM encrypted-firmware mis-authentication plus fallback-path control-flow hijack
MilanLaunchy replay characterization	Orion S-band launch / re-entry links	Delayed re-transmission of authentic RF waveforms over a distinct channel
Not a MilanLaunchy usage	Password managers	URL icon fetching injection template, explicitly described as only the closest matching attack template

A common misconception is to treat these usages as a single attack family. The data do not support that. One concerns immutable boot firmware, VCEK derivation, and attestation forgery on EPYC Milan; the other concerns RF replay-interference against spacecraft communication links. The password-manager paper is narrower still: it states that it “does not use the term ‘MilanLaunchy Attack’,” and only aligns by loose intuition around “launch-detection” through icon fetches (Fábrega et al., 2024).

2. MilanLaunchy on EPYC Milan: target, threat model, and security property

In the SEV-SNP setting, MilanLaunchy targets the trust boundary that ties attestation to platform versioning. SEV-SNP’s attestation uses a per-chip ECDSA Versioned Chip Endorsement Key (VCEK) derived from a hardware root seed and the platform TCB version, so that newer firmware obtains stronger keys and older firmware cannot compute keys for newer versions; this is the stated core of SEV-SNP’s TCB rollback prevention guarantee (Shen et al., 13 May 2026). MilanLaunchy gives software control over the Milan ASP bootloader and SEV-SNP firmware execution, but by itself does not break rollback because the VCEK “hashstick” fixes the key to the minimal SVN the BootROM committed to while executing the compromised or rolled-back code. BadFuse is the step that bridges that remaining gap.

The threat model is the standard SEV-SNP confidential-computing model: a malicious host or hypervisor with root privileges, full BIOS control, and the ability to rewrite SPI-Flash, for example via BMC or UEFI shell; no physical access, fault injection, or debug interfaces are required (Shen et al., 13 May 2026). The reported experiments used an AMD EPYC 7413 (Milan) with a TYAN S8036GM2NE motherboard, Ubuntu 22.04, Linux 6.12, and SPI-Flash reflashing via BMC. This places MilanLaunchy squarely within the adversarial assumptions that SEV-SNP is intended to withstand.

The architectural elements relevant to the exploit are the ASP BootROM (immutable, EL1), the off-chip bootloader (EL1), and the SEV-SNP firmware (EL0). The BootROM loads the bootloader from SPI-Flash over the System Management Network (SMN), authenticates it, and handles fuse operations; the bootloader initializes AGESA modules and finally loads the SEV-SNP firmware, which handles SEV ABIs such as SNP_GUEST_REQUEST and SNP_DOWNLOAD_FIRMWARE(_EX) (Shen et al., 13 May 2026). The firmware chain of trust is anchored either in an AMD public key hash hard-coded in BootROM or, if burned, in a SHA-384 digest in fuses designated as Custom_PK.

3. Cryptographic root cause and BootROM exploitation path

The exploit relies on a specific Milan-era firmware-loading design. Milan’s BootROM uses a two-stage decryption hierarchy for encrypted ASP firmware: the BootROM Key decrypts the Wrapped IKEK via AES-128-ECB to recover the IKEK; the IKEK decrypts the Wrapped MEK in each firmware module header via AES-128-ECB; and the MEK decrypts the firmware body via AES-128-CBC with the header IV (Shen et al., 13 May 2026). The crucial generational detail is that, on Milan, the RSA-PSS signature authenticates {Header | Body} where the body is still encrypted. By contrast, Zen 1 signed {Header | Decrypt(Body)}, and Zen 4/5 added a hash of Decrypt(Body) stored in the header and covered by the signature. The Milan design therefore permits a misdecryption attack: if an attacker can manipulate the decryption key material, the decrypted plaintext can be altered without violating the signature.

The paper identifies two additional logic issues that make the design flaw exploitable in practice. First, there is a stale SRAM window: when the BootROM tries the primary off-chip bootloader (entry type 0x1), it copies the image into ASP SRAM, then verifies signature and decrypts; if verification fails, it does not clear the SRAM before loading the fallback recovery bootloader (entry type 0x3). Second, the first decrypted instruction can be made useful with brute force. Treating AES as a random permutation, forcing $n$ decrypted bits costs about $2^n$; the paper states that one 32-bit instruction costs about $2^{32}$ trials, which is minutes in practice, while two chained instructions would cost $2^{64}$ and are infeasible (Shen et al., 13 May 2026).

The resulting control-flow path is precise. A crafted SPI-Flash image contains a primary bootloader with a deliberately invalid signature and a chosen load address of 0x20000, extended with an “extra loader,” plus a valid, signed recovery bootloader extracted from Milan-PI-1.0.0.1, and a crafted Wrapped IKEK entry (0x21) whose ciphertext and HMAC cause the first decrypted instruction at the primary image entry point to become an unconditional branch to 0x20000 (Shen et al., 13 May 2026). The BootROM loads the primary bootloader into SRAM at 0x20000, fails verification but leaves the bytes intact, then loads and verifies the recovery bootloader. Immediately after decryption of the crafted primary code for execution of the first instruction, the forced first instruction branches into the stale SRAM buffer. The extra loader then copies the full custom off-chip bootloader to its standard location, for example 0x100, and branches there. At that point, attacker-controlled code executes at ASP EL1.

A plausible implication is that MilanLaunchy is not merely a transient redirection primitive but a stable boot-chain subversion method. The paper states that the custom bootloader path runs a complete EL1 environment, performs normal hardware initialization, preserves platform stability, and boots the x86 OS cleanly, which distinguishes it from more fragile fault-injection or memory-corruption patterns (Shen et al., 13 May 2026).

4. From EL1 code execution to VCEK root-seed recovery

MilanLaunchy is the enabling primitive for BadFuse rather than the complete break by itself. With EL1 code execution in the off-chip bootloader, BadFuse abuses the fuse programming interface exposed through MMIO to the SMN-mapped fuse controller. According to the reverse-engineered map, secret fuses are readable at SMN 0x5D000–0x5E000 before the BootROM asserts the read latch; afterward, reads return zeros. However, write protection for those fuses is absent or disabled by default for Milan (Shen et al., 13 May 2026).

The paper gives two independent extraction paths. In Attack I, the attacker reprograms the Custom_PK SHA-384 digest and its redundancy metadata so that the BootROM authenticates against an adversary-controlled public key rather than the hard-coded AMD key digest. The attacker then signs malicious ASP firmware with the private key corresponding to the injected Custom_PK and sets its SVN to 255. Because, in the Milan hashstick, the VCEK seed associated with SVN=255 is cryptographically equivalent to the root VCEK seed under Algorithm 1, the malicious firmware can boot at the highest SVN and exfiltrate the effective root seed to host DRAM (Shen et al., 13 May 2026).

In Attack II, the root VCEK seed is reconstructed bit-by-bit with a fuse oracle across cold reboots. The pseudocode supplied in the paper iterates over all 256 bits, blindly tries to set each bit to 1, cold reboots the system, fetches the current VCEK, and compares it to a baseline. If the VCEK changes, the bit was originally 0; otherwise it was already 1 (Shen et al., 13 May 2026). The method depends on the observation that ECC and Fletcher checking on the VCEK seed region were found to be disabled in practice on Milan, and that re-blowing an already-1 bit is harmless.

Once the root seed is available, the cryptographic consequences are direct. The attacker can derive per-version VCEK seeds by traversing the hash chain, compute ECDSA VCEKs for arbitrary tuples of layer SVNs, and sign attestation reports that validate for any purported TCB version (Shen et al., 13 May 2026). Relying parties and cloud tenants therefore observe valid signatures and a plausible TCB version, even when the platform is actually running older or compromised firmware. This is why the paper concludes that MilanLaunchy plus BadFuse “collapse SEV-SNP’s anti-rollback model on EPYC Milan.”

5. Scope, affected versions, mitigations, and disclosure

The affected generation is EPYC Milan (Zen 3) SEV-SNP platforms; the paper also states that Threadripper PRO 59x5WX shares the same vulnerable BootROM and lacks the VCEK isolation, making it affected for the non-SNP supply-chain angle discussed in Appendix A.2 (Shen et al., 13 May 2026). Zen 4/5 systems such as EPYC Genoa and Bergamo are described as unaffected by MilanLaunchy because they added a decrypted-body hash stored in the header and covered by RSA-PSS, which closes the Milan mis-authentication hole.

AMD’s Milan mitigations are partial and version-sensitive. Beginning with Milan-PI-1.0.0.3, AMD stopped shipping encrypted ASP payloads and bumped the off-chip bootloader SVN; the paper states that this prevents leveraging MilanLaunchy to escape the minimal-SVN key trap, even though the BootROM bug itself is immutable (Shen et al., 13 May 2026). This means that downgrade paths remain relevant unless additional controls are enforced. The authors’ recommendations include removing support for Custom_PK hashing in the BootROM, ensuring that the signature covers Decrypt(Body) or a signed authenticated hash of Decrypt(Body), binding public-key identity into the VCEK root derivation or adopting a DICE-style derivation that measures firmware content, and adding write-protect controls and mandatory ECC/Fletcher validation for secret fuse arrays.

The practical constraints are also explicit. Attack II requires many cold reboot cycles, one per bit, to refresh the fuse latch and re-derive a new VCEK. The attacker must be able to rewrite SPI-Flash and reboot the host. No JTAG, SPI bus probing, or glitching is needed; the attack is software-only (Shen et al., 13 May 2026). The disclosure timeline places MilanLaunchy disclosure on January 6, 2026, with AMD SB-3045 on May 12, 2026, and BadFuse disclosure on April 8, 2026.

A plausible implication is that the dominant lesson is architectural rather than implementation-local: protecting attestation against rollback requires not only one-way seed derivation, but also immutable cryptographic binding in the BootROM and strict write protection over the fuse state that anchors that derivation.

6. MilanLaunchy as replay-interference in spacecraft launch and re-entry links

In a separate usage, “MilanLaunchy” denotes replay-interference in RF spacecraft links rather than a firmware exploit. A replay attack captures a valid, previously transmitted waveform, including its modulation, framing, and synchronization features, and re-transmits it after a delay; in launch and re-entry links, that replay arrives with different time-of-flight, Doppler, and channel phase than the original (Benchoubane et al., 20 Jun 2025). Unlike simple jamming or spoofing, replay injects an authentic-looking but time-shifted signal that competes coherently in the receiver’s synchronizers and PLLs. During launch and re-entry, where dynamics are high, link budgets are tight, and timing is critical, replay can force false locks, desynchronize, or capture the receiver even without fabricating new frames.

The characterized adversary is a HALE-platform interceptor of Orion S-band traffic. In the launch downlink scenario, the attacker intercepts Orion downlink intended for GS1 and replays it toward GS1, while GS2 sees only legitimate Orion downlink due to geometry and the Best Frame Selector (BFS) prefers the better ground-station feed. In re-entry uplink and downlink scenarios, the attacker replays previously captured GSR-to-Orion or Orion-to-GSR traffic over a distinct emulated channel with different delays, taps, and Doppler and without phase coherence to the legitimate signal (Benchoubane et al., 20 Jun 2025).

The quantitative effects are substantial. The abstract reports that the attacker’s signal can overpower legitimate transmissions, leading to a Signal to Noise Ratio difference of up to -7.8 dB during re-entry and -6.5 dB during launch. For re-entry downlink, with GA^out = -25 dB, ΔSNR ≈ -7.8 dB, and BER jumps to 13.0% for MQ-9 replay and 10.6% for RQ-4 replay. For re-entry uplink, the same attacker output gives ΔSNR ≈ -7.1 dB for MQ-9 and -6.9 dB for RQ-4, with BER rising to 26–30%. For launch downlink at Max-Q, overshadowing begins at lower attacker output levels, with visible ΔSNR degradation already at about GA^out ≈ -45 dB on GS1, while GS2 maintains ΔSNR ≈ -0.14 dB and is selected by BFS (Benchoubane et al., 20 Jun 2025).

The proposed mitigation is a more secure receiver design incorporating a phase-coherency-dependent decision-directed equalizer and a narrowed second-order DPPL bandwidth, reduced from 62.8×10^-3 in the baseline to 15.7 mrad. The equalizer replaces phase-agnostic CMA with a decision-directed LMS-style linear equalizer whose updates are suppressed unless the post-PLL phase lies within a coherency window. Reported improvements under attack include BER reductions of 54.5% and 73% on re-entry downlink, reduction from 30.28% and 26.75% to about 3.45% on re-entry uplink, and about 89% BER reduction on launch downlink at GS1 under attack (Benchoubane et al., 20 Jun 2025). This suggests that the term “MilanLaunchy” in the spacecraft context is best understood as a replay-induced synchronization and capture problem, not as a protocol-level forgery in the SEV-SNP sense.

7. Relationship to adjacent literature and common confusions

The password-manager literature in the supplied data is relevant chiefly as a disambiguation point. “Exploiting Leakage in Password Managers via Injection Attacks” explicitly states that it does not use the term “MilanLaunchy Attack,” and identifies the URL icon fetching attack only as the “closest matching attack template” (Fábrega et al., 2024). In that template, the attacker controls their own application client, injects candidate URLs into a victim’s shared vault items, and observes whether the client launches icon-fetch requests; the resulting fetch/no-fetch signal acts as a deterministic 1-bit oracle for URL membership. Although the paper uses words such as “launches a server fetch,” this is unrelated to either the EPYC Milan BootROM exploit or the Orion replay characterization.

The technical difference is fundamental. MilanLaunchy on EPYC Milan is a boot-chain exploit that abuses mis-authentication of encrypted firmware and a fallback-path SRAM artifact to obtain ASP EL1 execution, then serves as the precondition for root-seed extraction and attestation forgery (Shen et al., 13 May 2026). MilanLaunchy in the spacecraft characterization is a replay-interference campaign against high-dynamics S-band links, where an authentic waveform is re-transmitted with altered delay, Doppler, and phase to destabilize synchronizers and PLLs (Benchoubane et al., 20 Jun 2025). The password-manager paper instead studies injection plus side-channel observation in end-user applications and treats icon-fetch behavior as a control-flow leakage oracle rather than as a launch, replay, or firmware-subversion mechanism (Fábrega et al., 2024).

For researchers, the main interpretive point is therefore terminological hygiene. Where the context is SEV-SNP, ASP EL1, VCEK, or BadFuse, MilanLaunchy refers to the EPYC Milan exploit. Where the context is Orion, HALE platforms, SDRs, Max-Q, or replay-induced false lock, it refers to the RF replay-interference characterization. Treating one as evidence about the other would be unwarranted.