        _        _ _   _    _    __  __
  _ __ (_)_ __  (_) | | |  / \   \ \/ /
| '_ \| | '_ \ | | |_| | / _ \   \  / 
| | | | | | | || |  _  |/ ___ \  /  \ 
|_| |_|_|_| |_|/ |_| |_/_/   \_\/_/\_\
              |__/                     
                            by smea

日本語訳

I - Cubic Ninja ユーザーランド突破口 (別称 ninjhax, entrypoint)

	詳細 : Cubic Ninja (Ubisoftのゲーム, http://www.nintendo.co.jp/3ds/software/aqnj/) にはレベル・エディタが含まれる。ユーザー・モードのレベルはゲームカードのセーブ・パーティションにセーブして
	 QRコード(や日本語版ではstreetpass)を介して他のユーザーと共有できる。一度暗号化と圧縮(blowfish 暗号や一部 lz 圧縮がそれぞれにあたる)方法が理解されると、
	 ゲームが読み込む独自のカスタム・レベルのQRコードを生成する事が可能。

	問題 : レベルがセーブされるフォーマットには可変長の要素が含まれる。パース時に、該当する要素の長さの確認無しに、そのような要素は通常スタック上の固定サイズのバッファにロードされる。
	もちろん、これは自明に突破可能なスタック破壊へとつながり、これによりROP機能が手に入る。非常に都合の良い事にレベル・ファイル全部は前もってヒープにロードされ、
	レベルファイルサイズに制限は無い事に触れておくべきであろう。しかもなお悪い事に偽造QRコードを使用して全く同様のクラッシュを引き起こす事ができる。

	制限 : これによりコード実行ではなくROP機能が使用できる。QRコードに無制限のサイズはあり得ないし、またスタックはそれほど大きくもない。 
	突破口 IIを使用して最初の制限を、2番目はhttp:Cを介して二次的なペイロードをダウンロードする事で克服した。また、Cubic NinjaにはSDやldr:roアクセスが存在しない。
	(なぜ後者が重要であるのかは突破口 IIIを参照。)

	修正 : ゲームのソースコード内でこれを修正するのは些細な事である。サイズチェックを適切な場所にいくつか追加するだけ。ソースコード無しでの修正はより困難である。 
	/edit/ ディレクトリ以下にある.mapファイルが正規のものであるかを確認するようセーブゲームをスキャンするコードを書く事はそれほど難しくないであろう。しかしながら
	QRコードの読み出しを突破口として使用できるので、それだけでは不十分である。それを気に留めておきつつ、	クラッシュを防ぐ為にゲームのコンパイルされたコードに手を入れる事も可能だが、 
	その手段は困難であろう。
	もっと正確に言うと、主に0x001F5F38 (EU/US版において、JPNは未確認)にある機能に問題があるようだ。この機能はデータ、ひとまとめになった構成をある外部バッファにコピーするよう
	デザインされているようである。これはソースとデータの構成(R0)へのポインタ、送り先バッファ(R1)へのポインタ、送り先バッファ(R2)のサイズを引数として持つ。入力データが出力バッファより
	大きい場合は失敗する。これで安全そうに見える！が、それには「裏口」が含まれる。R2が0の時、入力データサイズは全くチェックされない。残念ながら, このR2 = 0といった裏口はゲームのコード
	全般で、よくスタック・バッファを伴って使用され、非常に危険なものとなっている。良い知らせは適切なR2を指定するようコードにパッチを当てる事でクラッシュが修正される。
	残念ながらコードは通常0x001F5F38機能により出力されるエラーを確認しないようなので、十分であるとは言い切れないが、まず手始めになると思われる。


II - GPU DMA 突破口 (別称 gspwn, ssspwn, gpuhax, The Real Deal)

	詳細 : 3DSのGPUでは読み書き権限を使用してある特定のメモリ領域にアクセスする事ができる。これらの領域にはVRAMやFCRAMの一部が含まれる。gspモジュールを介してメモリ領域に渡ってデータを
	コピー、テクスチャ／頂点オブジェクトのデータの読み書きやレンダリングの際にフレームバッファへの書き込みなどにGPUを使用するコマンドを含む、いろいろな事に使用される。

	問題 : GPUがこれらメモリ領域にアクセスできること自体が問題ではないが、gspで処理するGPUコマンドの為の入出力アドレスに対して全くチェックを行なわないというのは問題である。 
	GPUは0x20000000-0x26800000メモリ領域全体に読み書きアクセスでき、従ってGX コマンド 2、3と4を使用してこれらの領域にアクセスする事は可能である。 
	「ありがたい事に」FCRAMの最後にある(意図的？)システムメモリ領域は除外されるが、それでも簡単なコード実行の達成や他の種の攻撃(使用時間／確認時間等が考えられる)といったチャンスを与える事になる。

	制限 : 現在実行中のアプリの.text領域を上書きする事でネイティブ・コードの実行が可能になるが、それで即座に何かそれ以上出来るようになる訳ではない。ホームメニューを含め、他に実行中のアプリそれぞれが
	自身の.textを0x26800000+メモリ領域内に隠し持つ。

	修正 : これの修正は大変興味深い事に些細かつ、非常に複雑なものである。注目すべき事としてこれを悪用する方法が(少なくとも)３つある。
			- GXコマンド : これが一番修正しやすいもの。単純にコマンド2、3と4に対してハンドラーにチェックを入れるようにする。実際にどのようにチェックを機能させたいかは不確かだが 
			(実際にマップされたLINEARヒープ内にアドレスが入るようにするのが理想的だが、任天堂のシステムでそれが容易くできるかどうかはわからない)非常に実現可能である。
			- WriteHWRegs/WriteHWRegsWithMask : ユーザーモードのアプリからGXコマンド・ハンドラーにより使用されるレジスタ読み込み／書き込みのシーケンスを手作業で模倣する事は可能。
			 これは上記の修正がごく簡単に回避できてしまう事を意味する。従って、特定のレジスタに書き込む際にそれらのコマンドのハンドラーに同様の修正を追加すべき。
			- レンダリング : これは厄介な部分である。初めてこの脆弱性を利用した際、私のアプリの.text領域に出力するよう設定されたフレームバッファを使用してシーンをレンダリングした。 
			これを防ぐにはGPUコマンドを設定するフレームバッファに対して送られたGXコマンド1と5で送られたGPUコマンド・バッファをスキャンしなければならない。
			これはGPUコマンドをひとまとめにできたりGPUコマンドパラメータをマスクできてしまうという事から更に難しくなっている(と思われる)。そのため、正しく行なわれないと
			単純なフィルタがだまされて悪意のあるフレームバッファの設定を通過させてしまう可能性がある。 
			他の問題はユーザーモードのアプリでGXコマンド1と5で使用されるGPUレジスタの読み込み／書き込みシーケンスを再現出来てしまい、この場合もやはり、それらのコマンドに対して
			ハンドラー内に入れられたチェックが完全に回避できてしまうことにある。


III - ro takeover 突破口 (別称 rohax)

	詳細 : 3DSは「ro」(恐らくrelocatable object) と呼ばれるシステム・モジュールを実行し、これによりユーザーが動的にリンクされたコード (「CRO」)をロードして実行できる。
	これらCROは通常romfs内に直接格納され、署名され、アプリ内の各CROファイルのハッシュを含む中央CRRファイルを使用して確認される。ファイルがロードされるとCRRの署名が確認され、その後
	CRRファイル内に格納された該当ハッシュと比較して各CROの整合性が確認される。 
	再配置できるようCROファイルにはロードされているコードに当てなければならないパッチのリストが含まれる。roシステムのモジュールは高特権システムコール多くにアクセスし、特に 
	自身や他のプロセスの仮想メモリ空間内でメモリ領域に実行可能ステータスを許可する。

	問題 : 突破口 IIを使用して、署名チェックが行なわれた「後」でロードされたCRRファイルのハッシュリストを変更する事が可能。これにより任意のCROファイルがロードできるようになる。
	その後、roのスタックにパッチを当てる再配置パッチリストを使用するカスタムCROが作成でき、ro内でROP機能が使用できるようになり、それをSVC 0x70を使用してroコード実行に使用する。 
	再配置パッチはCROセグメント内のみに存在可能で、最初のパース時にCROセグメントはCROメモリ内で確認されるため、これは可能ではないはず、これはよいことである。しかしながら、
	CROセグメント表 (これは実使用のためにどこからかのコピーではなくCRO自身の中にある)を含めるようCROセグメントの1つを拡張して、最初の再配置パッチを使用してスタックを含むようCROセグメントを拡張し、
	後続のCROパッチを使用して我々のROPチェーンをスタックに書き込むようすることができる。

	制限 : ro内でコード実行はsvcControlProcessMemoryにアクセス出来るようになるので問題。これにより他のプロセス内に実行可能ファイルとしてメモリにマップ可能。
	svcMapProcessMemoryを使用して他のプロセスのメモリも改変できるようになる。とはいえ、他のプロセスに対するハンドルが必要でroはsvcOpenProcessにアクセスできないので
	他プロセス (例えば理想的には、ローダー...)何でもにそういった事が行なえる訳ではない。従って、Cubic Ninja内のメモリを再マップするためには我々のro内のコード実行機能のみを使用する。

	修正 : 突破口 IIの修正でこれの悪用を妨げる事になるのは確かである。しかしシステムの他の部分の他の不具合を使用して突破口 IIに似たような事ができないという保証は無い。
	そのため、可能性として考えられる修正には以下が含まれる。
		- CROハッシュをチェックする度にCRRの署名をチェック。
		- 最初にパースする際、CRO部分をCROの外どこかにコピー。


IV - Bonus Round (別称 spiderto、または「突破口という訳ではないが、 Cubic NinjaからSDカードやldr:roにアクセスする方法がこれになる」)

	詳細 : 3DSはメインアプリにアプレットを同時に起動させる事ができる。これらアプレットにはホームメニューやウェブ・ブラウザ(別称 spider)が含まれる。APTコマンドの所為で
	そういったアプレットをいかなるユーザーモードのアプリから起動する事が可能である。

	"問題" : spiderなどといったシステム・アプレットが.textを0x26800000+領域に置く一方で, 二次的なスレッドの為のスタックを含む情報の収納にヒープを使用する。これにより全てROPを通して
	突破口 IIと適切なタイミングを使用してそのスレッドを乗っ取ることを可能にし、そこからspiderのメインスレッドを乗っ取り、それを使用してrohaxを実行する。
	そこから、Cubic Ninja spiderのroとfsにセッション・ハンドラーを渡すようNS:SendParameterを使用する。

	制限 : N/A

	修正 : N/A


 突破口シーケンスのまとめ :

	- ninjhax => Cubic Ninja ROP
	- Cubic Ninja ROP => gpuhax => Cubic Ninja コード実行
	- Cubic Ninja コード実行 => gpuhax => spiderto => spider ROP
	- spider ROP => rohax => ro コード実行 (roが「hb」カスタム・サービスハンドラーになる。)
	- ro コード実行 => メモリの再マップや基本的なキャッシュ管理機能を使用してCubic Ninjaコード実行 

V - 推奨

	再優先事項は突破口 II(gspwn)の修正になる。この作業で最も重要な部分で、これを取り除く事で他全てが崩壊する。侵入地点を修正するのは良いが、侵入地点はなかなか見つからないものである。
	III(rohax)の修正は良いがコード実行にrohaxは「必要」でない。II(gspwn)が実に一番危険なもので何よりもまず取り除くべきものである。
