新着記事

2005年12月02日

挙動不審?まったくもってその通り

Suspicious Activity? Indeedより。

挙動不審?まったくもってその通り

2005/11/21(月) 02:26:13 + 0100

DRM付きのソニーCDを物色するために週末をまるごと費やした甲斐もあり、 私のコードが無許可で本当に再配布されているのかどうか、自ら検証することができた。 結果的に、ひどい添加物による挙動不審?をひとつ発見することになってしまったが。 まったくこいつは必要以上に楽しめるポストモダン・ジャズアルバムだよ。 幸運にも、Celine DionのCDを見つけられたもんでね。

案の定、そのCD特注のプレイヤーをインストールすると、 aries.sysとかいう秘密のドライバと一緒に、いくつかの興味深いファイルまでもがインストールされる。 例えば$sys$filesystemディレクトリにすっかり隠されている$sys$DRMServer.exeだ。 私は嫌な物体を速やかに始末し、真に重要なファイルであるECDPlayerControl.ocxの調査に取りかかった。 このファイルからは、Sebastian PorstMatti Nikkiによって、数多いプログラムの断片が発見されている。 具体名を挙げるとmpglib、LAME、faad2、VLC、その他もろもろ。

問題のDRMSコードがVLC由来である証拠

もはや言うまでもないことだが、ECDPlayerControl.ocxとVLCのソースとの間には、その関数や構造における明らかな類似点が複数存在する。 たとえ暗号プロトコルを必要とするほどに緻密な実装をしようとも、 2つに分かたれた実装に認められる多くの類似点が示す確からしさを退けることなど到底できはしない。 とりわけデータ構造と定数テーブルなど、完全に一致するようにも見える。 だが、そんな事実さえ霞んでしまうほどのまったくもって強固な証拠を発見したと考えている。

drms.cの原型は、2004/01/05Jonによって書かれたものだ。 私はその後2004/01/18に同ファイルをハックして再構築し、 さらにリバースエンジニアリングしたMD5関数およびAES関数を綺麗に実装しなおした。 2004/05/05、JonはDRMSv2のサポートを加えたが、 こちらについても私は2004/05/08にコードを再構築している。 これら変更の一部は、VLCに特化したものである。 (例えば何故かVLC外部での利用に適さないコードをうっかり書いてしまったけれど、 そのくせ外部のMD5ハッシュ生成機構まで使用可能なコードも書けてしまったというような場合を除けば) こういったコードこそECDPlayerControl.ocxから探し求められた具体例である。

例として、Jonによる原型となったコードには以下の命令が記述されていた。


    p_acei[ 4 ] = 0x5476212A;

このlong word型配列の全バイトが0x20と0x7fの間で構成されていたので、 のちに次のよう書き直される運びとなった。


    char p_secret1[] = "Tv!*";

上記の変更はコードを人間にとってより読みやすくするために行ったもので、 理由は、AppleのDRMSプロトコルにまつわる数多い秘密がASCII文字列に隠されているからにほかならない。 "Tv!*"という文字列を使っているバイナリを探索することもできるけど、 0x5476212Aを使っているバイナリを見つける方法を検討するためにはもう少し時間が必要らしい。 ちなみにソニーrootkitは以下のコードを使っている。(関連行のみ抜粋)


     .text:100883B8   mov   cl, byte ptr ds:xxxxx+4 ; 0
     .text:100883C2   mov   eax, dword ptr ds:xxxxx ; "Tv!*"
     .text:100883C8   mov   [esp+70h+yyyyy], eax
     .text:100883DC   mov   [esp+7Ch+zzzzz], cl

xxxxx+4を使っているということは即ち、 ECDPlayerControl.ocxが機密保持用途の32bit整数ではなく単なる文字列を使っているということなのだが、 その割には当該文字列の5文字目(NULL文字)が決して使われない現実に注意を払っていないのだ。

別の例を挙げよう。このコミットで、私はDoExtShuffle()関数を再構築し、 FourthPass()関数とFifthPass()関数をマージし、スタックに割り当てられる構造体をひとつ破棄した。 ここで重要なのは、以下に示すDoExtShuffle()関数が主にC言語関数のサイズを削減すべく、 込み入った判断の繰り返しを経て作られたという事実だ。


 static void DoExtShuffle( uint32_t * p_bordel )
 {
     uint32_t i_ret;
     i_ret = FirstPass( p_bordel );
     SecondPass( p_bordel, i_ret );
     ThirdPass( p_bordel );
     FourthPass( p_bordel );
 }

i_ret変数は再利用されず、p_bordel配列中にマージされていてもおかしくなく、 また、SecondPass()関数はFirstPass()関数内に入っているケースも考えられる。 何をどうしたらこうした実装になるのかということに注目してもらいたい。 このやりかたは紛れもなくコードが進化してゆく過程で遺されてきたものなのだ。 そしてこれに相当するソニーのコードを以下に示すが、まさに完全な一致を見せている。


     .text:10089F3C xxxxx:
     .text:10089F3C   mov   ecx, esi
     .text:10089F3E   call  yyyyy
     .text:10089F43   push  eax
     .text:10089F44   mov   eax, esi
     .text:10089F46   call  zzzzz
     .text:10089F4B   add   esp, 4
     .text:10089F4E   call  ttttt
     .text:10089F53   call  uuuuu

ソニーのコードをしばらく眺めていると、当然の成り行きとしてこんな例が山ほど集まってしまった。 しかしそれだけにとどまらず、いくつかの新しい発見もしている。

問題のDRMSコードはどこから来たものなのか?

問題コードのもとをたどれば疑いなくVLCに行き着くわけだが、 どうも長い旅路を経ているようなのだ。VLCの別部分が問題のrootkitに含まれていない以上、 VLCから直接伝来したとは考えづらい。とはいえ、ソニーのコードにはFAACの一部が存在しており、 FAACはVLC由来のdrms.cを含んでいて、現在もなおFAAC CVSにあるdrms.cのバージョンは怖いくらい昔の物なのだ。

Sebastian Porstもソニーのコードと現バージョンのVLC中に含まれるdrms.cとの間にあるいくつかの明らかな相違点に注目していた。 それが最も明確に現れているのは以下のコードだ。


     if( p_shuffle->i_version == 0x01000300 )
     {
         DoExtShuffle( p_bordel );
     }

そしてこれは以下のようなアセンブリコードとなった。


     .text:10089F2E   cmp   eax, 1000300h
     .text:10089F33   jz    short DoExtShuffle
     .text:10089F35   cmp   eax, 1000400h
     .text:10089F3A   jnz   short skip
     .text:10089F3C DoExtShuffle:
     .text:10089F3C   ...
     .text:10089F58 skip:
     .text:10089F58   ...

0x01000400は4G iPodのファームウェアバージョンをチェックするためのものだ。 ついでに、少なくとも40KBにおよぶ新たなルックアップテーブルを発見した。 おそらくはさらなるバッファ・シャッフリングに利用されるものなのだろう。 当初私はこれが単なるF4IのDRM実装についての問題だと考えていたが、 これらのシャッフリング・コールは我々のDRMSコード、まさにdrms.cの一部に由来するiPodハードウェア情報検索コードの中にわざわざ隠れ住んでいる。

ソニーはDRMSv3スクランブル解除ソフトを頒布しているのか?

私の考えつく限り唯一の説明は、誰かがVLCのコードを盗むとしたら、 その動機は来たるAppleのDRMSフォーマットバージョンをサポートし、 VLCの開発者陣に知られぬところでソフトウェアを再配布することで、 それは十中八九GPLを侵害するだろうということだ。 (こういう言い回しなのは、今のところ肝心のソフトウェアを見つけておらず、迂闊なことを言えないからだ)

それがGPLソフトウェアに基づいている以上、私にはすでにソニーにECDPlayerControl.ocxのソースコード開示を要求する権利を有していることになる。 そんなことより、このソフトウェアについてかなりの部分の著作権を所有している例の人がしらばっくれているので、 ひょっとするとこれは私が一躍時の人となるチャンスなのかもしれない。

けれどもさらにもう一度これをリバースエンジニアリングするのはそもそも難しい事じゃなかろう。 むしろ次世代のオープンソースiTunes Music Storeファイルプレイヤーがソニーによって提供されちゃったりしたら、 そっちのほうが素敵すぎるぞ!

Sam Hocevar

posted by 7mm MG at 13:25| Comment(0) | TrackBack(2) | 和訳 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。

この記事へのトラックバック

洋楽ファンのみなさん、SONYのコピー制限悪用が活動してます
Excerpt: 「SONYのコピー制限はウイルスと変わらない?」「SONYのコピー制限の追記」で説明しましたが、米国ソニー BMG社がコピー制限機能として使っているのは、悪質なウイルスと変わらない動きをする上にウイル..
Weblog: The Wind of Blessing
Tracked: 2005-12-02 21:17

第21回・よりわかりやすいrootkit的CCCDとMedia Maxの検証。
Excerpt: 最近トンとニュースも入ってこなくなってきたような感のある、SONYBMGのrootkit的CCCD、さらに隠べいしかない(苦笑)と勝手に思ってるMediaMaxネタ。 ここ、日本では、セキュリティに..
Weblog: ふっかつ!れしのお探しモノげっき
Tracked: 2005-12-04 11:22
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。