Dark-AleX.orgのフォーラムに、また新しいPSP-3000のバグを発見したというビデオが紹介されていました。【記事】
Xeiyanideチームって聞いたことあるなぁ。PSPGENチームの一員か？

---

Nuevo fallo en PSP 3000

El equipo de Xeiyanide, J3r3mie y spimort hemos encontrado una forma mas fructifera que un desbordamiento de buffer.

El logro se basa en que la PSP, al conectarse con un modulo antes de buscar una actualizacion, es redirigida a otro modulo que contiene un updatelist [una lista con las actualizaciones disponibles], y al descargar el eboot, no lo hace de la version 5.03, si no otro diferente.

Por ahora esto es solo funcional en la PSP 3001 (de USA) con 5.02. No vamos a desvelar la forma de hacerlo para evitar que Sony lance un firmware 5.04 que corrija esto. Tarde o temprano sera publicado, pero solo cuando un eloader este disponible.

---

Google先生〜、またスペイン語です。出番です。
機械翻訳の翻訳なので翻訳の正確性は皆無です。
[Google翻訳]+[まもすけ翻訳]
New bug in PSP 3000
PSP-3000に新たなバグ

The team Xeiyanide, J3r3mie and spimort have found a more fruitful than a buffer overflow.
XeiyanideチームのJ3r3mie氏とspimortがバッファーオーバーフローよりすごいものを発見しました。

The achievement is based on the PSP, when connected with a module before looking for an upgrade, it is redirected to another module that contains a updatelist [list available upgrades], and download the eboot, it is not the version 5.03, if not another.
アップデータがあるかどうかをチェックするPSPのモジュールがネットワーク接続をする時に起こります。アップデートリスト(更新可能な状態にあるもののリスト)を含む別のモジュールにアクセスし、ebootをダウンロードしますが、バージョン5.03ではないようです。

For now this is only functional on the PSP 3001 (USA) with 5.02.We will not disclose how to do to prevent a launch Sony firmware 5.04 to correct this. Sooner or later it will be published, but only when a eloader available.
これはFWが5.02のPSP-3001（USA版）にだけ起こります。これを修正するためにソニーがファームウェア5.04を出すと明言はできません。eloaderがリリースされたりすることがあれば遅かれ早かれソニーは出しててくるとは思いますが。

OFW5.02のPSP-3000をネットワークアップデートかけると、EBOOT.PBPはダウンロードできてメモリースティックに保存もされるのだけれど、アップデートの必要がないとか表示される、という内容みたいです。
そもそも作業中になにかコメントをしゃべっているのですが、全く解読不能です。

US版だけと書いてありますから日本版ではダメみたいです。そもそも試してまともに更新できたりするとGrpshift exploitが無効になってしまいますから試すにも勇気がいります。
動画のタイトルが「Go! Exploit PSP-3000 by Xeiyanide, spimort and J3r3mie」になってますが、これをどうやればexploitに化けるのか見当もつきません。

フォーラムでは特に偽物論議にはなっていません。それよりもフォーラムでは最近どんどん報告されるPSP-3000のバグに「いったいいくつバグがあるんだ？」とうれしい悲鳴も聞こえてきてます。
でも、見つかっても放置ですけどね。今のところは全部。

先日PSPの累計売り上げ台数が5,000万台達成のニュースをお伝えしましたが【記事】、それだけ売れてるということはユーザーもそれなりにはいるわけで、よってたかってバグ探したらそりゃ出ても来ますよね。問題はそこからexploitに昇華させることができるユーザーががやたら少ないことです。

おそらくUS版PSPでしか起こらないらしいこのバグはこのまま黙殺されソニーに葬られることでしょう。アーメン。

しばらく前から取り組んでいたのだけれど、XMBのセーブデータ管理上は表示されるのに起動すると読み込んだ後にデータ破損してるから削除しなさいと怒られ続けてた。
今日になってようやく気がついた。
恥ずかしい話だが、システムバージョン表示も5.00M33だったからうっかり忘れていた。
PSPのFWが5.03TDPだったことを。

どうりでgripshiftのexploitが破損データになるわけだ。大失敗。

ということで、Gripshift日本版でなんとかしてHello Worldでも表示できないものだろうかと試行錯誤してみた。
唯一暗号化されていないデータが存在するのはUS版のみ。
US版のspartaのデータと、オリジナルデータでなにが書き変わっているのかちょっとのぞいてみた。
まずはオリジナルとspartaの復号化したデータでどこが違うのかから見ていくとしよう。

…ULUS10040.binもSDINFO.BINもSDDATA.BINも全部CRCが違う。

容量が小さいのから見ていくか。
まず2kBのSDINFO.BINから。

SDINFO.BINを見ると、
00000080:から8バイト分は、たぶんXMB上のセーブデータ管理で表示されるプレーヤーの名前部分かな？
US版はMATIAZって表示されるし、1% COMPLETE : 5 CREDITSもそうだし。日時はファイルのタイムスタンプだろうか。
JP版はMAMOSUKEって入れたけど、同じアドレスに入っているから間違いなさそう。
ということは、SDINFO.BINは関係なさげ。

次に同じく2kBのULUS10040.bin。
00000074から0000008Bまでが違う。
spartaのは
90 CC E4 08 00 70 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
オリジナルは
90 CC E4 08 D4 63 00 00 D4 63 00 00
47 52 49 50 53 48 49 46 54 E2 84 A2

オリジナルのはGRIPSHIFTナントカって文字が入っているのにspartaはなくなってる。
000063D4ってのはSDDATA.BINのデータの最終アドレスだ。
spartaの00007000ってのは存在しないアドレス。これは何だ?

あとはオリジナルは00000100から8バイト分プレーヤーの名前(MAMOSUKE)があるのにspartaにはそれもない。
00000580から000005C8にもなにかデータがあるけれどオリジナルは00だけ。
とにかくspartaはデータが00で埋め尽くされている。
気になるのは00000078から2バイト分がオリジナルのD4 63に対してspartaが00 70になっていることくらい。

なぜ00で埋められているのか、それが関係あるのかもわからない。
70の秘密さえわかってしまえばたぶんULUS10040.binはなんとかなる。
日本版の場合はファイル名はULJM05089.binだ。

さて、セーブデータ本体の25kBもあるSDDATA.BIN。
名前の開始アドレスは日本版でも同じなことは分かっている。
でも日本版のSDDATA.binだとthis si spartaaaaaaの”a”の数を同じだけ入れようとするとUS版にはデータがないところにすでに何かデータが入っていてだめなんだよね。
同じだけ”a”入れても、データ読み込めてフリーズもせず、なぜか音楽(BGM)だけなくなるし。(効果音は出る)

日本版はデータをオフセットさせないとだめかなぁ。
this is spartaaaaaaaaaaの間にUS版には謎のアドレスが存在してる。
000000A9から4バイト分。
50 CD E4 08

そういえばMaTiAz氏が
The return address is located at offset 0xA9 in the file
って言ってたっけ。
あと、ヒントになりそうなコメントとしては
In this poc it points to 0x08E4CD50 (which is only a few bytes after the return address), and the code starts at 0xCC in the file.
あとたしか、言語によって戻りアドレスが違うとか…

0xCCからコードが始まるって書いてあるけど、000000CCから始まるのはたぶんこの68バイト。
00 44 02 3C 21 08 40 00
FF FF 03 24 00 00 43 AC
04 00 42 24 FD FF 00 10
00 00 00 00 00 00 00 00
00 00 E4 C2 00 00 00 00
00 00 00 00 9A F9 15 44
00 00 00 00 00 00 00 00
00 00 00 00 9A F9 15 44
9A F9 15 44

いや、たぶんこれだけなわけがない。

でも9A F9 15 44っていうのはSDDATA.BINの中に相当数存在してる。
NULLのところはFFで埋まっているのだけれど、その前後に必ず9A F9 15 44があるから多分無関係。だから68バイトではなくて24バイト？じゃE4 C2って関係ないのか？

ていうか、MaTiAz氏のUS版は1%しかゲームが進んでいないはずなのに、いままもすけがオリジナルを復号化したのは2%進んだデータだからよりデータ量多いはずなのに、オリジナルはFFで埋め尽くされているところにspartaはことごとくデータが埋まっている…
どれかがバッファーオーバーフローさせた後実行されるコードなんだろうけど、特定できない。やっぱりバイナリだけでなんとかなるものじゃないか…

不思議なのが、このSDDATA.BIN、オリジナル日本版は同じ2%くらいの達成率データでもFFで埋まっているところが全然ない。
必ず何か書かれてる。

どうもUS版はFFで埋まっているところ＝NULLで使っていないエリアに実行コードが書かれているくさいけど、日本版には同じような空きエリアがない。

EU版や韓国版のSDDATA.BINを見てみたいけれど、公開されているのは暗号化されたデータばかり。
そもそも唯一US版だけが初期に暗号化されていないデータも配布していたのでこうして中をのぞきこめるわけだが、EUと韓国でFFで埋まっているところがどうなっているのか見てみたい。
すでに現時点で3種類のexploitセーブデータがあるわけだが、比較すればなにか分るかも。

ここで問題が。
EU版でUMDではなくISOファイルを使ってやってみた。やってみたがフリーズして電源が落ちる。
pongもボンバーマンもRtypeも落ちる。起動しない。
起動しないことにはデータを復号できない。名前をバッファーオーバーフローしないように戻せばフリーズはしないのかな？でもそんなことしたらコード部分をオリジナルデータで上書きされるかも。
韓国版なんでそもそも手に入らないし、いい案だと思ったけど比較は無理だ。
ちなみにUS版でもHomebrew起動しない。UMDでないとだめなのか？それともCFWだからか？愛着のあるPSP-1000使ったせいか?だめだ、ワカンネ。

それにしてもなぜ日本版はFFで埋め尽くされていないのだろう。いったい何が書いてあるのだろう。素人ではやっぱりハッキングは無理か。
だめもとでPSPのSDKとか入手してみたけど、さっぱり使い方がわからない。
逆アセンブラみたいなものあればなんかわかるかもしれないけど、PSPセーブデータ用のものがあるのかどうかもわからない。
らぼこ使ってもセーブデータを改造するわけじゃないしな。
DSならNDSDIS2とかあるんだけどな。

ふといやな予感がした。
もしかすると、日本版だけ放置されてるのは、誰も手をつけてくれないのではなくてFFで埋まってるところがなくてexploitを実行できるコードを記述する空きエリアがないせい？
だとしたら日本はお先真っ暗？

[本日の格言]
素人は手を出すべからず　ひたすら待つべし

やっぱり誰か、頼む。