日々の戯言

１１月４日（火）　AVHDD crack [2]

状況は見積りよりも大幅に後退。以下問題点。

• 書き戻しのタイミングによって、データ書き込み先ブロックが変化する
• 書き込まれたデータブロックのトータルサイズが 192 byte TS 時点と比較して増加する
• 同じファイルを書き戻し、相違ブロックだけを切り出したバイナリ比較が一致しない

というわけで、平文ブロック - 暗号文ブロックペアを作ることが不可能という状況になっている。8192 block に対する総当りでの鍵推定で突破口を開くしかないのかなーという絶望的な状況。今世紀中に終わるのだろうか。

一応 C2_DCBC をリトルエンディアン用に書き直して総当り用のコードを書き始めてはいるものの、そろそろフルバックアップ＆同一 HDD へのリストアによる moov もどきを真剣に考えるべき時期なのかもしれない。

１１月６日（木）　AVHDD crack [3]

敗北宣言。C2 暗号の S-Box が非公開なため、総当り用プログラムさえ作れずに敗北。こっち方面の努力は諦めることにした。さすがに (256!)*(2^56) の全数探索をやる気力はでない。

ちきしょーアルゴリズム公開というのなら S-Box ぐらい公開しやがれー。S-Box 非公開で何が暗号アルゴリズム公開だー。

以上負け犬の遠吠え。さて、長い間放置してしまった VFAPI プラグインの方に戻るとしよう。

私は諦めてしまったけれども、ひょっとしたら居るかもしれない後に続く犠牲者の為に。まず、C2 暗号サンプル実装（S-Box がダミーなので実用にならない） とか。

総当りができそうだったら、正常系 (Digital BS 録画 -> i-Link キャプチャ) と異常系 (正常系のデータ部を 1 bit だけ反転して書き戻してから、i-Link キャプチャ) との比較から、暗号文 - 平文ペアの作成と進むつもりだったのになぁ。

１１月１１日（火）　３年前の寝言

３年前は 寝言 で済んだのだけどなぁ。software patent ML のアーカイブから [software-patent: 182] Re: オープンソース側の自衛 を眺めて悲しくなる。とうとう世の中はここまで来てしまったのか。いや、現行特許法を厳密に解釈する限り、まったくもって正しい意見なんだけど。

１１月１４日（金）　間違ったデジタル放送の楽しみ方 [1]

1 COPY 化される前に撮っておいた某 TS ファイルを眺めながら、WOWOW って、一部 CM はコンポジットだけど、それ以外はコンポーネントだったんだな〜と知り、惜しい局を亡くしたと悲しくなる。以下判断材料。

CM	OP

CM 側には NTSC 特有のドット妨害が顕著に出ているのに対して、本編側にはドット妨害どころかクロスカラーすら出ていない。これが BS-i とかだと……いかにも D2 アプコンと判るドット妨害＆拡大に伴うレート不足でのモスキートのおまけつきだからなぁ。

こんなノイズ（当然ながらフレーム周期で発生場所が入れ替わる）を再現するために貴重なビットを費やしてるのかと思うと……ホントもう少しマシな機材を使ってほしい。

１１月１５日（土）　間違ったデジタル放送の楽しみ方 [2]

さらに間違い度を向上させるために。7/24 に投棄した某仕事の副産物を 更新 し、さらに例の TS ファイルを読み込んで MV や QP 等を眺めてみる。結果は、流石 WOWOW と言うべきか。Repeat First Filed (RFF) フラグを使用した 24p 符号化までされていることを知って、ますます惜しい局をなくしたと悲しくなる。

映画等を放映することを考えると 24p (RFF) 対応かどうかで画質が大幅に変わるから、有料放送での映画目的の加入者からの収入に依存してる WOWOW として対応は当然と言えるのかもしれない。けれども他の局がアレなことを考えると、ものすごく貴重な存在のような気がする。ただし、いくつか欠点も見つけたので、その辺の指摘とかをしておく。

• シーンチェンジ判定がきつすぎ
• MV への bit 配分が大目（問題にするほどじゃないかもしれないけど）
• フィールドピクチャに非対応（これは仕方がないような気もする）

詳細は次回以降に解説の予定。

１１月１６日（日）　間違ったデジタル放送の楽しみ方 [3]

WOWOW の利用している MPEG エンコーダの問題点その１、シーンチェンジ判定について。このエンコーダはどうやら実際の符号化の前に 3:2 プルダウンとシーンチェンジの検出処理を行っているらしい。例のアプリケーションで眺めていると、P ピクチャであるにもかかわらず、MV が一切存在しない（動き補償を行わずすべてイントラ MB としている）フレームが存在することからそれが判る。

すべてイントラ MB で符号化するなら、いっそ I ピクチャとして符号化したほうが macroblock_type の VLC でビットの節約ができるのになぁ、とは思うものの、シーンチェンジ検出自体は悪いことじゃない。実際にシーンチェンジしているなら、そこはイントラ MB で符号化したほうがビット数を節約できるし、無駄な動き評価でリソースを食わずに済む。ただし、問題なのはその精度。

0 I	1 B	2 B	3 P	4 B	5 B	6 P	7 B	8 B	9 P

上のシーケンスで、"3 P" のフレームが（シーンチェンジとして）オールイントラで符号化されていればそれは問題ないのだけれども、実際には "3 P" フレームは通常の P ピクチャとして MV を持つ形で符号化され、何故か "6 P" フレームがオールイントラで処理されているのを見つけてしまうと、ちょっとそれはどこか間違ってるんじゃないかなぁと思ってしまう。

確かに画面の左半分で MPEG の苦手な回転運動（風車）があるとはいえ、それでも右半分はまったく動きの無いシーンなのだから、絶対に普通の P ピクチャとして処理したほうが符号化効率がいいはず。

１１月１７日（月）　間違ったデジタル放送の楽しみ方 [4]

WOWOW の利用している MPEG エンコーダの問題点その２、MV (motion vector) へのビット配分について。このエンコーダはどうやら動き評価 (Motion Estimation) において、MV が消費するビットを考慮していないらしく、単純に差分値が一番小さくなる MV を採用しているらしい。

次の 0P と 3P から間の 1B を予測するケースで、1B のベクトルを眺めてみる（JavaScript On で 1B 画像の上にマウスカーソルを移動で MV 表示）と、ちょっとそれは問題があるんでないのという MV が頭の辺りに見えたりする。補足しておくと、黄色が 0P からの予測でシアンが 3P からの予測。

0P
1B MV
3P

0P, 3P 共にオールイントラで符号化されてるのも突っ込みどころではあるのだけど、1B 自体が 0P からの MV(0,0) 予測だけでもよさそうなのに 3P から無理やりに似た部分を探し出して MV にしてるのはビットの無駄遣いなんじゃないかなぁと思う。また、最大 MV が (15,15) 以内に収まるフレームでも、B ならば f_code(5,3), P なら f_code(5,4) としてるのももったいない点。そのピクチャに含まれる MV を表現するのに必要な f_code にとどめておけば、それなりにビットを節約できるのに。

この辺の事情およびこの種の最適化の必要性については、今年５月にあった 2003 NHK 技研公開「ハイビジョン映像の高圧縮符号化技術」を見た人なら納得してくれるんじゃないかと思う。（ただアレは比較対象が画質最低な TM5 だったうえに、符号化時間が TM5 よりも遅いっちゅう話だからまた別の問題があるけど）

１１月１８日（火）　間違ったデジタル放送の楽しみ方 [5]

WOWOW の利用している MPEG エンコーダの問題点その３、フィールドピクチャ非対応について。MPEG-2 にはフレームピクチャとフィールドピクチャというものがあるのだけど、たいていのエンコーダは対応が面倒なのでフィールドピクチャの存在を無視している。WOWOW が利用してるエンコーダもやっぱりフィールドピクチャには対応していない。

大抵の場合、フィールドピクチャと同等の処理がフレームピクチャでのフィールド DCT やフィールド ME でできるのでこれは問題にならないのだけれども、B ピクチャの途中でシーンチェンジが発生する（TOP フィールドがシーン A で BOTTOM フィールドがシーン B という）場合だけはフィールドピクチャでなければうまく対処できない。

たとえば上の 23.976 fps シーケンスがあった場合。これは 3:2 プルダウンによって下の 29.97 fps に変換される。

このまま MPEG 符号化される場合は、何も問題はおきない。しかし不幸なことに、マスター作成時に尺をあわせるため A2T/A2B, A3T/A3B, B0T/B0B の 3 フレームが削除されたとする。

これは、RFF が使用されて次のように符号化される。

2B フレームのボトムフィールドには A シーンが、トップフィールドには B シーンが入ってしまった。動き補償は同じシーンから実行した方が効率がよくなる（差分係数が低くなる）ので、ボトムフィールドに関しては 0P フレームから、トップフィールドに関しては 3P フレームから予測するのがベストになる。けれども、フレームピクチャではマクロブロック単位で前方予測のみを行うか、後方予測のみを行うか、双方向予測を行うかしか選択できない。マクロブロック内のトップフィールドには後方予測を行い、ボトムフィールドには前方予測を行うという方法は選択できない。

こういった場合に 2B フレームに相当するフレームがどうなるかというと、こうなってしまう。

レートに余裕のあった画面上ではそれなりの画質になっているものの、画面下へとエンコードが進むにしたがって画質が急速に悪化していくのが判る。

フィールドピクチャ符号化に対応していればフィールド単位で完全に別の予測を行うことができるので、こういう場合でも片方のフィールドを前方予測のみで、他方を後方予測のみで符号化して上記悲劇を回避することができる。……のだけれども、はっきり言ってこれは仕方がないんじゃないかなぁと思ったりする。フィールドピクチャに対応しようとするとエンコーダーを作る場合の面倒くささが倍増するんで。

１１月１９日（水）　間違ったデジタル放送の楽しみ方 [6]

今までいろいろとケチをつけていたけれども、それでも WOWOW の画質はマシな方で、他の局のビットストリームはもっとすさまじいものだったりする。たとえば動き検索範囲が広けりゃそれでいいって訳じゃないだろうと突っ込みたくなってしまう BS-Japan の MV とか、どんなレート制御アルゴリズム使ってるんだとあきれてしまう BS-i の QP とか。（どちらも巨大な画像なので注意）

しかし、こういう間違った楽しみ方も、来年４月には完全にできなくなってしまうのかと思うと悲しくてたまらない。あー冬茄子支給後に「間違った DVD+HDD レコーダの楽しみ方」を書くための機種選定用情報収集を始めなければ。

１１月２０日（木）　InterBEE 2003

昨日から開催されている InterBEE 2003。今年は幕張行きを回避することに成功した。代わりに他の人が犠牲になってしまったけど、自分さえ良ければそれでいいという方針の元、AV watch / ZDnet の記事でも待ちながら過ごすことにしよう。

今年に入ってからは CODEC（MPEG-4, MPEG-2, H.264）とかの仕事ばかりで UI 側を作ることが無かったおかげなのだけれども、このまま行けば来年も行かずに済むだろう。出展者パスで会場を回れないのは残念だけど、一般人が見てて面白い展示は少ないからなー。それよりは説明員としてブースに張り付かなくて済む方がありがたい。

１１月２１日（金）　Adobe と特許

Adobe & 特許と聞いて連想するのは特許 3390979。特許庁の検索は使いづらいので、クレームだけを引用しておく。

【請求項１】 第１、第２のクリップのシーケンスと該第１、第２のクリップ間の特殊効果遷移とを含む映像プログラムを編集する方法において、(a) 時間行を表示し、(b) 第１のクリップの少なくとも一部の描写と、第２のクリップの少なくとも一部の描写および該第１、第２の描写間の特殊効果遷移の種類を示す遷移アイコンとをそれぞれ同時に時間行に沿った異なるトラックに表示して映像プログラムを示すディスプレイを生成し、(c) そのディスプレイを修正して映像プログラムを編集することを特徴とする映像プログラムを編集する方法。

本当はこの後【請求項２】・【請求項３】と続くのだけれども、それは請求項１を実現するソフトウェアを使った装置についてなのでとりあえず省略。えーとクレームを読んでも知らない人は何を主張してるのか判らないと思うので、実例を。

詰まるところ、特許 3390979 というのはこーゆー画面でビデオ編集する方法の事。肝はタイムライン展開したビデオクリップに最低１つはクリップ内の画像が含まれていることと、クリップ間の遷移エフェクトをアイコン表示してるところ。特開平07-046462 の段階ではただのタイムライン展開も含むと解釈できるようなあいまいなクレームが書かれていたけど、流石にそれでは特許は取れなかったらしい。

他社製のビデオ編集ソフト（例えば Canopus の EDIUS とか [screenshot]）でタイムライン上のクリップがただの文字だけになってたりするのは、この辺の特許が影響してるのではないかと邪推している。

１１月２５日（火）　AVHDD crack [4]

諦めたんじゃなかったのかという指摘は無視する方向で。現在まったりと save/restore attack 中。

AVHDD が "CPRM for Portable ATA Strage" の Dynamic Media ID 対応の独自ファームウェアを使っていて、save/restore attack に対処済みだったらどうしようかと思いながら、昔ダンプしておいた HDD イメージファイルを書き戻してみたところ、Rec-POT 側から正しく HDD を認識してくれて、当時のデータを復元できたので安心した。これでとりあえず 1 COPY の物を消滅させずに済む。

攻撃の幅を広げることもできるので、もう少し頑張ってみようかなという気になってくるから不思議。相不変 S-Box は不明なままなんだけど、なんとか既知平文攻撃はできそうだ。

しくしくしく。HDD 刺した後で電源を入れるのを忘れてしまった。連休中実家で過ごしてて、アパートに戻って気がつくこの虚しさ……。

１１月３０日（日）　AVHDD crack [5]

さて AVHDD は dump & restore によって破壊されることはないと判明したので、実際のデータブロックがどのように暗号化されるのかというあたりを調べてみる。

利用する道具は今までと変わらない。まず必要なものは Rec-POT 本体（120G モデル）。それと IDE HDD を raw dump できる環境（FreeBSD with 300G HDD）。最後に TS/IEEE1394 キャプチャが可能な環境（MardocController/WinXP Home）。後は各種ソフトウェアの知識色々。

まずは下準備。AVHDDPlayer で全データを削除し、その状態で HDD の内容を dump する [DUMP:A]。次に、適当な TS データを IEEE1394 経由で書き戻し、再び HDD の内容を dump する [DUMP:B]。これで２つの dump データができたので、この二つをバイナリ比較し、書き戻した TS データがどこに書き込まれたのか（相違ブロック）を調べる。結果 136M 近辺と 1200M 〜 2400M に相違が見つかったので、136M 近辺は FAT 領域やらメニューエリアだろうと推定。後ろの広い領域にデータがあるに違いないと判断する。

次に第二段階。[DUMP:B] を作成する為に書き戻した TS データを複数回 IEEE1394 キャプチャし、キャプチャデータ間でバイナリ比較を行う。結果、キャプチャ開始タイミングの違いによるオフセットの相違はあるものの、それ以降のデータは完全一致（188 byte TS キャプチャの場合）することが判明した。

さて最終段階。[DUMP:B] の TS データが書き込まれている 1200M - 2400M の一部を 1 bit だけ反転させてデータを AVHDD に書き戻し、これを TS キャプチャしてみる。とりあえず 1638400000 〜 1638408192 の 8k ブロックに着目して、0x0fe7, 0x0fef, 0x0fe7, 0x0fff, 0x1007 バイトの最下位ビットを反転させたもので試してみた。

ここで、0x0fe7, 0x0fef, 0x0ff7, 0x0fff の場合について、もう少し判りやすい表にしてみる。

上の表の「×」であらわした部分が、そのオフセットのデータを変更した場合に平文に影響が出た部分を示している。これから以下のことが判断できる。

• CBC モードのリセットポイントが 0x1000 にある（おそらく 4k ブロック単位で CBC 暗号化が行われている）
• ブロックはアドレス下位 4 bit が 0x0〜0x7 のデータと 0x8〜0xF のデータの二つに分割されて、それぞれ別の CBC モード暗号化が行われている（おそらくビットエラーへの耐性を上げるため）

というわけで、目出度く「暗号文-平文」ペアの入手に成功。フォーマットの方も少しずつ見えてきた。後は S-Box さえ判れば総当り攻撃が可能なのだけど……。ソフトウェア DVD Audio プレイヤーのクラック（DVD Audio は CPPM で暗号化されてるので同じ C2 暗号が採用されている）に挑戦してる人も居るみたいだけど、成功報告はまだどこからも出ていないし……内部情報のリークとか期待しても無駄だろうなぁ、もし自分が開発者だったらと考えてもリークするなんてありえないし。