ほぼ機械翻訳のコピペ。興味のある人のためだけのもの。
OTPは、アドレス0x10012000の一見ランダムなデータの0x100バイトの領域です。3DS本体の固有キーはこの領域から導き出されていると推測されますが、現在は正確にはわかりません。この領域は、ブートROMによって復号化されるコンソール固有のデータストアである可能性がありますが、誰かが完全に保護されたブートROMをダンプするまで、その方法はわかりません。今のところ、誰かが保護されたブートROMを正常にダンプできたかどうかは不明です。
本体FW Ver.3.0.0-X未満のバージョンでは、0x10012000-region（OTP）は保護されておらず、十分な権限（arm9コード実行）を持つ攻撃者によってダンプされる可能性がありました。
Ver.3.0.0-X以降、任天堂はCFG_SYSPROT9レジスタを使ってこの領域をロックするように切り替えました。これはブートローダをロックするもので、任意のコードを実行できる段階よりも前の、ブートの極端に早い段階で設定されています。このレジスタは正確に1回設定することができ、本体（ユニット）の電源が完全にオフになるまでスイッチをオフにすることはできません。従って、3.0.0-X未満のバージョンを使用しないでフルOTPをダンプすることはできません。
しかし、Ver.9.6.0-XにおいてOTPのハッシュをダンプする方法があります。Kernel9Loaderは使用後にSHA_HASHレジスタをクリアしないので、SHA_HASHをダンプすると、Kernel9LoaderからKernel9に渡されたOTPのハッシュが与えられます。さらに、i2cによって引き起こされたMCU再起動によって、想定されていたようにRAMがクリアされないという、長年にわたる脆弱性が存在します。
これにより、任意のデータがSysNANDバックアップのnand_sector96 + 0x10に書き込まれ、本体（デバイス）にフラッシュされるハードウェアベースの攻撃が可能になります。その後、私たちのコマンドでi2cをMCUのリブートに接続し、ペイロード（SDカードのファイルに0x1000A040〜0x1000A060を書き込む）をどこかのarm9メモリに書き込み、すべてのメモリにNOPスレッドを書き込んだ後、ペイロード（を実行？）。その後、Kernel9Loaderが無作為にペイロードにジャンプするまで、MCUを繰り返しリブート（nand_sector96 + 0x10を1ずつ増加（インクリメント））します。
上記の方法には複雑であり、かつ不必要なハードウェアをわざわざ使用するため、このガイドでは3.0.0-X未満のバージョンにダウングレードするソフトウェアベースのアプローチにを使用することに決めました。バージョン0_15_20（＝Ver.2.1.0-4？）が選択されたのは、完全に悪用可能なブラウザバージョン（2.0.0-Xには部分的に悪用可能なブラウザがありますが、他の理由では機能しません）が含まれている3.0.0-Xより下の唯一のバージョンです。
このプロセスでは、CTRNANDが0_15_20に書き換えられます。これは、（のようなコンソール特定のファイルのコピー、0_15_20を含む既成のCTRNANDイメージをインストールすることにより達成されるmoveable.sedとSecureInfo_AタイトルデータベースCMACSを固定した後、それに）。新しい3DSでは、CTRNANDの暗号化スロットを交換し、Old
3DS NCSDヘッダーをNANDにインストールし、Old
3DS専用な0_15_20ソフトウェア（＝Oldにしかない2.1.0-4…？）を起動できるようにします。
