---
title: 'MilanLaunchy Attack: Exploit & RF Replay'
url: https://www.emergentmind.com/topics/milanlaunchy-attack
type: topic
---

# MilanLaunchy Attack: Exploit & RF Replay

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 [2605.12990]. 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 [2506.17446]. 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 [2408.07054].

## 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) [2605.12990]. 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 [2506.17446].

| 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 [2408.07054].

## 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 [2605.12990]. 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 [2605.12990]. 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) [2605.12990]. 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 [2605.12990]. 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 [2605.12990].

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` [2605.12990]. 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 [2605.12990].

## 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 [2605.12990].

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 [2605.12990].

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` [2605.12990]. 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 [2605.12990]. 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 [2605.12990]. 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 [2605.12990]. 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 [2605.12990]. 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 [2506.17446]. 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 [2506.17446].

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 [2506.17446].

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 [2506.17446]. 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” [2408.07054]. 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 [2605.12990]. 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 [2506.17446]. 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 [2408.07054].

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.

Source: https://www.emergentmind.com/topics/milanlaunchy-attack