PSP Ver2.0のセキュリティーホール

巷で騒ぎになっているようですが、ここでは別の(画像とビュアーという)観点から語ってみます。

BMPは非圧縮な画像のため、この手のセキュリティーホールが入る余地はほとんど無いですが、
JPEGやTIFFやPNGといった圧縮画像や画像コメント情報があるフォーマットにはセキュリティーホールは沢山あります(言い過ぎかな…)

偽のヘッダ情報と、それに付随した特殊なコード(簡単な例だと特定アドレスへの分岐命令等)を
ファイル内に埋め込むことで、ビューアーがその領域をアクセスすると任意のコードが実行できるようになっちゃいます。

今回ポイントは、
予め壁紙登録しておくPNG画像は画像ではなくプログラムコードであり、
それが壁紙としてVRAM上に表示されている(メモリ上に展開されている)

というところでしょうか。

で、問題のTIFF画像をXMBから読みに行くと、サムネイル画像を展開する際にバッファオーバーフローを引き起こし、
壁紙として表示中のVRAM上のアドレスにジャンプして任意のプログラムを実行させるという手順を踏んでいます。

実際にTIFF画像によって発生させて実行することのできるコードサイズには限りはあるのですが
今回は壁紙登録という裏技(?)を使ってVRAM上のアドレスにジャンプするだけのコードを埋め込んでおけばよいということで
あとはVRAMのメモリ容量が許す限りの任意のコードが実行できるようになります。
(今回のは本体Versionを1.0にすりかえてるだけでしょうか)

うまいことを考えましたね・・・(分かってしまえば簡単ですが)

まぁWindowsでさえこの手の画像関係のセキュリティーパッチは今でも当たってるので
(最近だと2005年7月のJPEG GDI+関係のパッチでしょうか)
PSPに常に最新のセキュリティーを保てというのは酷かもしれません。

が、既に自明になっているセキュリティーホールに関してはちゃんと潰しておいたほうがよいのではないでしょうか?

#せっかく9月頭に2.0のファームリリースしたのだからそれ以前に判明してる分ぐらいは…

あとファームのアップデートが99%で失敗したり、その後の起動時に警告が出るのは
PSPの設定ファイルがVer1.0系とVer2.0系に互換性がないためだと思います。
設定ファイルが壊れてしまうのはよくあること(?)なので
「工場出荷時の設定に戻す」という機能は必要だとは思いますが、これが仇になりましたかね。

と、ここまで書きましたが、この手の質問には特に回答しないので全ては自己責任ということで。

#よく理解せずにやっちゃうと壊れちゃうかもしれませんよ!(と警告はしておく


[今回の総括]
え?JVIEWのセキュリティーホールですか?
そりゃいっぱいありますよ!なんも対策してないので!えぇ(汗

#明日は我が身 (ガクブル
[PR]
# by maman_jv | 2005-09-29 13:00 | PSP全般

昔に書いたJVIEW妄想案が別の場所で実現しつつ

以前ここで書いてた妄想がようやくどこかの誰かさんによって実現されているようですね。

WiFi Jukebox

PSPRadio
でしょうか(あえてリンクはしません)

軽く覗いてみました(WiFi Jukebox)
・ストリーム再生ではないのでオンメモリ上にMP3をロードする必要がある
・10M以上のファイルは再生不可(上記要因のため)
・libmadによる再生 (44kHz以外は再生不可)
・Windowsマシンをサーバーにするサーバークライアント方式
・サーバープログラムは付属(同一作者?)

まだまだこれからといった感じでしょうか。
(オンメモリロード再生だけでいいならJVIEWでも今すぐできそうだな…)

で、こっち(PSPRadio)はというと
・mp3のストリーム再生可能
・44 22 11kHzのmp3をサポート
・AACサポート
・プレイリスト対応
とこっちはちょっと開発が進んでいるようです。

2つを比較してみると
・WiFi Jukeboxは独自プロトコルでmp3データを一括受信して再生するタイプ
・PSPRadioはHTTPプロトコルでmp3データをストリーム受信して再生するタイプ
でしょうか。

PSPRadioとUzuを使えば家内ストリームサーバーが組めそうですね。(試してなので出来るか謎)

両者の今後を見守りたいと思います。
[PR]
# by maman_jv | 2005-09-29 12:59 | PSP全般

Cell開発キット?

とりあえず、開発好きな物としては興味を引かれる発表がありましたね。

次世代プロセッサCellのチップセットおよびリファレンスセットの開発・販売について

10/4のCEATECでどんなものか分かるみたいなのでちょっと気になってみたり。
といっても単にCellが使えるだけなのでPS3とは全く関係ないですな。

果たしてこれは個人で買える物なのだろうか・・・?

#映像関係の仕事をやってるので会社で買ってくれないものかと期待してみたり(多分無理)
[PR]
# by maman_jv | 2005-09-26 18:30 | PSP全般

自分メモ1

あると便利かもと思った機能

●(MP3が再生していない時に)一定時間操作がないと自動でスリープする

単にリモコンで一時停止したままスリープするの忘れてて
気がついたら電池がなくなってしょんぼりだったことが(以下略
[PR]
# by maman_jv | 2005-08-31 08:00 | PSP全般

PS3で使われるCellの情報(無駄に長文)

ついにSCEIから公開されましたね [http://cell.scei.co.jp/index_j.html]
ドキュメント好きな人間としてはこういうのを読むとニヤニヤしてしまうものです。

PS2でPS2 Linux購入した時には、簡単なEEとVUのマニュアルが
付いてただけだったのでちょっとしょんぼりだった思い出が。
当時はこんなPDFを読んでニヤニヤしてたこともあったかなぁ(遠い目)
東芝2000年10月技報 「家庭用ゲーム機を進化させるリアルタイム三次元CG技術」

これまで
・PS1 → ねっとやろうぜ!
・PS2 → PS2Linux
・PSP → 今回
というように各プラットフォームでいろんな物を作ってきたわけですが
さて、PS3は一般ユーザーが中身を弄れる日は来るのでしょうか・・・?

ついでにこれまでの人生で触ったことのある開発環境でのコード比較をしてみる。
過去どこかのサイトで書かれていた情報を基にしています。(そのサイトは現在消滅)

[各プラットフォームでの単純な演算集]
---------------- 開始 ----------------
// C言語 (unsigned short i)
i=0x8000;
i=(i>>8)&0xff;

// Verilog
assign i[15:0] = 16'h8000;
assign x[7:0] = i[15:8] && 8'hff;

// R3000(PlayStation)
ori t0,zero,$8000
srl t0,t0,8
andi t0,t0,$ff

// VU(PlayStation2-VectorUnit)
NOP IADDIU VI01,VI00,0x7fff
NOP IADDIU VI01,VI01,1
NOP MFIR.x VF01x,VI01
ITOF4.x VF01x,VF01x IADDIU VI02,VI00,0xff
FTOI0.x VF01x,VF01x NOP
ITOF4.x VF01x,VF01x NOP
FTOI0.x VF01x,VF01x NOP
NOP MTIR.x VI01,VF01x
NOP IAND VI01,VI01,VI02

// TMSC62x
zero .L1 A0
set .S1 A0,0xf,0xf,A4
shr .S1 A4,8,A4
extu .S1 A4,24,24,A4

// 68000
move.w #$8000,d0
lsr.w #8,d0
andi.w #$ff,d0

// x86系
mov ax,8000H
mov cl,8
shr ax,cl
and ax,ffH

// Z80(番外編)
LD H,80H
LD L,00H
SRL H
RR L
SRL H
RR L
SRL H
RR L
SRL H
RR L
SRL H
RR L
SRL H
RR L
SRL H
RR L
SRL H
RR L
LD A,L
AND ffH
---------------- 終了 ----------------

全部を眺めてみた感想
・C言語
 はい。全てのコードのオリジナルですが、全く意図のないコードです。
 まぁ内容に関しては華麗にスルーしてください orz
・Verilog
 HDL言語(ハードウェア記述言語)ですね。
 これも実際はこんなコードは書かないでしょう(定数入れて終わりなので)
・R3000
 PS1のアセンブラですね。PS2やPSPにも関連しますかね。
 このコードだけレジスタへの値設定をORでやってるので
 意図的な最適化が入っているとも言えるかも・・・
・VU
 PS2のベクターユニット(VU)向けに記述するとこんな感じに。
 元々ベクタ演算に特化したものなのでITOFやFTOIみたいに
 不要な命令が入ってますな。他と比べて異彩を放っているかも。
 この辺りがVUが扱いにくいと言われる所以なのかもしれないですね。
 (実は知らないだけでもっと簡単な記述があるのかも?)
・TMSC62x
 TI社のDSPですな。さすがにこんなサンプルコードではパイプラインも組めず・・・。
 これに関しても最初のロードをZERO(内部的には同じレジスタの引き算)で置き換えてます。
 まー設定する値が0x8000だからZEROとSETが使えるという話でもあります。
 これも意図的な最適化ですね。
・68000
 MC社の68系ですな。ニーモニックが直感的で分かりやすく、
 レジスタモードやアドレッシング等含めて個人的には一番好きなアーキテクチャーです。
・x86
 Intel社の86系ですな。個人的には一番苦手なアーキテクチャーです・・・。
・Z80(番外)
 8bit演算のみを使うとこんな感じに。ゴメンナサイ無理させすぎました。orz
 これこそ意図的な最適化(汗)。HLで記述すればこんなにはなりませんね。

とまぁこんな感じにCellの登場をニヤニヤしながら待ってます(オチ無し)

#普通に最適化かけたら0x80代入して終わりですけどね!
[PR]
# by maman_jv | 2005-08-26 22:00 | 日常

GPU対応はやっぱりかなり面倒ですな

GPU使っていろいろやろうとするとクリアすべき問題点がたくさんあって面倒ですねぇ・・・

何が面倒かって
(1)読み込む画像のサイズは任意サイズを想定しなければならない
(2)テクスチャーサイズは2の階乗
この2つがなかなか相容れない条件なのがね・・・

簡単にクリアしようとすると内蔵ビュアーと似たような感じになってしまうのだけど
このソフトの趣旨から言えばそれは回避したいし

あーそうだ、シームレス縮小無しとかに限定すれば一気に簡単になるなぁ
(回転/スクロール/シームレス拡大のみOKとか)

シームレス縮小に対応時に考えなければならないこと
(A)2の階乗単位でテクスチャー分割すると分割境界のリニア変換が綺麗にいかない
  →オーバーラップして誤魔化せないものか?(試してないけど期待薄)
(B)巨大画像の場合MIPMAP化は必須なのか
  →多分MIPMAP切り替え境界で画質が変わってしまう

(A)はメモリ効率は今までとほぼ変化無しだけど見た目の画質が落ちる。
そもそも繋ぎ目がわかってしまうのでシームレス画像とは呼べない。

(B)は見た目の画質はテクスチャー切り替え境界付近以外では保障されるがメモリ効率が極端に悪くなる。
また、縮小時に画質が変化する部分ができてしまうので厳密なシームレス縮小とは言えない。

可変サイズの画像を扱わなければならないから考慮しないといけないことが沢山あって面倒だなぁ

内蔵ビュアーがなぜあんな風になったのか(そうせざるを得なかったのか)
今更ながらに実感してる次第であります。 > 内蔵ビュアー製作担当の方心中お察しします

#もっとサクサク解決できる技術レベルと時間が欲しい(最近JVIEWに時間取れて無し)
[PR]
# by maman_jv | 2005-08-18 22:00 | PSP全般

画像閲覧のLRキー設定

>おいちゃんさん
>キー割り当てについてですが、LとRを入れ替えてみたんですが反映されていないようなのですが・・・
>LやRにその他の割り当てをするのは問題ないようなんですが、
>標準設定からLとRを入れ替えがうまくいきません。ご検討頂ければ幸いです。

はっはー、キー設定のパターンが以前と変わったためでした。
(設定が細かくなってわかりにくくなったためともいいますが)

画像閲覧のLとRの入れ替えは[Viewer key set]の
LTRIGGERとRTRIGGERで機能変更してください。
[prev img]と[next img]がそれに該当します。

[Normal key set]の[prev page]と[next page]は
Filerモード時のページスクロール用のキー設定になります。

というわけなので現在の版でも正しく動くと思いますので設定変更してみてくださいm(_ _)m
[PR]
# by maman_jv | 2005-08-09 13:30 | PSP全般

やっぱいろいろと

GPU対応やっぱ面倒ですなぁ

最初出すときはいろいろ制約がついてるかもしれません。
(サムネイル表示周りでいろいろと手間取ってたり)
[PR]
# by maman_jv | 2005-08-08 08:00 | PSP全般

拡大縮小率の設定と表示開始位置

TOMさん
>小説などスキャン時にOCRしても結果のチェックが面倒なので
>スキャン→jpgしたものを読んでいますが、

トリミングとかをしてないということですよね?

で、

>(拡大して余白の部分が画面外になる程度?)

ということは拡大縮小率の指定を可能にして
さらに表示開始位置は前画像のを記憶しなくちゃダメってことですよね?

現状次画像を閲覧する場合はImagePosの設定に従って
毎回表示位置が初期化されます。

#ImagePosに前回位置を引き継ぐとかを追加すればいいのだが例外チェックが面倒だな・・・

そろそろGPU周りにも手をつけ始めたので
回転(90度単位)+拡大縮小もそのうちできるようになるはずです。

ただ、PSPのメモリに入りきらないような巨大なJPEG画像に関しては
事前に縮小展開されているため、画像解像度は非常に低くなります。

また、現状のVer0.5系では、ScreenFitの設定を行なうとキャッシュメモリには
フィッティング後の画像が登録されているため、キャッシュメモリをある程度効率的に利用できます。

ですが、GPUを使うようになると実サイズの画像をキャッシュメモリに登録するため
メモリの効率はVer0.5系より悪くなるでしょう。

まぁこれは仕方が無いことなのでどうしようもないわけですが・・・ orz
[PR]
# by maman_jv | 2005-08-02 00:00 | PSP全般

復帰完了

とりあえず、ようやく光化完了。

まぁいろいろありましたが、開通したので善し。

無線LAN環境も構築したのでPSPとも接続可能に
あー、ということは、PSPのVer2.0を確かめるいい機会か・・・

画像ビュアーも気になるがWebブラウザも気になるし
[PR]
# by maman_jv | 2005-08-01 23:00 | 日常