Xbox 360のハイパーバイザを標的とした「Bad Update」エクスプロイトは、低速で信頼性の低い概念実証から、極めて効率的な攻撃へと移行するために重要な技術的改良が行われました。当初、このエクスプロイトはエントリーポイントとして物理的なゲームディスクを必要とし、成功率も低いものでした。しかし、2つの主要なコミュニティの貢献によって状況は変化しました。一つは、Rock Band Blitz (RBB) のデモ版における新しいゲームセーブのエントリーポイントの発見であり、もう一つはハイパーバイザのレースコンディションの最適化です。RBBのDLC解析コードにおけるメモリ破損を悪用することで、攻撃者は現在、USBメモリを介してエクスプロイトチェーンをブートストラップすることができ、物理ディスクの必要性がなくなりました。

元の概念実証における主要な技術的障害の一つは、単純な暗号文ルックアップテーブルの失敗でした。Xbox 360は12ビットのホワイトニング値を持つメモリ暗号化スキームを使用しており、任意の平文に対して1024通りの暗号文の組み合わせが存在します。著者の初期のルックアップテーブルの使用は、新しいハイパーバイザのビルドにおいて、ハイパーバイザ関数内の特定のTranslation Lookaside Buffer (TLB) フラッシュが削除されたために失敗しました。著者がカーネルラッパーをスキップしてハイパーバイザシステムコールを直接呼び出したため、ホワイトニングビットが古くなり、無効な暗号文の読み取りが発生しました。この古いハイパーバイザと新しいハイパーバイザの挙動の違いは、初期のエクスプロイトの不安定性における決定的な要因でした。

ハイパーバイザのTLBフラッシュ機構を示す技術的な図または図解。
ハイパーバイザのTranslation Lookaside Buffer (TLB) フラッシュ挙動の視覚的表現。icode4.coffee

この画像は、元のエクスプロイトの不安定性を引き起こしたTLBフラッシュに関する特定のハイパーバイザの挙動を説明しています。

「invalid write detected」というエラーメッセージを示すスクリーンショットまたは図。
初期の概念実証中に遭遇した「invalid write detected」エラーの例。icode4.coffee

この図は、暗号文ハッシュテーブルが実装される前の、元のエクスプロイトの失敗状態を示しています。

これを解決するために、現在のエクスプロイトは悪意のある暗号文の値を事前計算して保存するハッシュテーブルを利用します。システムは1024回の反復を行い、すべての可能なホワイトニングビットを使い果たし、各暗号化割り当てに対してTLBエントリを手動でフラッシュすることで、正しいホワイトニング値がキャプチャされることを保証します。期待される暗号文の最初のNビットがテーブルのインデックスとして機能します。より大きなハッシュテーブルはより多くのメモリを消費しますが、キーサイズは衝突を最小限に抑えつつ、過度なCPUキャッシュのスラッシングを避けるように選択されました。XKEペイロードと暗号文上書きスレッドの間の改善されたスレッドスケジューリングと組み合わせることで、これらの最適化により実行時間は数秒に短縮され、ほぼ100%の成功率を達成しました。ただし、これらの最適化の有効性は、メモリオーバーヘッドとCPUキャッシュ圧力の間の微妙なバランスに依存しているため、特定のハードウェアのキャッシュ挙動に左右されます。