Hacking the Xbox 日本語訳

Appearance

第6章　最高のXboxゲーム：セキュリティハッキング ​

Xboxのハードウェアを改造・調整する次の段階は、Xboxハードウェアを完全に支配することだ。残念ながら、ハードウェアを支配するのは思ったほど簡単ではない。Xboxの設計者たちは、高度なソフトウェア攻撃はもちろん、大半のシンプルなハードウェア攻撃からもコンソールを守るために、セキュリティに多大な労力を注いだ。Xboxのセキュリティ機構は、デジタル著作権管理（DRM）アーキテクチャの産物だ。

NOTE

原則として、自作プログラムを実行するといった「フェアユース」の目的でハードウェアを使うことは、違法ではないはずだ。しかし、フェアユース、保護されたハードウェア、そして比較的新しい著作権保護回避法の関係はいまだ不明確だ。第12章「注意せよハッカーよ」では、ハッキングの法的問題をより詳しく取り上げている。

Xboxのセキュリティ対策を回避する方法はいくつもある。本章と第8章「XboxセキュリティのリバースエンジニアリングXboxセキュリティ」では、Xboxのセキュリティシステムを解析した冒険譚を語る。成功だけでなく、遭遇した失敗についても書く——そこから学べることがあるからだ。第9章「裏口から忍び込む」では、他のハッカーたちがXboxセキュリティを回避するために取ったアプローチを解説する。第7章「セキュリティ入門」では、第8章と第9章を理解するための背景知識を提供している。

妄想的な設計との最初の出会い ​

2000年春にXboxが発表されたとき、ハードウェア愛好家コミュニティは沸き立った。その興奮の理由はゲームとしての可能性だけではない——300ドルという手頃な価格で、ネットワーク対応のx86アーキテクチャ高性能PCとして使える可能性があったからだ。発売数か月後の値下げにより、Xboxの価格はその後200ドルを下回るまで下がった。Xboxのアーキテクチャがx86 PCに非常に近いということは、膨大な既存アプリケーションと技術ノウハウが、理論上はコンソールに簡単に移植できることを意味していた。

僕が初めてXboxの中身を見たのは2001年11月下旬、当時の彼女（今は婚約者）がクリスマス前のプレゼントとしてくれたときだ。すぐに作業に取りかかった。Xboxハードウェアを支配するためには、まずブートROMを取り出して中身を解析するのが最初のステップだ。第2章のXboxアーキテクチャの解説を思い出してほしい——XboxのブートROMには、Xboxの動作環境を確立するためのコードがすべて含まれている。

ROMを読み出す ​

Xboxで使われているROMは、電気的に消去・書き換えが可能なフラッシュROM（FLASH ROM）だ。フラッシュROMには複数のパッケージ形式があるが、Xboxが採用しているのはもっとも一般的なパッケージの一つ、TSOP（Thin Small Outline Package、薄型小アウトラインパッケージ）だ。Xboxマザーボードの上面、セクターU7に搭載されており、回路記号はU7D1だ。TSOPパッケージは非常に見分けやすい——長方形の形状で、ピンがパッケージの短辺にのみ並ぶ、数少ないチップパッケージの一つだからだ。他のほとんどのパッケージはピンを長辺や全辺に配置して接続性を最大化しているが、フラッシュROMはシリコン面積あたりのI/O要件が比較的少ない。ベースの型番「29F080」をウェブ検索で確認すれば、これが確かに8Mbitのフラッシュだとわかる。

フラッシュROMの内容を読み出す（ハッカー流に言えば「スナーフ」する）技術はいくつかある。はんだ付け不要の方法は、フラッシュROMに挟み込むテストクリップを購入し、Xbox本体には電源を入れずに、テストクリップ経由でROMに電源を供給・制御しながら中身を読み出すことだ。この目的に適したテストクリップはEmulation Technologyから購入できる（www.emulationtechnology.com）。（テストクリップによるオーバーライド方式にはいくつかの問題がある。最大の問題は、テストクリップ経由で電源を受けていないフラッシュROM周辺のチップを恒久的に損傷させてしまう可能性だ。ただしXboxの場合は問題が生じないようで、この方式を試みたハッカーたちは成功を収めている。1 僕が最初にこの方法を選ばなかったのは、マザーボードを壊したくなかったのと、この方法に必要な300ドルのテストクリップを買う余裕がなかったためだ。）

もう一つの巧みな方法は、フラッシュROM周辺のテストポイントにワイヤーをはんだ付けして、XboxがROMの内容を読み取る様子を盗み聞きすることだ。盗み聞きの方法は二種類ある。一つはROMとインターフェースできるカスタム基板にワイヤーを接続すること、もう一つはロジックアナライザ（デジタル信号を多チャンネルでキャプチャする計測器）を使い、Xbox CPUがROMにアクセスする際のデータをキャプチャすることだ。後者の方法でも成功を収めたハッカーがいたし、実際にこの手法の過程でXboxのブートシーケンスにいくつかのバックドアが発見されている。2 僕がこの方法も選ばなかったのは、最初のXboxを入手した時点でロジックアナライザを持っていなかったこと、そして大量のワイヤーをはんだ付けする作業が非常に面倒で難しく、ミスも起きやすいからだ。

僕がとったのはもっとオーソドックスな方法だ——フラッシュROMを外して、ROMリーダーに差し込む。さらにマザーボードにソケットを取り付けた。そうすれば今後のROMの着脱やプログラミングが素早く確実にできる。

細かいピンの完全性を保ちながらフラッシュROMを取り外すのは、適切な道具があれば簡単で、そうでなければほぼ不可能だ。コツは、フラッシュROMのピン全体を同時に加熱することだ。均一に加熱できれば、フラッシュROMはマザーボードからすっと外れる。標準的な鉛筆型のはんだごてではピン全体を同時に加熱できない。この作業に適した道具は、図6-1に示すような「トング」または「ピンセット」型のはんだごてだ。このタイプのはんだごては二つのヒーターエレメントを持ち、チップの両側を同時に加熱できる。さらに、チップ全体の長さを一度に加熱できる幅広のパドル型チップを備えている必要がある。

Figure 6-1: Removing the Xbox FLASH ROM with a tweezer-style soldering iron.図6-1: ピンセット型はんだごてでXboxのフラッシュROMを取り外す。

こうした機能を持つはんだごては相当な値段（数百ドル）がするが、あらゆる場面で役立つ価値ある投資だ。僕はErsa SMT Unit 60Aを使っているが、展示会の会場で大きく値引きして購入したもので、学位取得中にこなした基板組み立て案件で元はすぐ取れた。Xytronic製の手頃な価格のはんだごてがJameco（品番168410）から約70ドルで購入できるが、僕自身は使ったことがないので品質は保証できない。もう一つのリーズナブルで簡単な方法は、付録B「はんだ付け技術」で説明している脱はんだ合金を使う方法だ。（ROM用のソケット3は比較的安価で20ドル未満だが、取り付けには安定した手と光学ルーペ類が必要だ。）

ROMを外してピンを清掃・点検したら、ROMリーダーで内容を読み出せる。ROMリーダーは購入できるが、自分で作るのも良い学習体験だ。僕が自作したROMプログラマについては、ウェブサイト（http://www.xenatera.com/bunnie）で紹介している。オリジナルのFlashburner4プログラマはシンプルな設計で、第2バージョン5より理解・製作しやすいが、機能は劣る。

ただし、ROMをできるだけ早く読み出すことが目的なら、素直にROMリーダーを購入する方がいい。良いROMリーダーは、本気のハードウェアハッカーの道具箱に欠かせない一品だ。Needham's Electronics（http://www.needhams.com）は幅広い価格帯に対応した優れたROMプログラマ／リーダーを展開している。

Microsoftとの邂逅 ​

ROMの内容を取り出したら、次のステップは仲間のハッカーたちと共有して解析することだ——本当にそうだろうか？　ROMの内容をウェブサイトに公開してから12時間も経たないうちに、MicrosoftのエンジニアからMicrosoftの著作権コンテンツをサイトから削除するよう丁寧に依頼する電話が来た。もちろんすぐにコンテンツをサイトから削除した。最初から公開しなければよかったのだ。

Microsoftとのこの最初の接触は、Xboxのリバースエンジニアリングは普通の家電製品のリバースエンジニアリングとは訳が違うという厳しい警告だった。リバースエンジニアリングのある側面を守る法律も存在するが、知的財産（IP：Intellectual Property）所有者を守る膨大な著作権法も存在する。Microsoftの権利を尊重しながらXboxを共同でリバースエンジニアリングするのは、法的な地雷原を歩くようなものだ。

一方では、Microsoftは利益を期待して製品に投資しリスクを取る権利がある。しかし収益性は法律では保証されていない。たとえばMicrosoftがやっているように、ソフトウェアの売上で差額を回収する目的でコンソールを大幅な赤字で販売する（「ロスリーダー」戦略）のはリスクの高い賭けであり、最終的にMicrosoftが利益を得ることは法律によって保証されていない。一方でハッカーである僕たちには、自分が稼いだお金で購入したハードウェアをいじる権利（「フェアユース」）がある。Microsoftが実質的にPCを大幅割引で僕たちに売りたいというなら、それは別に構わない。Xboxにおけるマイクロソフトの損失を補填するのに十分なゲーム（10本前後以上）を購入するかどうかは、完全にMicrosoftのビジネス・マーケティング戦略の問題だ。

僕の見方では、Microsoftの大きな損失対収益比はこの業界では少々異例だ。ソニーと任天堂はコンソールハードウェアのコストでほぼ損益分岐点を維持している。携帯電話会社もXbox並みの赤字で端末を販売することが多いが、端末コストを回収するためにユーザーとの契約を義務付けており、契約解除には違約金が発生する。これはXbox Liveのビジネスモデルへのマイクロソフトの自信の表れかもしれない。

こうした問題のちょうど中間に位置するのが、暗号技術を使った著作権保護機構とフェアユースの権利の相互作用だ。Xboxはコピープロテクションとコンソールの利用ポリシーを強制するために暗号技術を幅広く活用していることがわかった。そこで登場するのが、比較的新しく判例も少ない1998年デジタルミレニアム著作権法（DMCA：Digital Millennium Copyright Act）だ。確立した判例が少なく、法律の文言の間にはグレーゾーンが多い。ハッカーとして自分が直面しうるリスクを自分で評価しなければならない。第12章「注意せよハッカーよ」では、新時代におけるハッキングの法的問題をより詳しく探っている。

ROMの中身を解析する ​

Microsoftに跳ね返されたが、ROMの中身は手元にある。そのまま解析を進めた。ブートROMにはハードウェア初期化手順と、オペレーティングシステムをロードする命令が含まれており、ひょっとするとOSコード本体もあると予想されるだろう。しかし、どこから始めればいいのか？

ROMの中のプログラムは毛糸の玉のようなものだ。糸の端を見つけさえすれば、あとは時間と根気さえあれば必ず核心まで解きほぐせる。

幸い、XboxのPentiumプロセッサの起動ポイントはIntelによって詳細に文書化されている。電源を入れると、プロセッサはリセットベクタと呼ばれる決まったアドレスからコードを実行し始める。このリセットベクタはアドレス0xFFFF.FFF0——メモリの最上部付近だ。このアドレスのデータを16進数で見てみよう：

0xFFFF.FFF0  EBC6 8BFF 1800 D8FF FFFF 80C2 04B0 02EE

最初の2バイト「EBC6」は、0xFFFF.FFB8番地へのジャンプ命令だ。最初のバイト「EB」は「次の命令からの相対変位による短い相対ジャンプ」という特定のオペコードで、2バイト目の「C6」がジャンプの8ビット符号付きオフセットだ。つまりプロセッサが最初にすることは、別の場所へジャンプすることだ——リセットベクタにはメモリの上端から落ちるまでに16バイトしか余裕がないため、どのブートプログラムも必ずこの処理を行う。このコードはリセットベクタとして典型的なものなので、教育目的でここに転載しても問題ない。

次のコードブロックは、プロセッサのGDT（Global Descriptor Table、グローバルディスクリプタテーブル）とIDT（Interrupt Descriptor Table、割り込みディスクリプタテーブル）を初期化する処理だ。GDTとIDTはプロセッサのメモリ管理方式と割り込み処理方式を設定する。これらのレジスタの役割を正確に理解する必要はないが、興味があればIntelのデベロッパーウェブサイト（http://developer.intel.com）で公開されている「IA-32 Intel Architecture Software Developer's Manual, Volume 3: System Programming Guide」で詳しく説明されている。

これらのレジスタの設定後、プロセッサはプロテクトモードに移行して0xFFFF.FE00——メモリの最上部から正確に512バイト下の領域——にジャンプする。ここから話が面白くなってくる。セグメントレジスタを設定する短いコードのあと、ジャムテーブルインタープリタ（Xboxコミュニティでは「X-Codeインタープリタ」とも呼ばれる）と呼ばれるプログラムが実行される。ジャムテーブルとは、ハードウェア初期化の文脈で使われる、読み取り・書き込み・単純な条件分岐のオペコードを含む値のテーブルを指す業界用語だ。一般的なPCの初期化には数百の操作が必要で、ジャムテーブルはコア初期化コードを肥大させることなくこの複雑さに対処するのに役立つ。ジャムテーブルを使うと、インストールされているメモリの種類や量といったユーザー設定可能なハードウェアパラメータにも対応できる、より柔軟な初期化が可能になる。Xboxの場合、ジャムテーブルインタープリタはフラッシュROMの下端付近からジャムテーブルのオペコードを取得し始める。（ジャムテーブルインタープリタが実装するオペコードは非常に強力で、ジャムテーブルのオペコードを使ってXbox内の任意の場所へのデータの読み書きができることを覚えておいてほしい。）

ジャムテーブルインタープリタが終端オペコードを実行すると、プロセッサはMTRR（Memory Type Range Registers、各メモリ領域のキャッシュ可能性を宣言するレジスタ群）をクリアし、0xFFFF.A000から始まる16KBのメモリ領域の復号を開始する。このメモリ領域の復号に使われている暗号は、微妙な違いはあるがRC-4暗号アルゴリズムによく似ている。リスト6-1に、Data Rescue社のIDA Proというツールの助けを借りてリバースエンジニアリングしたCコードを示す（このツールについては次の章で詳しく説明する）。

c
// key initialization routine
unsigned char K[256]; // 0xFFFFC80 in flash
unsigned char S[256]; // 0x10000 in SDRAM
for( i = 0; i < 256; i++ ) {
    S[i] = i;
}
j = 0;
for( i = 0; i < 256; i++ ) {
    // RC-4 would do j = (j + K[i] + S[i]) % 256
    j = (j + K[i] + S[j]) % 256;
    // swap S[i], S[j]
    temp = S[i];
    S[i] = S[j];
    S[j] = temp;
}

// decryption routine
unsigned char cipherText[16384]; // 0xFFFFA000 in FLASH
unsigned char plainText[16384];  // 0x400000 in SDRAM
for( index = 0x4000, i = 0, k = 0; index > 0; index-- ) {
    // xbox version
    t = (S[i] ^ cipherText[k]) % 256;
    plainText[k] = t;
    // swap( S[i], S[t] );
    temp = S[i];
    S[i] = S[t];
    S[t] = temp;
    i = (i + 1) % 256;
    k++;
}

リスト6-1: フラッシュROMに見つかったダミー暗号の逆コンパイル。

この暗号で復号されたデータは、復号プロセスの最後に実行されるコードのブロックのはずなのだが、ここで何かがひどくおかしいことが判明する——復号されたコードはガベージだ。まったく機能しない。

📦 コラム：メモリアドレスデコーディングのトリック

メモリの特定領域を物理的な実態とは異なる見せ方にする技術がいくつかある。Xboxのブートシーケンス解析に関係する二つのトリックは、エイリアシング（aliasing）とオーバーレイング（overlaying）だ。

メモリのエイリアシングとは、二つのアドレスが同じメモリ位置を参照することで、通常はいくつかのアドレスビットを無視することで実現する。例で示そう。3ビットのアドレスを使うシステムを考える。3ビットシステムでアドレス指定できるのは2³ = 8か所だ：000、001、010、011、100、101、110、111。ここで4か所のメモリがあるとする。4か所を識別するには2ビットで十分だ：00、01、10、11。この4か所のメモリに3ビットアドレス方式でアクセスする場合、アドレスビットの1ビットを無視しなければならない。最上位ビットを無視すれば、アドレス000と100はどちらもメモリの位置00にマッピングされる。つまり位置00は、アドレス000と100にエイリアスされているということだ。

メモリオーバーレイングは、帯域外の情報を使って異なるメモリバンクを切り替える技術だ。秘密のメモリバンクを持ちたいとしよう。そのために、CPUと公開メモリ・秘密メモリの間にセレクタを挿入する。このセレクタは、図6-2に示すように、秘密メモリまたは公開メモリのいずれかのデータをCPUに提示することができる。結果として、アドレスセレクタを制御するプログラムが、秘密ブロックへのアクセス権も制御することになる。コンピュータが秘密メモリバンクのコードから起動した場合、秘密コード領域のプログラムはこの仕組みを使って、公開メモリ内のプログラムを実行する前にセレクタを公開メモリに切り替えることで、自分自身を隠すことができる。

Figure 6-2: Memory overlaying to hide secret regions.図6-2: 秘密領域を隠すためのメモリオーバーレイ。

さらに、ジャムテーブルのオペコードも壊れているように見える。この現象は問題に取り組む他のハッカーたちによっても確認されており、コード変換エラーではないことが証明された。明らかにXboxには表面からは見えないものがある。

この奇妙な動作を説明しようとする仮説と噂が出始めた。人気の高かった仮説には次のようなものがあった：

  • アドレス線またはデータ線のスクランブル。 どこかでアドレス線やデータ線が何らかの1対1マッピング関数によって反転または並び替えられている。スクランブル関数は初期化手順の一部としてチップセットにプログラムされている可能性があり、初期ブートブロックはプレーンテキストとして読めるが、残りのデータはスクランブルされているかもしれない。
  • 二次暗号プロセッサ。 Xboxの別のプロセッサが実際のXbox初期化を担当しており、ROMのブートコードはダミーだ。
  • プロセッサ内蔵のブートコード。 プロセッサがプロセッサダイ上のコードブロックによって実際に初期化されており、ROMのブートコードはダミーだ。
  • チップセット内蔵のブートコード。 プロセッサは標準のPentiumと同じように動作するが、チップセットにROMのダミーコードを上書きするブートコードが含まれている。

これらの仮説のほぼすべてについて、証明または反証する唯一の方法はハードウェア上で実験を行うことだ。たとえば、SMC（System Management Controller、システム管理コントローラ——Xboxがコンセントに挿さっている間は常にオンの8ビット自己完結型プロセッサ）がマシンのセキュアブートシーケンスに関与していないことを確認するため、ハッカーたちはSMCの全ピンの波形トレースをキャプチャし、SMCが初期化において重要な役割を果たす場合に予想されるイベントシーケンスと照合して分析した。

仲間のハッカーからの重要な観察は、0xFFFF.FFF0のリセットベクタコードを変更してもXboxが完全に正常に起動するというものだった。0xFFFF.FFF0でプロセッサが最初に実行する命令が壊れていれば、マシンがクラッシュするはずだと誰もが考えるだろう。ところがマシンは完全に正常に動作した。この観察は、フラッシュROMの様々な部分を意図的に壊す実験によって検証された。結果は、フラッシュROMの驚くほど広い領域を壊してもXboxの起動には何の影響もないというものだった。特に、0xFFFF.FE00から0xFFFF.FFFFまでのブート初期化シーケンス全体をヌルにしてもXboxは問題なく起動した。

この発見だけで、フラッシュROMのブートブロックがダミーだという仮説が強く支持された。しかし疑問は残った——本物のブートコードはどこに保存されているのか？　選択肢は三つ：二次暗号プロセッサの中、プロセッサの中、そしてチップセットの中だ。二次暗号プロセッサの仮説は、マザーボード上に起動時に暗号プロセッサの役割を果たすのに十分なパワーやアクティビティを持つチップがないという理由で却下された。

ブートブロックをプロセッサに格納する選択肢も、チップセットに格納するよりも可能性が低いと判断された。この分析の根拠はチップ製造のコスト経済学に基づいている。Pentium IIIプロセッサは多くの手作りブロックを持つ非常に複雑なデバイスであり、セキュアブートブロックを含むようにシリコンを修正するには、カスタムシリコンの製造に必要なマスクだけで約25万ドルの先行投資に加え、相当なエンジニアリングリソースが必要になる。さらに、Microsoftは当初XboxにAMDプロセッサを選んでいたが、土壇場でIntelに切り替えたという噂もあった。プロセッサコアにカスタムブロックが統合されていたとすれば、MicrosoftはCPUベンダーをそう簡単には切り替えられなかったはずだ。一方、nVidiaのチップセットはシリコンコンパイラを使ってモジュール設計されているため、セキュアブートブロックのような機能を追加するのは技術的にずっと容易だ。さらに、XboxのチップセットはMicrosoft専用に作られたnForceのカスタムバージョンで、IntelのFSB（フロントサイドバス、Front Side Bus）専用に調整されている。そのため、セキュアブートブロック追加のコストは、そのようなプロジェクトにすでに割り当てられているエンジニアリングリソースとマスクセットに組み込める。

チップセット内の秘密ROMオーバーレイに本物のブートコードがあるという仮説のもとで、残された課題は、コードがどのチップ（ノースブリッジかサウスブリッジ）に格納されているかを特定し、この秘密ROMを抽出する方法を見つけることだった。秘密ROMを抽出するための戦略がいくつか浮上した：

  • PentiumのJTAG（Joint Test Action Group）「バウンダリスキャン」機能を使って初期ブートコードのキャプチャを試みる。JTAGは専用のシリアルポートを通じてチップ上の全ピンの状態を読み書きできる診断バスで、非常に強力で汎用性の高いデバッグツールだ。
  • プロセッサのFSB（フロントサイドバス）をプローブして、プロセッサに入るブートコードのキャプチャを試みる。

Figure 6-3: Missing JTAG via.図6-3: 欠落したJTAGのビア。銅充填領域（明るい部分）に元々ビアがあった穴があることに注目。ボードレイアウトを土壇場で変更した際に充填領域の再計算をしなかった結果だ。

  • メモリスニファを取り付けて、メモリへの書き込み時に復号済みデータストリームのキャプチャを試みる。
  • 顕微鏡を使ってチップ表面から秘密ブートエリアの内容を読み出す。
  • サウスブリッジとノースブリッジチップ間のバスをプローブして、チップセットがプロセッサに送るブートコードのキャプチャを試みる。これはブートデータがサウスブリッジのどこかに格納されている場合にのみ有効だ。

これらの仮説はどれも簡単に検証できるものではなかった。フラッシュROMイメージの暗号解析に行き詰まった挫折したハッカーたちが次々と諦め、Xboxハッキングへの取り組みは徐々に停滞した。僕も諦める組の一人になっていただろう（何しろ、あと数か月で博士論文を書き上げなければならなかった）——決意を固めたハッカーコミュニティが励ましをくれていなければ。

2001年12月のクリスマス休暇中、IRCチャンネルとウェブフォーラムを通じてハッカー仲間と連絡を取り合い続けた。世界中の様々な境遇のハッカーたちがXboxハッキングのIRCチャンネルに集まっており、技術的なことも個人的なことも、彼らから学び、彼らと語り合うのが楽しかった。

1月は全部博士論文6の執筆に費やしてXboxハッキングは避けようと心に決めていたが、Xboxが採用した複雑で謎めいたセキュリティには抗えなかった。時が経つにつれ、IRCチャンネルにたむろする少数のハードコアハッカーグループにハードウェアの専門家が必要だということがますます明らかになってきた。1月末までには、Xboxセキュリティについての情報が面白すぎて無視できなくなっていた。

2台目のXboxを購入し、ホットエアガンで主要部品をすべて取り外し始めた。Xboxを分解することにはいくつかの目的があった。一つ目は、チップを取り外すことでXbox上の配線と接続がすべて露出し、マルチメーターの導通テストモードを使ってチップ間の接続を簡単に追えるようになることだ。二つ目は、興味深いチップをすべて熱い酸の槽に浸けてプラスチックの封止材を除去し、顕微鏡で解析できるようになることだ。最後に、Xboxを買って完全に分解したことで、動作するXboxをプローブしたり改造したりする際の心理的な余裕が生まれた。（リバースエンジニアリングは庭仕事に似ている。手と膝を汚さないようにしながら庭を耕すのは難しい。だったら割り切って土の中に転がり込んだ方がいい。）

Xboxの分解の結果、Microsoftがハードウェアハッカーからコンソールを守るために講じた対策のいくつかが明らかになった。まずPentium CPUのJTAG接続を確認した。JTAGの信号はすべて——TRST#信号を除いて——プロセッサ近くのタップしやすい抵抗器に便利にルーティングされていた。TRST#はJTAGインターフェースの初期化において重要な役割を果たす。興味深いことに、TRST#はアクセスしにくい場所の内部グラウンドプレーンに接続されており、JTAGメカニズムを恒久的に無効化していた。Xboxマザーボードをさらに調べると、TRST#信号が土壇場で取り除かれた痕跡が見つかった。（欠落したビアの最大の証拠は、図6-3に示すように、JTAG信号専用のビアクラスター近くの電源配線に、ビアとしてちょうどいい大きさの穴が開いていることだ。）

秘密ROMを抽出するためのJTAGアプローチへのさらなる打撃は、IntelのJTAGスキャンコードが独自仕様（プロプライエタリ）だということだ。秘密ブートデータを抽出するのに使えるレベルまでそのコードをリバースエンジニアリングすることは、それだけで一つの大きなプロジェクトになる。

JTAGアプローチを断念し、次に試みたのはCPU、GPU、そしてMCPX（Xboxのサウスブリッジチップ）のパッケージを剥がしてベアダイを顕微鏡で観察し、ROMの候補となる構造を探すことだった。パッケージの取り外し（「デキャップ」）は、チップを熱した発煙硫酸に浸けることで行った。（家庭でのこの方法はお勧めしない。一度、毒性と腐食性のある液体を全身にこぼしたことがあるが、幸い僕の肌ではなく保護具が犠牲になった。発煙硫酸は燃えさかる炎よりも速く有機物を溶かす。）同じく非常に毒性と危険性の高い発煙硝酸も使える。僕自身は試していないが、報告によると発煙硝酸はエポキシの封止材を除去するのにより効果的で、特に選択的なパッケージ除去が必要な場面で有用だという。

従来の可視光顕微鏡を使った手動検査は多少の望みを与えてくれたが、この技術は光の物理学によって限界がある。光の最短波長は450nm（青色に相当）であるため、最高の可視光顕微鏡技術でも150nmのトランジスタを解像することはできない。秘密コードが、従来のアレイROM構造——光学顕微鏡で識別できる上層の金属層に、1か0を定義する金属線がエッチングされている構造——を使ってチップに格納されていることを期待していた。ハードワイヤードROM構造を使う動機はコストだ。フラッシュROMとヒューズベースのPROMはシステムコストを大幅に増加させる余分な製造工程が必要だが、上層の金属層を使うことは設計者のリスク管理の観点から動機付けられる。上層の金属層は最も粗い層（光学顕微鏡で解像できるほど粗い）であり、ROMコードにバグがあった場合に変更するのに最もコストが低い層だ。また、初期の動作確認（ブリングアップ）段階では、FIB（Focused Ion Beam、集束イオンビーム）装置と呼ばれるチップ修正機を使って上層をカット・ジャンパするのが最も容易だ。残念ながら、顕微鏡でチップをざっと確認したところ、そのような構造は見つからなかった。

この時点で秘密ROMを抽出するために残された唯一の選択肢は、動作中のXboxハードウェアをプローブして、Xboxプロセッサへのコードのロード中にそれをキャプチャすることだった。サウスブリッジチップとフラッシュROMの上流でコードを盗み聞きするということは、フロントサイドバス、ノースブリッジ-サウスブリッジ間バス、またはメインメモリバスのいずれかをプローブすることを意味した。これらのプローブアプローチの実行上のトレードオフについては、次章（第7章）で基本的なセキュリティの概念を簡単に紹介した後、第8章で議論する。

注 ​

  1. Andy Greenによるテストクリップアプローチについてはこちらのページに詳しい記録がある：http://www.warmcat.com/milksop/milksop.html
  2. Visorによるロジックアナライザアプローチについてはこちらにまとめられている：http://www.xboxhacker.net/visor/aXventure1.txt
  3. Emulation Technologies（http://www.emulation.com）が幅広い種類のソケットを提供している。XboxのフラッシュROM用の具体的な型番はS-TS-SM-040-Aだ。
  4. http://www.xenatera.com/bunnie/proj/flashburn/fb.html
  5. http://www.xenatera.com/bunnie/proj/fb2/
  6. スーパーコンピュータアーキテクチャ、データとスレッドの移動、フォールトトレランス、高速低遅延ネットワーク、または大規模マルチスレッドマシンに興味があれば、こちらで博士論文を読むことができる：http://www.xenatera.com/bunnie/phdthesis.pdf
*原著*: *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 からも歓迎のコメントをいただいています。出版社による公式日本語版ではありません。

ニコ技深圳コミュニティ / 高須正和（@tks）による日本語訳コントリビューションです。著者 bunnie からも歓迎のコメントをいただいています。原著は Andrew 'bunnie' Huang および No Starch Press に帰属します。

翻訳テキスト © 翻訳者 | 原著 © 2003 Xenatera LLC (著者: Andrew 'bunnie' Huang) | CC BY-NC-SA 1.0