Appearance
第8章 Xboxセキュリティのリバースエンジニアリング
本章では、第6章で最初に遭遇したXboxセキュリティシステムの初期製品バージョンを、僕がどのように打ち破ったかを説明する。このセキュリティシステムは、フラッシュROMを解析してハードウェア初期化とブートイメージの復号シーケンスがフラッシュROMの外側に隠されていると気づいたことで発見した。第7章では、本章の内容を理解するうえで役立つ基本的な暗号技術の概念を紹介した。
ハードウェアから秘密情報を取り出す
第6章で結論づけたとおり、Xboxに隠されたブートコードは次の三つのバスのどれかを盗み聞きすることで取得できる。（1）フロントサイドバス（FSB）、（2）メインメモリバス、（3）ノースブリッジとサウスブリッジ間の接続だ。
XboxのPentiumプロセッサが使用するフロントサイドバス（FSB）の仕様は、IntelのデベロッパーサイトにあるPentium IIIプロセッサのデータシートに記載されている。FSBは双方向64ビットのデータバスで、約50本のアドレス・制御信号を持ち、すべて133 MHzで動作する。使用する信号規格はAGTL+と呼ばれるものだ。信号数が多く物理的な接続も難しいため、このバスの盗み聞きは費用と労力のかかる作業だ。現実的な手法は二つある。（a）数千ドルもする特殊なエミュレータ用ブレークアウトソケットにプロセッサを載せる方法、または（b）XboxマザーボードのFSB配線をリバースエンジニアリングし、100本近い信号それぞれに短いプローブ線をはんだ付けする方法だ。いずれの場合もAGTL+信号規格に対応したロジックアナライザが必要になる。これらの条件が重なったため、盗み聞きの出発点として別のバスを探すことにした。
次の候補はメインメモリバスだ。128ビットのデータバスにアドレス・制御信号を加えたもので、200 MHzのダブルデータレート（DDR）クロックで動作する。使用する信号規格はSSTL-2だ。（詳細はSamsung ElectronicsウェブサイトにあるSamsung K4D263238Mのデータシートを参照。）速度は高いが、Xboxマザーボードにはメモリのスペアフットプリントが設けられているため、FSBよりも盗み聞きしやすいかもしれない。
標準的な安価な100ピンTQFP（薄型四角フラットパック、100本のガルウィング型ピンを持つ矩形チップパッケージ）アダプタをこのスペアフットプリントにはんだ付けすれば、ロジックアナライザを接続するプローブポイントとして使える。ただし、この手法ではメインメモリに書き込まれたデータしかキャプチャできない。復号鍵は一般に読み取り専用データであり、隠しブートROMからプロセッサのキャッシュに直接転送されてメインメモリには格納されない。プロセッサが鍵を含むキャッシュラインの処理を終えると上書きされるため、鍵はプロセッサの物理的な境界を出ることがない。
📦 コラム：高速デジタル信号伝送についてもっと詳しく
コンピュータバス上のデータを盗み聞きしたり改ざんしたりするのは強力な技術で、対策が難しい。盗み聞きを理解するには、コンピュータ内部でデジタル情報がどのように伝送されるかの基礎知識が必要だ。
信号方式は大きく二つに分けられる——シングルエンド信号と差動信号だ。ワイヤ上でデジタル情報を伝送するには、電圧や電流といった物理量への変換が必要だ。古典的な方式では、「グランド」と呼ばれる共通の基準電位を基準に電圧を定義する。これをシングルエンド（非平衡）信号と呼ぶ。ただしこの方式は、信号の変化が伝搬時間に対して遅い場合にしか機能しない。実際には、電位の変化は電流の流れを伴う。電流は保存されるという自然の法則により、ある方向に電流が流れれば、逆方向にも必ず電流が流れなければならない。シングルエンド信号では、この逆向き電流（リターン電流）はグランドを通って戻るが、高速では信号電流と異なる経路を通ることがある。この不均衡が信号の歪みを引き起こす。
差動信号はこの問題を解決する。信号電流用と明示的なリターン電流用の2本のワイヤを使うことで、信号路とリターン路を平行に配線でき、電流の流れが均衡する。配線数は2倍になるが、より安定した信号伝送が実現できる。
電圧を論理値に対応させる規格を信号規格という。古くからあるTTLや3.3V CMOSの信号規格は、トランジスタの性能が低く大きな信号振幅が必要だった時代に考案された。近年はSSTL（シリーズスタブ終端論理）、GTL（ガニング・トランシーバ・ロジック）、LVDS（低電圧差動信号）、PECL（擬似エミッタ結合論理）など多様な信号規格が広まっている。これらの高速信号規格は二つの事実に対処している。一つは、電気信号の波はデータ伝送レートに比べて遅く伝わること。もう一つは、伝送路の終端でエネルギーを消費する必要があり、消費されなければ反射が生じて入射信号に干渉することだ。
高速アプリケーションでは、ワイヤをしばしば「伝送線路」と呼ぶ。信号遷移時間（信号が「1」と「0」の間を遷移するのに要する時間）に比べて信号の伝搬が遅いという事実を強調するためだ。（速度の比較は信号の動作周波数ではなく、遷移時間に対するものだ。）よくある誤解は、クロック周波数が低ければ伝送線路の効果を無視できると考えることだ。年に1回しか遷移しない場合でも、その遷移が1ピコ秒（1兆分の1秒）で完了するなら問題が生じることがある。
初心者にとっての朗報は、XilinxなどのベンダーのFPGAには広く使われているほぼすべての信号規格への対応が組み込まれていることだ。また、信号規格のドキュメントが充実してきているのも朗報だ。XilinxのFPGAデータシートには、対応するすべての信号規格について終端抵抗の位置と値が図解されている。データシートとアプリケーションノートの推奨事項に従えば、FPGAを使って幅広い信号を盗み聞きできる。タップをできるだけ短くすることだけ忘れなければ問題ない。
3番目の候補はノースブリッジとサウスブリッジ間の接続だ。それぞれ1本の制御信号と1本のクロック信号を持つ、8ビット幅の単方向差動バスのペアだ。信号規格はHyperTransportで、DDRクロッキングにより200 MHzで動作する。このバスの信号規格は、Xboxのチップセットとゆかりの深いNVIDIAのnForceに関するNVIDIAウェブサイトの公開情報から推測した。その後、HyperTransportコンソーシアムのウェブサイトで公開されているHyperTransport仕様と照合しながらオシロスコープで数回測定し、HyperTransportの信号規格が実際に使われているという仮定を確認した。
HyperTransportバスはXboxのマザーボード上ですべての信号が平行かつ等間隔に配線されており、バスの高い動作速度が要因の設計判断だろう。これはバスを盗み聞きの格好のターゲットにするが、データレートが非常に高い点が難点だ。この速度のバスを盗み聞きするには、信号インテグリティを保つためにタップ配線のスタブ長に特別な注意が必要で、高価なロジックアナライザかカスタムのアナライザ回路も必要になる。
最終的に、最初に盗み聞きするバスとしてノースブリッジとサウスブリッジ間の接続を選んだ。配線数がずば抜けて少なく、はんだ付けの作業量が最小で済むからだ。ノースブリッジとサウスブリッジ間の接続には固有の信号が10本しかないが、FSBとメインメモリはそれぞれ約100本の信号がある。はんだ付け箇所が多いと時間がかかるだけでなく、はんだブリッジや配線パターンの損傷によるハードウェア故障のリスクも大幅に高まる。はんだ接続の数を最小限に抑えることで、マザーボードへの副次的なダメージリスクを減らせる。
高速バスの盗み聞き
2002年1月下旬、HyperTransportの盗み聞きアプローチに取り組む決意をした。この手法には三つの大きな技術的課題があった。
- 信号インテグリティを損なわずに高速差動バスにタップを接続すること
- HyperTransportバスの400 MB/sというデータレートに追いつけるロギングツールを探すか自作すること
- マザーボード上の差動HyperTransportバス配線の極性とビット順序を特定すること
予算内でのバスタップ
最初の二つの課題は密接に関連している。高速バスの解析・ロギングツールには独自のインターフェースがあることが多く、Xboxのマザーボードへの接続にはカスタムアダプタが必要になる。最後の課題——ビットの極性と順序の特定——は、データロガーを接続して動作させた後、大量の後処理とデータ解析で解決できる。
HyperTransportは業界で広く受け入れられたオープン標準なので、市販のプロトコルアナライザやロギングツールが利用できる。その一例がFuturePlusのHyperTransportプロトコルアナライザだ。ただし、作業当時このプロトコルアナライザの価格は25,000ドルを超えていた。さらに、ターゲットボードをアナライザのバスインターフェースポッドに合わせて特別に設計する必要もある。
プロトコルアナライザを購入してXbox向けに改造する手間をかける代わりに、自前の簡易版を自作した。HyperTransportプロトコルはかなりシンプルなので、これは実現可能だった。XboxのHyperTransport実装は、送信用と受信用の8ビット単方向バスを二つ使っている。各バスにはクロックとストローブ線がある。この信号規格では、クロックの各エッジで有効なデータを送出する必要がある。新しいパケットの始まりはデータ線がアイドル状態から抜け出すことで示される。ストローブ線はコマンドパケットとデータパケットを区別する。他のバスで典型的なサイドバンド信号——アドレス、読み書き制御、チップセレクト、割り込み線など——は、HyperTransportではインバンドコマンドパケットで処理される。つまり、バスを盗み聞きするのに必要なのは10本の差動信号（20本のワイヤ）だけだ——ハッカーにとって最高の朗報だ。
HyperTransportプロトコル自体はシンプルだが、Xboxバスに物理的に接続でき、かつ400 MB/sの速度に追いつけるものをどう見つけるかが問題だった。このHyperTransportバスタップの構築に理想的なツールはFPGAだろう。しかし当時、高速データレートに対応できるFPGAは存在せず、さらに重要なことに、ベンダーからHyperTransport用として認定されたFPGAも存在しなかった。
理論上、Xilinx Virtex-II FPGAはこの用途に使えたはずだが、製品が発売されたばかりで非常に高価かつ入手困難だった（現在、ローエンドのVirtex-II FPGAは100ドル以下で購入できる）。当時手元にあった最良のFPGAは、修士論文の一環として試作したスーパーコンピュータ用ネットワークルータに組み込んだXilinx Virtex-E FPGAだった。そのネットワークルータボードはネットワークインターフェースにCTT（センタータップ終端）の信号規格を使っており、設定・制御・デバッグ用のIntel StrongArmプロセッサも搭載していた。
課題は、HyperTransport信号をCTT信号にインターフェースする方法と、本来そのスピードで動作するよう設計されていないFPGAから400 MB/sの性能を引き出す方法を解決することに集約された。
HyperTransportの信号規格は、TIA/EIA-644規格で定められたLVDS（低電圧差動信号）の近縁だとわかった。HyperTransportドライバは通常、コモンモード電圧600 mVを中心に差動スイング600 mVの信号を生成する。一方、LVDSレシーバは差動スイングが100 mVを超え、コモンモード電圧が50 mVから2.35 Vの範囲にあるデータを正しく受信できる。つまり、LVDSレシーバはHyperTransportドライバと直接互換性があるのだ。（Virtex-EはLVDS信号への直接インターフェースをサポートしているが、手元のVirtex-EはすでにCTT信号用にハードワイヤードされたシステムに組み込まれていたため、その機能を利用できなかった。）自分でタップボードを設計するなら、ここで述べるハックではなく、FPGAのネイティブLVDS機能を使うのが最善策だ。
📦 コラム：HyperTransportへの信号注入
本章で説明する盗み聞きアプリケーションはHyperTransportのレシーバのみを必要とする。「中間者（man-in-the-middle）」攻撃のようなアプリケーションでは、HyperTransportの信号をオーバーライドして偽のビットを挿入できるデバイスが必要になる。HyperTransportはLVDSと同様に電流モードドライバを使っているため、これは実現可能だ。ドライバは生じる電圧に関係なく、一定量の電流をワイヤに流すよう設計されている。通常の状況では、ワイヤのインピーダンスがオームの法則に従って電流を電圧に変換するため、これは完璧に機能する。しかし電流は足し合わさったり打ち消し合ったりする。意図された信号を打ち消すオーバードライブ電流を加える拮抗差動ドライバをHyperTransportラインに接続できる。このオーバードライブは、Xilinx Virtex-EやVirtex IIなどのFPGAが提供する柔軟でプログラマブルなI/Oを使って実現できる。
このバスオーバーライドデバイスの最も単純な応用は、リセットベクタがCPUに送信される際にその送信先を変更し、Xboxの制御を奪うものだ。リセットベクタの送信先は、
0xFFFF.FFF0にある「ジャンプ」オペコードに続く1バイトにコード化されている。リセットベクタはリセット解除から確定的なクロック数後に送信される可能性が高いため、この攻撃のタイミング要素は、HyperTransportバスクロックでクロッキングされリセット信号に同期したタイマーだけで実現できる。このような「中間者」攻撃は、暗号学的に安全な公開鍵ブートブロック実装さえも無力化する。
また、信号を劣化させないために、LVDSレシーバはXboxのマザーボードにできるだけ近い場所に配置する必要がある。ケーブルが長いとワイヤからエネルギーが逃げ、ノイズや反射が発生してシステムが動作しなくなるおそれがある。
HyperTransport信号をFPGAに届ける問題の解決策は、信号変換チップを使うことだ。LVDSはLCDパネルインターフェースや通信システムのバックプレーンで広く使われているため、安価なLVDS-CMOSコンバータが多数入手できる。目的の信号規格はCTTだが、よく見るとCMOSドライバをCTTレシーバにインターフェースすることは実は問題ない。CTTは1.5 Vで終端された50 Ωの伝送線路に+8 mAまたは-8 mAを流す電流モードの信号規格だ。レシーバは基準終端電圧と伝送線路の電圧を比較する差動アンプだ。Virtex-EのCTTレシーバアンプは、受信電圧が基準電圧から200 mV以上スイングする限り動作するよう仕様が定められている。標準CMOSトランスミッタはCTT終端ラインを駆動する際、8 mAの電流をソース／シンクできる。また固定電圧で終端されたラインを駆動することも問題ない。したがって、標準的なLVDS-CMOSコンバータチップを使って、XboxマザーボードのHyperTransport信号を論文用に自作したボードに入力できる。選んだチップはTexas InstrumentsのSN65LVDS386で、データシートはTexas Instrumentsのウェブサイトで入手できる。
LVDS-CMOSコンバータチップをボードに接続する作業は、XboxマザーボードのHyperTransportバスのクリーンなレイアウトのおかげで驚くほど簡単だ。図8-1はHyperTransportバス配線の写真だ。すべての線が平行に等間隔で走っているのがわかる。クロック（TX CK/TX CX* と RX CK/RX CX*）やストローブ線（TXD8/TXD8* と RXD8/RXD8*）など一部の線には極性マークまで付いている。このシンプルなレイアウトのおかげで、タップボードの設計と製作が容易になる。
図8-1: XboxマザーボードのHyperTransportバス配線パターン。
タップボードに必要なのは、LVDS-CMOSコンバータチップ、電源調整回路、そしてXboxマザーボードのHyperTransportバスと同じ間隔でボードの端まで引き出した配線パターンだけだ。正確な間隔を実現するために、デジタルキャリパーでこれらの配線の寸法を計測した。図8-2にHyperTransportバス配線の寸法を示す。
図8-2: XboxマザーボードのHyperTransportバス配線の寸法。1ミル（mil）は1インチの1/1000（25.4マイクロメートル）。
この計測は少しトリッキーだった。バス全体の幅を計測し、配線数とスペース数で割って平均的な間隔と配線幅を求めた。次に、PCB CADプログラムでこれらの配線をレイアウトし、1:1スケールで紙に印刷した。印刷した配線とボードの配線を見比べながら手で微調整した。（多くのプリンタには多少のスケーリング誤差があるため、試す場合はまず既知の長さの線を何本か印刷して計測し、誤差を確認すること。プリンタは水平方向と垂直方向で異なるスケーリング誤差を持つことがあるので、両方向で確認すること。）
適切なソフトウェアがあれば、オリジナルのボードを設計するのはそれほど難しくない。詳しくは付録C「PCBレイアウト入門」を参照。
部品の選定が終わると、HyperTransportタップと信号変換ボードの設計とレイアウトにはさらに数時間しかかからなかった。ボードの回路図は図8-6に示す。その後、インターネット経由で発注してボードを製造した。多くの基板製造業者はGerberファイル形式のボード設計データをメールやFTPで受け取り、手頃な価格でクイックターン製造サービスを提供している。今回は5日間で1枚あたり33ドルで2枚製造した（詳細は付録C「PCBレイアウト入門」参照）。この価格はボードを四角く切り出す費用のみを含む。ただし、HyperTransportタップのある側の形状を特殊にする必要があった。Xboxマザーボード上の既存の部品に干渉せずに取り付けられるよう設計するためだ。また、タップボードをマザーボードにはんだ付けする作業を容易にするために、接合側のエッジをわずかに傾斜（ベベル）させる必要もあった。図8-3に示す形状になるようベルトサンダーで手作業で削り出した。削り出す際は、ベルトサンダーの研磨ベルトがボードの配線面から先に当たるよう向きを調整して、銅の配線パターンが剥がれないようにした。タップボードのような小さなボードをベルトサンダーで削るときは注意が必要だ——うっかりすると指まで削れてしまう。
ベベルエッジの削り出しが完成したら、ボードにすべての部品をはんだ付けした。（付録B「はんだ付け技術」参照。）
図8-3: HyperTransportタップボードのエッジの形状。
図8-4: タップボードのはんだ付け手順。
完成したタップボードをXboxのマザーボードに接続する必要があった。この重要なステップがおそらく最も難しかった。まず、Xboxのマザーボードを細かい目の紙やすりではんだレジストを剥がし、ターゲットとなる配線の素銅を露出させた。その後、これらの配線にフラックスを塗り、熱したはんだごての先で薄くはんだを乗せた。
タップボードをマザーボードに接続するための手順を図8-4に示す。準備したタップボードを、タップボード上の配線とマザーボードの間に30 AWGの細い線を一本はんだ付けして、大まかな位置と角度でマザーボードに仮固定した。この仮固定線は一時的な保持手段として使うだけで最後は取り外すので、複数の配線をまたいでいても問題ない。線を付けたら、銅の配線を浮かせないよう線を熱して接着を解きながら、マザーボード上のタップボードの位置を慎重に微調整した。（最適な位置合わせを確認するために顕微鏡を使った。）ボードの位置に満足したら、接合部に強力なエポキシを塗布してすべてを固定した。エポキシは硬化して堅固な接合部を形成する必要がある。（エポキシを正しく使わないとゲル状に硬化するものがあるが、接合部の機械的な強度は完全にエポキシで確保しなければならず、はんだ接合部に頼ってはいけない。）使用したのはMiller-Stephensonエポキシフォーミュラ907で、タップボードを持ってXboxを持ち上げてもタップ接続が乱れないほどの強度で硬化する。
エポキシが硬化したら、仮固定線を取り除き、素銅の接合面をはんだ吸い取り線とフラックスで少し清掃した。タップボードの配線をマザーボードの素銅配線にはんだ付けする最終ステップは、表面実装部品をボードにはんだ付けするのと変わらない。付録Bで説明する標準的なはんだ付け技術がほぼそのまま使える。図8-5に完成したアセンブリの外観を示す。
図8-5: XboxマザーボードにマウントされたHyperTransportタップボード。
データロガーの構築
HyperTransportバスの盗み聞きの二つ目の課題は、バスの400 MB/sデータレートに追いつけるロギングデバイスを入手するか自作することだ。十分な性能を持つツールを購入するのは完全に予算外だったため、自作するしかなかった。
ロギングデバイスの構築には、以前自作したボードに組み込んだVirtex-E FPGAを使うことにした。ただし、Virtex-E FPGAを使う上での問題は、データブック上の性能仕様がHyperTransportバスに追いつくには不十分な点だ。幸い、FPGAは製造マージンが保守的で、設定可能な配線ファブリック内の信号伝搬遅延が性能の主な制約要因になっているため、オーバークロックが良好に機能する。そのため、性能を制限している主要なパスをいくつか手動で特定し、ソフトウェアによるディレイラインとクロックの選択的な反転で補正できる。性能上最重要なブロックは遅延を最適化するために手動配置し、コンパイラと自動配置配線ツールに非重要な部分を任せた。図8-7にHyperTransportバスのデータをキャプチャするために使った全体設計を示す。
図8-6: HyperTransportタップボードの回路図。
図8-7: Xilinx Virtex-E FPGAに実装したデータロガーのブロック図。
設計の概念はシンプルだ。HyperTransportバスから高速データを取り込み、1/4速度クロックの4位相でクロッキングして、4倍遅いが4倍広いデータストリームを生成する。これにより、手動配置と微調整を最初の数段の入力フリップフロップだけに限定できる。次に、遅延器とローテータのセットでデータを再整列し、先入れ先出し（FIFO）メモリに一度に一つずつ格納する。FIFOキャプチャ開始のトリガー信号は、最初のリセットからカウントアップを始めるタイマーコンパレータで生成する。複数のランの結果を連結することで長いウィンドウのデータをキャプチャできる（各ランでキャプチャトリガー点を前のランからずらす）。後でトリガー回路に追加した最適化は「ゼロを格納しない」（DNSZ：Do Not Store Zeros）機能だ。DNSZモードでは、すべてゼロのデータはFIFOに格納しない。HyperTransportバスのアイドルデータを除外するのに有効だ。出力されるデータトレースは、タイムスタンプ付きの32ビットワードのシリーズだ。
FPGAデータロガー設計の最も難しい部分は、入力パスの遅延のキャリブレーションだった。キャリブレーションは、オシロスコープを使ってHyperTransportバス上の小さなウィンドウのデータをプローブすることで行った。プローブデータとログデータが一致するまで、配線遅延とバイト単位の回転を調整した。アイドル時に数百マイクロ秒ごとにバス上で共通のコマンドシーケンスが繰り返されており、これがキャリブレーションの基準として役立った。
バスの順序と極性の特定
データのロギングが完了した後の最後の課題は、HyperTransportバスの信号の順序と極性を解明することだ。Xboxマザーボード上のHyperTransportバスの最重要な2本の信号はラベルが付いているが、残りの8本のデータ線は極性とビット順序が不明だ。
8本のデータ信号の正しい極性は、アイドル状態のバスデータのビットパターンを観察することで特定した。HyperTransportバスはほとんどの時間アイドル状態なので、これは難しくない。アイドルパターンがすべて0であるべき場合、1として現れるビット位置は極性が反転している。これはFPGA内の対応する配線に反転項を挿入することでハードウェアで修正した。
しかし、正しいビット順序の特定はずっと難しい。HyperTransportバスを通るデータの多くはフラッシュROMから来るという仮定のもと、バイトごとに1のカウントを行った。理論は、バスの順序は純粋な並べ替え（permutation）であり、バイト中の1のビット数はフラッシュROMのデータとロガーでキャプチャしたデータ間で保存されるというものだ。1のカウントのパターンを照合して、フラッシュROMとログデータ間の対応する候補領域を特定した。幸い、HyperTransportバスを最初に通るデータはフラッシュメモリの底部近くにあるチップセット固有の初期化データなので、正しく一致するパターンを見つけるのにそれほど時間はかからなかった。各ROMとロガーのバイトのセットを表に並べ、短いCプログラムの助けを借りて、すべての行の値が一致する順序が見つかるまでビットの列を入れ替えた。
キャプチャデータの解読
有効なデータトレースが取れたところで、残る問題はその意味を解読することだ。解読の前に、これまで収集したデータについてわかっていることを整理しておこう。
時間的相関：ログデータは大局的に見て、想定される初期化イベントのシーケンス——ジャムテーブルの初期化、続いて復号ステップ、RAMからの実行——と強い時間相関を持つはずだ。各イベントに対応するログトレースの領域は、大きなアクティビティのバーストが発生してその後に無音の領域が続く時点を観察するだけで特定できる。
トランザクション長：Pentiumプロセッサにはデータキャッシュと命令キャッシュの両方があるため、HyperTransportバス上でのフラッシュROMや隠しブートROMへのすべてのフェッチは、偶数長のトラフィックバーストとして現れるはずだ。
確定的な順序：収集したデータはタイムスタンプが付いており時系列的に正しいため、リセットベクタで最初にフェッチされる命令をデータログで特定できれば、残りの命令の位置と構造を推測できる。
最初、HyperTransportバスを通るデータの大局的な構成を確認することを怠ったため、いくつかの問題が生じた。図8-7のロギングマシンの簡略ブロック図では、HyperTransportバスがリセットされるたびにログFIFOもリセットされる。これは良いアイデアに思えたが、もともと電源投入時にHyperTransportバスは一度しかリセットされないと誤って思い込んでいた。実際には、ジャムテーブルの初期化ステップの後にHyperTransportバスが二度目のリセットを受ける。そのため、最初にトレースを見始めたとき、暗号化データとわずかなコードの断片しか見えず、ブートベクタと論理的に対応付けられるものが何もなかった。
これがどれほどがっかりすることか！一歩引いて、オシロスコープのタイムスケールをミリ秒/分割に設定してHyperTransportバスのイベントを観察した。より早い段階のリセットパルスがあることに気づき、最初のパルスだけをキャッチするようトリガー機構を調整したところ、ブート命令が簡単に特定できた。秘密ROMの0xFFFF.FFF0にある16バイトは、フラッシュROMの同じ16バイトと偶然一致していた。そこから、各命令ブロックをメモリ上の正しい位置に配置できるよう、地道なトレースと逆アセンブルを大量に行いながらプログラムカウンタの現在値を追跡した。キャッシュラインのフェッチは毎回連続する16または32バイトのメモリで構成されており、独特のデータロガータイムスタンプパターンを生成してリバースエンジニアリングの助けになった。
キャッシュラインを探してトレースを数時間精査した後、ディスアセンブラに入力するのに十分なコードを収集した。（使用したディスアセンブラの詳細は後述のコラムを参照。）
📦 コラム：ソフトウェア解析ツールについて
ハッキング経験を積む中で、必ずどこかでアセンブリ言語コードを逆アセンブルする必要が出てくる。2002年1月、Xboxのセキュリティをリバースエンジニアリングしていた時、仲間のソフトウェアハッカーたちからこの作業に最適なツールを教えてもらった。それがIlfak GuilfanovによるIDA Proで、DataRescue Corporationが販売している（http://www.datarescue.com/idabase/）。IDA Proはx86コードだけでなく、実に多様な組み込みプロセッサのコードも逆アセンブルできる。IDA Proの出力品質も非常に高く、コードセグメントは自動的に注釈付けされ、読みやすく整理される。IDA Proには多数の便利で楽しいツールも搭載されている。僕のお気に入りは、コードライブラリのシグネチャを関数呼び出しに自動的にパターンマッチングする機能と、キーを押すだけでジャンプをたどる機能だ。
コード解析で非常に役立ったもう一つのツールはHackManだ。HackManはTechnoLogismiki Corporationのフリーウェアだ（http://www.technologismiki.com/hackman/）。名目上は「ヘックスエディタ」、つまりバイナリデータを直接操作できるファイルエディタだが、単純な編集をはるかに超えた多くのユニークな機能を持つ。たとえば、HackManには逆アセンブラが内蔵されている。IDA Proほど強力ではないが、ヘックスエディタとインタラクティブに連携する。データログをトレースしながら候補のキャッシュラインを有効なコードかどうか素早くテストし、秘密ROMの最終的なバイナリイメージを組み立てる際に役立った。
データの後処理とオンラインのハッカー仲間の大いなる助けを借りて、使われている暗号がRC-4/128だと特定した。RC-4は対称暗号なので、鍵はXboxのどこかに保存されているはずだ。しかしデータストリームで鍵を特定しようとしていたが、なかなかうまくいかなかった。鍵は当時は明確な位置に対応付けられないコードの断片と共有されたキャッシュラインフェッチにまたがっているようだった。
夜が更け、16進数を見つめることに疲れてきた頃、絶対に成功しないはずのことを試してみることにした。データログ内のスライディングウィンドウから導出した鍵を使ってフラッシュROMのターゲットイメージを復号するRC-4復号プログラムを改造した。これはかなりブルートフォースな手法で、データストリーム全体を検索するには数万回の復号（ログの各バイトに対して1回ずつ）が必要だ。RC-4復号の出力をヒストグラムルーチンに入力することで処理を自動化した。鍵が一致しない場合、出力は統計的に「ホワイト（一様）」になるはずだ——一致しない鍵ではすべての値が概ね同じ確率で現れるはずだ。しかし鍵が正しいなら、ヒストグラムに偏りが現れ、他の値よりも突出して多い値が出てくるはずだ。
最終的に、午前5時頃にこのブルートフォース検索を行うプログラム「trykeys」を完成させた。目をしょぼつかせ疲れ果てながらも、今夜の作業を終える前にテスト実行してみることにした。プログラムが候補データストリームを処理し続ける出力を見て、僕がどれほど呆然としたか想像してほしい。
$ ./trykeys.exe ms4.bin binout.full
.............................................................
.....................found possible key combo: avg 96, min 5,
offset 8745..................................................
..............................................................フラッシュROMイメージはms4.bin、バイナリデータロガートレースはbinout.fullという名前だ。trykeysプログラムは、オフセット8745から始まるデータをテスト鍵として使ったROMイメージの復号で、統計的に異なるヒストグラム（平均値96、最小バケット高さ5）を識別した。データストリームから候補鍵を取り出し、候補鍵を使って復号出力を解析した。出力は本物の有効なコードのように見えた。隠しブートセクタの鍵を見つけた——サウスブリッジチップに保存されていた！数日後、睡眠を取って学業に追いつき、データストリームの適切な解析を完了させ、秘密ブートセクタ全体のイメージを組み合わせた。
秘密ブートコードのRC-4鍵を手に入れたことで、当時のすべてのXboxが受け入れるフラッシュROMイメージを生成できるようになった。これはXboxのトラスト（信頼）メカニズム全体が、マザーボード上のROMをオーバーライドするか交換するだけで侵害できることを意味する。これはMicrosoftが製造中のテストと診断目的でフラッシュROMをオーバーライドするために提供しているテスト構造を使って実現できる。Xboxは数秒に1台のペースで生産ラインから出荷しなければならないため、MicrosoftはフラッシュROMのオーバーライドを可能にするクイック接続テストポイントのセットを設計していた。
📦 コラム：ハッキングの法的課題
振り返ってみると、Xboxのハッキングで本当に大変だったのは技術的な部分よりも、社会的・法的な部分だった。サウスブリッジチップから秘密鍵を取得した後、MIT人工知能研究所の研究指導教員であるTom Knight教授と面会して結果を議論した。僕の研究はDMCA（デジタルミレニアム著作権法）に違反する可能性があると指摘され、発表前にMITの法務部に相談した。MITの法務部は最終的に、DMCAによってリスクが高すぎるため、コンピュータアーキテクチャ研究の一環としてMITで行った研究にもかかわらず、個人として発表しなければならないと回答してきた。弁護士費用を払えず、研究を発表できないかもしれないと絶望したが、その時Hal Abelson教授が電子フロンティア財団（EFF）につないでくれた。その結果、EFFとボストンカレッジのLee TienとJoe Liuが僕の研究発表を支援してくれることになった。
その後、数ヶ月にわたる審議と交渉が続いた。二つの戦線での戦いだった——Microsoftを宥めながら、MITに研究を受け入れさせなければならなかった。4ヶ月後、Microsoftによる好意的な研究レビューと、研究室の同僚と教授たちの圧倒的な支持を受けて、MITが折れた。MITは独立した個人としてではなく、MIT学生として研究を発表できると決定した。5ヶ月の法的な膠着状態の結果、AI研究所のテクニカルメモランダムが作成され、続いて2002年8月の暗号化ハードウェアと組み込みシステムに関する国際会議（CHES：Cryptographic Hardware in Embedded Systems）での学術発表につながった。
この話には一応のハッピーエンドがあるが、指導教員、研究室、そしてEFFの優れた弁護士たちの支援がなければ、まったく違う結末になっていた可能性がある。DMCAは不正なハッカーと正当な研究者の間に曖昧な線を引く。MITの支持がなければ、DMCAの研究免除条項を満たせなかったかもしれず、研究が発表されることなく終わったか、発表されたとしてもMicrosoftに異議を唱えられていたかもしれない。言論の自由はすべての人に適用される——名門学術機関の象牙の塔に座る幸運な人たちだけのものではない。Xboxに取り組み、優れた成果を上げていた人は無数にいたが、彼らの声はDMCAの幕の裏に永遠に封じ込められている。
代替ROMイメージは、ネイティブのXbox CPUを使って製造テストプログラムを実行するのに役立つ。XboxのLPC（Low Pin Count）インターフェース実装の物理的な構造により、ユーザーもMicrosoftの製造委託業者も、はんだ付けなしで適切に設計されたフラッシュROMオーバーライドデバイスを取り付けられる。
明らかに、Xboxのトラストメカニズムをオーバーライドする能力には厄介な法的含意がある。僕の意図は主に好奇心を満たすことと、次にフェアユースの権利のもとで自分のコードをXbox上で実行することだったが、他の人はゲームをコピーしたり、Microsoftの著作権で保護されたカーネルコードを改変・再配布したいと思うかもしれない。暗号はその応用を選ばないので、RC-4鍵の抽出はすべての用途に等しく使えてしまう。そのため、法的な問題を整理するために電子フロンティア財団（EFF）に連絡した。法的プロセスは遅くて重たいものだ。鍵を取得したのは2002年2月だったが、適切な学術フォーラムで研究成果を発表する許可が下りたのは6月近くになってからだった。
たった128ビットのためにこれほど大騒ぎになるとは思ってもみなかった。1998年のデジタルミレニアム著作権法（DMCA：Digital Millennium Copyright Act）は、ハードウェアハッキングの景色を永遠に変えた。リバースエンジニアリングはかつて保護された行為であり、健全で競争的な市場を構成する一部と見なされていた。今では、フェアユースの権利を行使するために自分の家の中で暗号セキュリティシステムをいじって回避するだけで、数千ドルの罰金と訴訟に直面する可能性がある。第12章「注意せよハッカーよ」を読んで、自分の法的権利と責任を理解することを強くお勧めする。
📦 コラム：隠蔽によるセキュリティ
Xboxセキュリティの初版でMicrosoftが使った技術は、隠蔽によるセキュリティ（security through obscurity）の典型例だ。強力な暗号であるRC-4/128を使ってROMイメージを暗号化し、人々がROMの内容を解析したり独自のROMを作成したりするのを防ごうとした。しかし、RC-4/128は対称暗号なので、XboxはROMイメージを復号する鍵——同時に暗号化鍵としても使える——を持たなければならない。この復号・暗号化鍵が、秘密ブートROMの内部に埋め込まれた重要な保護情報だ。この鍵を隠すことが隠蔽によるセキュリティだ——いったん鍵が見つかれば暗号は無意味になり、すべてのセキュリティが失われる。
真のセキュリティとは、ユーザーがXboxのすべてのパーツにアクセスできても、自分の有効なフラッシュROMイメージを暗号化できない状態を指す。つまり、Xbox外部に秘密情報を保管する必要がある。公開鍵暗号はまさにこのシナリオのために考案された。MicrosoftがXboxのブートコードを公開鍵暗号で暗号化または署名していたなら、安全なブートROMの内容をすべて知っていても役に立たない。主要な秘密情報であるMicrosoftの秘密鍵は、ワシントン州レドモンドのどこかの金庫室に安全に保管されており、手の届かない場所にあるからだ。
ただし、明るい面もある。次章では仲間たちの発見を紹介する。その多くはXbox初期化シーケンスのバックドアの発見だ。これらのバックドアを使えば、Microsoftの著作権で保護された著作物へのアクセスを有効にせず、ゲームのコピーも有効にすることなく、Xboxで自分のコードを実行できる。次章ではまた、英国のAndy Greenによってわずか数日でクラックされたXboxセキュリティバージョン1.1も紹介する。
*原著*: *Hacking the Xbox: An Introduction to Reverse Engineering* © 2003 Xenatera LLC
*著者*: Andrew "bunnie" Huang | *出版*: No Starch Press
*日本語訳・レビュー*: ニコ技深圳コミュニティ / 高須正和（@tks） — [https://takasumasakazu.net](https://takasumasakazu.net) — CC BY-NC-SA 1.0
*注記*: 本翻訳は、原著の Creative Commons ライセンス条件に従って公開する翻訳コントリビューションであり、著者 bunnie からも歓迎のコメントをいただいています。出版社による公式日本語版ではありません。