これまでの経緯
Switch 2初のソフトウェア脱獄ツール「ns2jb」が発表
2026年10月、ゲーム機「Switch 2」向けの初のソフトウェアベースの脱獄ツール「ns2jb」が、Hacker Newsで発表されました（Hacker News (API)）。このツールは、任意のネイティブコードをsysmoduleとして実行可能にし、自作ソフトの動作やゲームの改造、セーブデータのバックアップ、そしてほとんどの周辺機器へのMMIO（Memory-Mapped I/O）アクセスを可能にするとされています。
「ns2jbは、Switch 2向けのソフトウェアのみ、テザード型の脱獄ツールであり、任意のネイティブコードを通常のsysmodule、および組み込みのfs sysmoduleとして実行することを可能にします。」
開発者は、この脱獄ツールの機能を示すために、Switch 2専用ゲームである「マリオカートワールド」を改造したデモも公開しています。当初はAI（Codex）がSwitch 2を自動で脱獄する試みも行われましたが、結果的には開発者が約2週間かけて手動で脆弱性を悪用したとのことです。
WebKitとSmileBASICの脆弱性を悪用したコード実行
ns2jbは、初期のコード実行のために主に二つの経路を利用しています。一つは WebKitのN-Day脆弱性 で、カスタムWi-Fiキャプティブポータルを通じてロードされるWebkitの脆弱性を突くものです。ゲーム機でのWebKitを標的とした脱獄は一般的であり、今回もこのアプローチが採用されました。
しかし、このWebKit経由のアプローチでは、JavaScript関数オブジェクトの置き換え以上に任意のIPC（Inter-Process Communication）呼び出しを行うのが困難であると開発者は述べています。そこで次に注目されたのが、Switch 1向けゲーム「SmileBASIC」の脆弱性です。SmileBASICは過去にも3DSでユーザーランドのコード実行を許した実績があり、巨大なC++コードベースであることから、今回も脆弱性が見つかる可能性が高いと判断されたようです。
「WebKitはコンソール脱獄の一般的な標的であり、初期コード実行のためにCodexがこれを選んだことは驚くべきことではありません。」
Codexは、SmileBASICのインタプリタで 32ビット整数オーバーフローの脆弱性 を発見しました。これは配列から要素を削除する際に position + count <= array.length のチェックが行われるものの、この合計がラップアラウンドして負の値になる可能性があり、結果として memmove 関数で意図しないメモリアドレスへのアクセスが発生するというものです。これにより、以前の8バイトがコピーされ、任意のコード実行につながる可能性が示唆されています。
ハードウェアとAIによる実験環境の構築
今回の脱獄プロセスでは、CodexというAIを活用した自動化の試みもなされました。開発者はSwitch 1とSwitch 2を囲むハーネスをセットアップし、JetKVMを通じてCodexがUSB経由でコントローラー入力を送信し、HDMI経由でビデオ出力を受け取れるようにしました。さらに、クラッシュ時に再起動が必要なSwitch 2の電源ボタンを押すために、Bluetoothライトスイッチフリッカーを使用するという工夫も凝らされています。
| 項目 | ツール/技術 | 用途 |
|---|---|---|
| AI | Codex | 自動脱獄試行（初期目標未達成） |
| ハードウェア | JetKVM | USB入力、HDMI出力の制御 |
| ハードウェア | Bluetoothライトスイッチフリッカー | クラッシュ時の電源ボタン操作 |
| ソフトウェア | WebKit | 初期コード実行の標的（N-Day脆弱性） |
| ソフトウェア | SmileBASIC | 整数オーバーフロー脆弱性の標的 |
AIによる自動脆弱性発見や悪用はまだ途上ですが、このような組み合わせによって、研究者は効率的に脆弱性を見つけ出す可能性を模索していると感じます。最近ではアカウント乗っ取りの脅威が増しており、GenAIがフィッシング詐欺を容易にしているという報告もあります（The Register）。こうした状況を鑑みると、AIを悪用した攻撃の進化は避けられないのかもしれません。
エンジニア目線で見ると：潜在的な影響と今後の対策
今回のSwitch 2の脱獄ツール登場は、発売後間もない時期であることを考えると、かなり衝撃的なニュースだと感じます。ソフトウェアのみで、かつテザードとはいえ、任意のコード実行が可能になるのは、セキュリティモデルの観点から見ても重要なインシデントではないでしょうか。
特に、WebKitとSmileBASICという異なるアプローチから脆弱性を探求している点が興味深いです。WebKitは過去にも多くのデバイスで悪用されてきた実績があり、またSmileBASICのような組み込みインタプリタが過去の脆弱性を再燃させる可能性を突く発想も非常にエンジニアリング的だと感じます。普段PythonやTypeScriptを書いている私からすると、C++で書かれた巨大なコードベースのSmileBASICでメモリ破損系の脆弱性を見つけるのは相当な手間がかかるはずで、CodexのようなAIツールがその助けになっているのは想像に難くありません。
この動きは、ゲーム機のセキュリティ研究者や、自作ソフト開発者にとっては朗報でしょう。しかし、メーカー側からすれば、ファームウェアのアップデートによる迅速な対応が求められるでしょう。一方で、こうした脱獄ツールは、ユーザーが購入したハードウェアをより自由に利用したいというニーズの表れでもあります。
ただ、このような脆弱性の公開は、悪意のある攻撃者にとっても格好の標的となり得ます。例えば、個人情報や決済情報などが保存されているセーブデータの不正なバックアップや改ざん、あるいは悪質なマルウェアの導入といったリスクも考えられます。企業は、Secure Software Factoryのようなアプローチでソフトウェアサプライチェーン全体のセキュリティを強化し、AIエージェントの安全な導入を進める必要があるというDockerの報告（Docker Blog）も、他人事ではないと感じます。
個人的には、こうしたツールがどのような経路で配布され、どのような法的な解釈がなされるのかも気になるところです。自作のプロダクトでも、OSSの脆弱性情報やライブラリの更新は常にチェックしていますが、ハードウェアレベルのセキュリティとなるとまた別の難しさがあります。今回の発表は、今後もゲーム機のセキュリティを巡る攻防が続いていくことを強く示唆しているように思います。
