Microsoft's 'unhackable' Xbox One has been hacked by 'Bliss'

Original Article ↗ Hacker News Discussion ↗

Microsoft’s 2013 Xbox One, long regarded as effectively “unhackable,” has finally been compromised via a sophisticated voltage glitching attack on its immutable boot ROM, enabling execution of unsigned code at the highest privilege level. Commenters frame this as a major engineering success rather than a failure, noting it took over a decade, physical access, and advanced hardware skills—and only affects early hardware revisions that were already obsolete. The thread broadens into questions about what “unhackable” really means, the economics and incentives behind console hacking, and how these techniques inform both future console security and broader trends like locked‑down consumer hardware.

Meaning of “Unhackable”

  • Strong disagreement over the term:
    • Some argue nothing is literally unhackable; the label invites ridicule (Titanic analogy, word inflation concerns).
    • Others say “unhackable” is reasonable in context: 13 years without a full compromise, including its entire commercial life, and relative to peers (PS4, iPhones) that were hacked much earlier.
    • Several note Microsoft never used that term; media and headlines did.

Difficulty, Timeframe, and Security Goals

  • Attack affects only the first 2013 “VCR” hardware revision; later silicon added more anti‑glitch protections.
  • Seen by many as a huge success:
    • No full boot‑chain compromise during the product’s active life; piracy and cheating effectively blocked.
    • Xbox security team explicitly aimed to make physical attacks cost more than ~10 games; by that metric they “won.”
  • Some argue the long delay also reflects lower attacker incentive: few true exclusives, strong PC overlap, and official dev mode for homebrew.

How the Hack Works (Voltage Glitching)

  • Uses power‑rail “voltage glitching”:
    • Carefully timed double glitches during early boot to (1) skip MMU init, then (2) hijack control during a memcpy, gaining code execution in the immutable boot ROM path.
  • Microsoft mitigations included:
    • Randomized delay loops, disabled debug/status readouts, hash‑chained boot stages, user/kernel‑like separation, and rail monitoring.
  • Commenters note fault injection is an old technique (smartcards, satellite TV, prior Xbox 360 “reset glitch”), but this is a particularly sophisticated application.
  • Consensus: defending against precise hardware fault injection with full physical access is extremely hard; you can only raise cost and delay success.

Homebrew, Emulation, and Practical Impact

  • Xbox One already had an official dev mode with side‑loaded apps (emulators, Kodi, homebrew).
    • Criticisms: memory limits, ID requirements, bans blocking dev mode; some prefer an unrestricted hack.
  • New exploit enables highest‑privilege unsigned code, opening:
    • Potential modchips (though only for early units, with legal/distribution hurdles).
    • Better game dumping, preservation, and perhaps improved emulation (including Xbox 360/OG titles enhanced on Xbox One).
  • Several users plan to repurpose cheap used launch consoles as Linux/homelab boxes.

Security, Ownership, and Future Platforms

  • Thread reiterates: security is not binary; delay and cost are valid goals.
  • Debate over efuses and secure boot:
    • One side: ubiquitous and needed to prevent dangerous firmware rollback.
    • Other side: they lock owners out; secure boot that only the vendor controls “should be illegal.”
  • Concern that techniques pioneered on consoles (secure elements, attestation) flow into phones, PCs, and cloud, potentially eroding general‑purpose computing.
  • Comparison with Azure:
    • Console is designed to survive hostile physical custody by users.
    • Azure Government relies more on physical controls, tamper‑resistant hardware modules, and data‑center procedures; very different threat model.