日々の戯言


バックナンバー

1997年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1998年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1999年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2000年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2001年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2002年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2003年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2004年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2005年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2006年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2007年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2008年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2009年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2010年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2011年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2012年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2013年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2014年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2015年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2016年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2017年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2018年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2019年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2020年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2021年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2022年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
バックナンバー内のリンクは無保証です

11月4日(火) AVHDD crack [2]

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

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

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


11月6日(木) 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 キャプチャ) との比較から、暗号文 - 平文ペアの作成と進むつもりだったのになぁ。


11月11日(火) 3年前の寝言

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


11月14日(金) 間違ったデジタル放送の楽しみ方 [1]

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

CM OP

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

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


11月15日(土) 間違ったデジタル放送の楽しみ方 [2]

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

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

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


11月16日(日) 間違ったデジタル放送の楽しみ方 [3]

WOWOW の利用している MPEG エンコーダの問題点その1、シーンチェンジ判定について。このエンコーダはどうやら実際の符号化の前に 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 ピクチャとして処理したほうが符号化効率がいいはず。


11月17日(月) 間違ったデジタル放送の楽しみ方 [4]

WOWOW の利用している MPEG エンコーダの問題点その2、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 にとどめておけば、それなりにビットを節約できるのに。

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


11月18日(火) 間違ったデジタル放送の楽しみ方 [5]

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

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

A0 A1 A2 A3 B0 B1 B2 B3

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

A0T A0T A1T A2T A3T B0T B0T B1T B2T B3T
A0B A1B A2B A2B A3B B0B B1B B2B B2B B3B

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

A0T A0T A1T B0T B1T B2T B3T
A0B A1B A2B B1B B2B B2B B3B

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

0P 1B 2B 3P 4B 5B
A0T A0T   A1T   B0T   B1T   B2T B3T
A0B   A1B   A2B   B1B   B2B B2B B3B

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

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

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

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


11月19日(水) 間違ったデジタル放送の楽しみ方 [6]

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

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


11月20日(木) InterBEE 2003

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

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


11月21日(金) Adobe と特許

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

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

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

特許 3390979

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

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


11月25日(火) 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 刺した後で電源を入れるのを忘れてしまった。連休中実家で過ごしてて、アパートに戻って気がつくこの虚しさ……。


11月30日(日) 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]。これで2つの 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 8 バイトの間隙付きで、8 バイトブロック 2 つが変化
0x0fef 8 バイトの間隙付きで、8 バイトブロック 2 つが変化
0x0ff7 8 バイト分のデータのみが変化
0x0fff 0x0ff7 を変えた場合の次の 8 バイト分のデータのみが変化
0x1007 比較的大きな領域で変化。キャプチャデータのドロップも発生

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

オフセット A B C D
0x0fe7 ×   ×  
0x0fef   ×   ×
0x0ff7     ×  
0x0fff       ×

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

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


1997年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1998年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1999年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2000年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2001年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2002年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2003年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2004年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2005年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2006年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2007年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2008年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2009年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2010年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2011年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2012年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2013年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2014年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2015年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2016年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2017年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2018年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2019年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2020年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2021年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2022年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
バックナンバー内のリンクは無保証です

[TOP]