新着記事

2005年12月03日

EULAを拒否しようとも、MediaMaxは迷惑なソフトをインストールし永久に実行し続ける

MediaMax Permanently Installs and Runs Unwanted Software, Even If User Declines EULAより。

EULAを拒否しようとも、MediaMaxは迷惑なソフトをインストールし永久に実行し続ける

2005/11/28(月) J. Alex Halderman

以前の投稿でMediaMaxがどういうことをするか述べた。 MediaMaxはソニーBMGその他のレコードレーベルにより音楽CDのDRMシステムとして採用されていて、スパイウェアのように振る舞うものである。 (MediaMaxは、ソニーBMGが先日リコールしたXCP技術とはまた別のものであり、ソニーBMGは未だにMediaMax採用ディスクを出荷し続けている) プロテクトCDを再生するとすぐ、MediaMaxは本拠地に通報し、エンドユーザ使用許諾契約を表示するまさにその直前に、 12MBを超えるソフトウェアをインストールする。そしてその中にアンインストーラは含まれていないのだ。

MediaMaxがインストールするソフトウェアの一部を例として挙げると、 プロテクトCDからのリッピングおよびコピーを妨害するためのドライバなどである。 ユーザが使用許諾契約に承諾していないというのに、まさかコンピュータの起動後すぐに、 MediaMaxがこのドライバを本気で恒久的に稼働させるものとは思ってもみなかった。 今にしてみると、そんな信用はそもそも大間違いで、事態は私が考えていたよりさらに深刻だったのである。

MediaMaxに関する先の記事へのコメントとして、読者であるfree980211の指摘が寄せられた。 問題のドライバは、たとえユーザがEULAに承諾したことがなかろうと、 同じプロテクトCDを2回以上使用した場合、恒久的な活動状態になってしまうことがたまにあるというコメントである。 初期の私の検証においてこの事実は解明されなかったが、それは図らずも問題の特性を厳重に抑制してしまっていたゆえらしい。 私はそれぞれの試験を、Windowsインストール直後の環境で、入念に立案しておいた特定動作についてのみ行っていたのだ。 追試験を行ったところ、MediaMaxが恒久的な活動状態になることをいくつもの環境で確認することができた。 しかも、はっきりと承諾しない旨を示した事実を無視してである。

この現象がどのタイミングで起こるかは、使用されているMediaMaxのバージョンに依存する。 CD-3と呼ばれる、2003年に取り入れられ、 今夏リリースされたアルバムまで採用され続けていた比較的古いバージョンがひとつ。 1年以上にわたりしばらくの間出荷され続けているMediaMax MM-5と呼ばれるバージョンがひとつである。 CDのルートディレクトリを調べることで、どちらのバージョンなのかを見分けることが可能だ。 MediaMax CD-3でプロテクトされたアルバムはLAUNCHCD.EXE、 一方MediaMax MM-5を採用したアルバムはPlayDisc.exeという名前のファイルを含んでいる。

どちらのバージョンのMediaMaxを採用したCDを挿入しても、インストーラプログラムは自動的に作動する。 (あらかじめWindowsのオートラン機能を切っておけばその限りではない) このインストーラはコピープロテクトドライバおよびその他のファイルをハードディスクに置き、 それからあなたが許諾するか拒否するかを尋ねる使用許諾契約を表示する。 使用許諾契約を常に拒否し続けたとしても、以下の手順を踏めば、問題のドライバは半永久的に稼働し続けることになる。

  • CD-3採用アルバムを挿入し、後日MM-5採用アルバムを挿入する
  • MM-5採用アルバムを挿入し、後日CD-3採用アルバムを挿入する
  • MM-5採用アルバムを挿入し、再起動後MM-5採用アルバムを挿入する。 なお、挿入するアルバムが同一であるか否かは問わない。

これらの現象は突然と言うよりむしろ、数週間、数ヶ月にわたって段階的に発生するものと言えるだろう。

コンピュータで音楽CDを再生することを好む諸兄にとり、これは悪い知らせである。 多くのユーザにとって、CDがMediaMaxを含んでいることに初めて気づくのは画面に使用許諾契約が現れる瞬間だが、 それでは時すでに遅し。恒久的な稼働状態に入ったドライバを停止させることなどもはやできないわけだ。 たとえユーザがご丁寧にEULAをその都度断り続けたとしても事態は好転せず、 どのみちこのソフトウェアは稼働し始めてしまう。要するに普通のやりかたをするかぎり事実上不可避なのである。

これは音楽ファンにとって悩みの種になるだろう。ドライバをなんとかして無効化しない限り、 MediaMaxプロテクト採用タイトルを再生するたびに厄介ごとをかかえこむことになるからだ。 iPodへのコピーについてはもはや言うまでもあるまい。 それはさておいて、例によってセキュリティリスクをも抱え込むことになる。 問題のドライバはWindowsカーネルの一部としてロードされ、 事実上コンピュータのあらゆる動作をあらゆる側面から制御する能力を有することとなる。 MediaMaxドライバがよりいっそうの被害をもたらす脆弱性をはらんでいるかどうかについては分からないが、 このインストール手法そのものが物騒な足がかりを作り出していることだけは間違いない。

こんな挙動は非合法じゃないかって?ごもっとも。 ユーザが明確に許諾を断り続けても、問答無用でシステムレベルのソフトウェアをインストールし、 深刻なセキュリティ上の懸念を引き起こすのだから、どう見ても不法行為である。

posted by 7mm MG at 22:32| Comment(2) | TrackBack(2) | 和訳 | このブログの読者になる | 更新情報をチェックする

最新ソニーBMG DRM目撃ガイド

Updated Sony BMG DRM Spotter's Guideより。

最新ソニーBMG DRM目撃ガイド

2005/12/02

野生のソニーBMG DRMを見つけるのは本当に難しいことなんだ。 多くの人々が発見方法を統一しようとしているのを尻目に、 問題のSunnComm MediaMaxソフトウェアは、遙か遠い範囲にまで広がる兆しを見せている。 表側に目立つステッカーが貼ってあるのに比べれば見劣りするが、裏側に小さな活字で書いてあるというのに。

アマチュアDRM探索家に助太刀すべく、我々は多種多様な手法を描き出す上映会(QuickTimeムービー)を企画した。 SunnComm MediaMaxソフトウェアのCDにおける変化に富む標示を寄せ集めた写真も並べておく。

SunnCommサポートサイト(「The CD in Question.」というプルダウンメニューを参照)にリストされた250タイトル以上を材料として、 以下のCDがソニーBMG(あるいはそのサブレーベル)によってリリースされ、パッケージにSunnComm MediaMaxの乗っている旨が標記されていることを確認した。

  1. Alicia Keys, Unplugged (Standard)
  2. Angie Stone, Stone Love
  3. Babyface, Grown & Sexy
  4. Backstreet Boys, Never Gone
  5. Black Rebel Motorcycle Club, Howl
  6. Charlie Wilson, Charlie Last Name Wilson
  7. Dave Matthews Band, Stand Up
  8. David Gray, Life in Slow Motion
  9. Eve 6, It's All in Your Head
  10. Imogen Heap, Speak for Yourself
  11. J-Kwon, Hood Hop
  12. Jim Brickman, Grace
  13. Kasabian, Kasabian
  14. Kings of Leon, Aha Shake Heartbreak
  15. Maroon 5, Live Friday the 13th
  16. My Morning Jacket, Z
  17. Pink, Try This
  18. Santana, All That I Am
  19. Sarah McLachlin, Bloom Remix
  20. Silvertide, Show and Tell
  21. Soundtrack, XXX: State of the Union
  22. Stellastar, Harmonies for the Haunted
  23. Velvet Revolver, Contraband

もっとあると考えてもらって差し支えない。MediaMax感染および感染のおそれがあるCDリスト完全版を参照してほしい。

Kurt Opsahl 02:39 PM

posted by 7mm MG at 22:13| Comment(0) | TrackBack(1) | 和訳 | このブログの読者になる | 更新情報をチェックする

MuzzyによるソニーXCP DRM問題についての暴言と愚痴

Muzzy's rant and whine about Sony's XCP DRMより。

MuzzyによるソニーXCP DRM問題についての暴言と愚痴

このページは僕の検証ページとは別のものである。 意見と事実は別のページにしておくのが賢明と考えたからだ。 このページは完全に意見のみで埋め尽くされている。 もし検証ページ にほんの少しでもバイアスのかかった内容があると思ったら、 メールしてくれればできるかぎりバランスを見直すつもりだ。 検証ページにはソニーXCP DRMシステムの簡潔なまとめ およびその問題についての記事もある。

本当のところはどうなのか?

メディアはどこもかしこもコピープロテクトの仕組みについて消極的な注意喚起を嫌というほど行ってきた。 しかし、rootkitそのものがもたらす真の問題は、消費者がコンピュータシステムの支配権を維持する能力を喪失することである。 セキュリティ企業各社は通常、ウィルス作者やその手の集団が勝手にコンピュータシステムの支配権を奪取すれば速やかに対処するのに、 大企業がまるで同じことをしたところさっぱり反応しない。 これは、既得権益を持つこのような多国籍企業がある種の消費者権利侵害を遂行した場合、 何かをできる立場にある全ての人が沈思せざるを得なくなることを表しているように思われる。 そして明らかに、真に迫った結論はどこにも出ていない。 一般人では、大声で悲鳴をあげたくとも、自身の利益を損ない得る正真正銘のセキュリティ問題に直面していようとも、 ソニーBMGの行いが合法的な範囲に収まるものなのかどうか、遺憾の意を表することしかできはしないのだ。

US-CERTは反応を示したが、 それは実際に起こったセキュリティ問題、例えばアンインストーラの脆弱性についてのものに過ぎない。 US-CERTはこのタイプのrootkitのインストールを阻止する手段について一般論的なアドバイスも行った。 しかしながら、ごく慎重に言葉を選び、rootkitそのものについての姿勢を示そうとせず、 この場合には的はずれのアドバイスを行っただけだったのだ。 例を挙げれば、「EULAを読みなさい」。 これはほとんど何の解決にもなるまい。 問題のEULAは当該ソフトウェアがアンインストール不能なことも、 他のあらゆる深刻な機能を持つことについても教えてはくれないからだ。 ブッシュ大統領の行政機関は、ソニーBMGに対して多少の警告を発した。 「あなたの知的財産ではあるが、あなたのコンピュータではない」という発言である。 だがこの発言でも事件の全体からは目を背けているどころか、 あたかも問題のすべてが昨今珍しくもない単なるセキュリティ欠陥であるかのように感じさせ、 宣伝広告上の被害にとどまるだけのものであるかのよう変節するものとさえ思えてくる。 以上の発言を受けてさえ、大企業が、気づきもしない無辜の消費者のコンピュータをハイジャックすることが、 果たして本当に許されるものであろうかという問題に、誰一人本気で取り組もうとしないのだ。 中小企業が同じことをやったなら、すぐにでも重大な紛争に巻き込まれてしまうことだろうに。

これは危険な状況である。この事態が放置され続ければ、 rootkitのインストールは慣例上ほぼ許されることになるからだ。 目下注目されている問題と言えば、XCP DRMのプログラムが欠陥品であることから生じる、 実際的なセキュリティ問題だけである。 このままでは、将来的にはユーザによってコンピュータの行動を支配することはもはやできず、 大企業が代わりにその行動を決定することになりかねない。 このことはすなわち、技術的な尺度で言えば、法を盾にする多国籍企業によって、 法運用を書き換えてしまうことが事実上可能であることをも示しているのである。 著作権法は著作物についての問題の有無を規定する法であったはずなのに、 もはやメディア企業が独裁を行うための手段となりはてたかのようだ。

責任問題

この事件についての全責任はソフトウェアを開発したFirst 4 Internetに押しつけられつつある。 先と同様、「音楽CDにrootkitが抱き合わせ販売された事実」という真の問題に取り組む人をなくしている理由のひとつと言える。 F4Iのプロテクトシステムにまつわる セキュリティ問題で思考停止している論者が多いが、それはどう考えても意図的なものだ。 関心をF4Iへ惹きつける動機も手段もあまりに単純である。 なにしろF4Iはあからさまに間抜けで未熟であるゆえ、 悪意を持って事を行ったようにすら見えづらいからだ。 著作権侵害問題は、この事件を興味深いものにしている争点とはわずかながらずれている。

第三者企業にDRM開発を委託したがために発生した問題のすべてについて、 ソニーBMGは回避することが可能だったのだろうか? これについてはおそらく、将来悪事が露呈したときにそなえてちょっとした悪巧みをする慣例があったのだろう。 要するに、問題が生じた際すべての不正行為は小会社によってなされたことであると押しつけ、倒産させ消滅させる。 そして、次の小会社にお鉢を回すのだ。 こんな理屈からだけでも、当局はソニーBMGとFirst 4 Internetとの関係を捜査せねばなるまい。 ソニーの主張によれば、F4Iは完全な第三者で、 ソニーはただF4Iの作ったプロテクトシステムを購入しただけだという。 F4Iがソニーからの特注品を開発し、 それが何をし続けるものか、飽くほどにソニーが知っていた証拠があろうともだ。 ソニーはまず間違いなく、rootkit機能の存在と、それが何をするものであるかを知っていて、 消費者のコンピュータを改ざんし、挙動を変え、支配権を奪い取るものであることまでをも確実に分かっていたはずだ。 そしてソニーは紛れもなく、問題のソフトウェアが除去できないことを顧客に黙っておくことを積極的に選択し、 おまけに問題のソフトウェアが本拠地に通報するような代物であることすら知らせ忘れたのだ。

加えて、著作権侵害に関して、昨今では訴訟事件の噂を聞くことも珍しくなくなった。 メディア企業が音楽や映画をダウンロードさせている「親」を訴えるというやつだ。 同じことが、ルームメイトに責任があれば、インターネット接続の提供者が訴えられるケースにも言える。 けれどもソニーは、自らの行為は連中とは違うと考えたらしい。 オープンソースソフトウェアを基盤にした違法コピーを頒布することが犯罪であると熟知しているにも関わらずだ。 はたして両者にどれほどの違いがあろうか? どのような理屈で責任を逃れられるはずだと考えたのだろう?

以下はArs Technicaフォーラムから Gilgamesh氏の投稿を引用したものである。 この記事は、ソニーBMGが著作権侵害についても責任を免れ得ない理由を法的観点から鮮やかに描き出している。 おそらく、法律家により入念に検討され書き込まれたものに違いあるまい。

First 4 InternetがソニーBMGのDRM(問題のrootkit)を開発した法的責任を負うとすれば、 その結果、彼らは生じ得たあらゆる侵害行為について第一の法的責任を負う。 たとえソニーが当該ソフトウェアの開発に一切関与していなかった場合でも、 ソニーはその頒布についての法的責任を負い、 さらにGroksterに関する新たな判例のもとにおいては、 侵害行為を誘発したものとして、最大では潜在的な第三者責任にまで広がることとなる。 MGM Studios Inc. v. Grokster, Ltd., 125 S. Ct. 2764 (2005);および、 「Karen M. Kramer, Metro-Goldwyn-Mayer Studios v. Grokster.The Supreme Court.s Balancing Act Between the Risks of Third-Party Liability for Copyright Infringement and Rewards of Innovation, 22 Santa Clara Computer & High Tech. L. J. 169 (2005)」を参照のこと。 Groksterに対する連邦最高裁判所の判決 によれば、「第三者の法的責任は侵害行為誘発の理論を経て見出され、 さらには明瞭な表現を以て示し、もしくは他の積極的な手段を侵害行為の助長のため提供したものとして...」とある。 もしこのGroksterに関する新判例 がソニーに法的責任を分与するために使われたとしたら、 事態の皮肉さは速やかに叙事詩的と言えるほどの水準に達するであろう。

また一方、実際に責任の争点となるのは、 ソニーBMGが現に自らの所有物ではないコンピュータシステムの支配権を奪ったことである。 ソニーはそれを故意に、何を行うものであるか知り尽くした上で行ったのだ。 遺憾ながら、セキュリティ企業各社はこの問題に取り組むことを恐れているようである。 ビジネス上、大企業を敵にまわすのは得策でないからだ。 今起こっているのは、セキュリティ企業各社が自身のセキュリティを守ることだけに躍起になり、 顧客のセキュリティをないがしろにしているということである。 大きな問題はDMCA、 欧州で言えばEUCDのような法にある。 コピープロテクトシステムがいかに悪質であるかを問わず、その回避を違法と定めるものだからだ。 これらの法は、コピープロテクトシステムが何を行うことを許容するのか、その定義について配慮されていない。 だが今日まで誰一人として、おそらくはDMCA 関連訴訟に挑むことを恐れて、この問題に触れようとしなかったため、 これらの「プロテクト」システム開発者は何をしても責任を免れることとなってきた。 しかし、たとえDRMの行いが合法か否かを法が定めずとも、 問題のDRMシステムは一目瞭然のまさに非合法な行為を行っているがために、 DRMシステム全般の採用を停止させかねないほどの強力な萎縮的効果をもたらしつつある。 まとめると、正当化され得ない2つの間違いがあり、それは以下のような明確な理屈となるということだ。 たとえDRMシステムがその行為において明らかに非合法であったとしても、 非合法な行為を実行するという理由からDRMを停止させることはそれでもなお許されないということである。

この種のDRMシステムは非合法であると宣言され、 セキュリティ企業各社が顧客の安全を守ることを阻止するような複数の法は打倒されるべきである。 メディア企業には、ビジネス上このようなDRMが必要なのだと不平不満をこぼす悪癖があるが、 そんなものはメディア企業が企図している新たなビジネスモデルにのみ適用されるべきだ。 顧客からまず権利を剥奪しておいて、それを売り戻すというようなビジネスモデルに。 昔々、企業は人々が所有したいと望むものを売ったものであったけれども、 今どきの企業は何か流行するものを見つけては、その独占販売権を主張するのが唯一の趣味らしい。 ときにあなたの人権はおいくらですか?

ソニーとFirst 4 Internetとの絆

僕の暴言の最初のほうで悪巧みの基本構想について述べたが、 それは小会社が不正行為を行うのに利用され、一切の憂慮なく倒産して消え去るというものだった。 僕がソニーとF4Iとの結びつきについて詳細な調査を呼びかけたところ、 Markのrootkitに関する投稿原文を読むよう指摘する一通のメールが届いた。 へえ、Michael Tandyという人が、ちょっとした探偵業をして、First 4 Internetに関わる公記録を洗い出したんだ。

えっ?First 4 Internet?どれどれ公記録によると、1999/11/24に法人格を取得。 2004年には売上高が709,941ポンド、営業経費が1,301,546ポンド、つまり営業損失が591,605ポンド。 過去5年間、年平均541,067ポンドの損失を出している。 2004年時点の信用格付けは「HIGH RISK(complete with capitalization)」、 一方で、4人の役員が年次報酬の224,413ポンドを1人平均56,103ポンドで山分けしている。
役員の一人、Nicholas Bingham(2002年に任命)は、 1989年から1997年まで"Sony pictures home entertainment Ltd."の役員で、 1996年から2000年まで"Sony pictures television production UK Ltd."の役員、 さらに1994年から2000年まで"Sony digital radio europe Ltd."の役員だった。
ソニーは皮肉にも、取り巻き連中の一人が提供していたがために、 不適切なコピープロテクト技術を採用してしまったのか。 ソフトウェア事業の失敗理由によく見られる、悪い商慣習だね。

なるほど、何かが起こっていることだけは間違いない。 ソニーBMGは「HIGH RISK」な企業のサービスを利用することのみならず特注品を依頼することを決断し、 そしてその人々のうち一人がこんな事態を方向づけたわけだ。 演繹的でない逆推論が危険であるのは百も承知しているが、これはあまりにしっくりきすぎる。 僕はビジネスのことを充分に理解しているわけではないし、 ソニーBMGがいつその決定を下したのか知っているわけでもないが、 ソニーBMGがそんな選択をしたことを納得のいくよう説明する術は、とてもじゃないが他に考えつかない。 差し当たって僕はその仮説に同意しておいて、 おそらく問題のDRMが社内で開発されたもので、責任を引き受ける小会社を選んで身代わりにし、 消費者のシステムの支配権を奪取することにまつわる法的問題から逃避したものと思っておくことにする。

あなたならどう考える?

2005/11/19更新 Matti Nikki

posted by 7mm MG at 20:15| Comment(0) | TrackBack(3) | 和訳 | このブログの読者になる | 更新情報をチェックする

MuzzyによるソニーXCP DRMシステムのまとめ

Muzzy's summary of Sony's XCP DRM systemより。

MuzzyによるソニーXCP DRMシステムのまとめ

ソニーBMGが使っているコピープロテクトシステム「XCP」にまつわる問題を、 簡潔にまとめようと思い立った。 僕の検証ページにもいくつかの検証結果は載せてある。 だけどそれは詳細のみだから、全体像を把握するのには不適切だと考えたんだ。 このページでは詳細にはあえて踏み込まず、何が起こっているのかについてだけ述べようと思う。 もしこれら全ての問題についての僕の意見を知りたければ、 僕のページRant and Whineを読むといい。

MediaMaxに関する情報のまとめを読みたいなら、jiriの比較対照表を見るといい。 肥大化した僕のページよりよっぽど読みやすいよ。

JavaScriptをONにしておくと、ハイライトボタン機能が使える。(訳注:和訳では未実装)

主な機能

XCPはカジュアルコピー防止のために比較的高水準のプロテクトを提供しつつ、  正規ユーザにはお好きなプラットフォームで高音質のデジタル音楽を体験させるものです。
−www.xcp-aurora.com より
  • プロテクトCDはマルチセッションCDで、プロテクトされていない音楽トラックと、 コンピュータの音楽CD(プロテクトのない普通のCDを含む)読み込み能力を改ざんするための「悪意のあるソフトウェア」から成る。
  • コンピュータの支配権を奪取し、実行中のOSカーネルを一部改窮し、システムのリソース監視方法を改ざんする。
  • CDリッピングソフトの正常動作を妨害し、その行為は多分既知のリッピングソフトを載せたブラックリストに基づいている。
  • アプリケーションの実行を常に監視し、DRMシステムが興味を持つソフトの実行を見届けるために覗き窓を開いておく。 その動作は、プロテクトのない普通の音楽CDをドライブに入れているときでも変わることがない。
  • プロテクトCDを再生すると、ただちに本拠地に通報する。 その際、どのプロテクトCDがいつどこで再生されたのかについての情報をソニーに提供する。
  • $sys$で始まるファイルや実行中のプログラムをシステムから見えなくし、自身の存在をも隠蔽する。
  • プレイヤーアプリを提供するが、CD再生機能のほかに、もれなく個人的なコピーを3回に制限する機能を搭載。 もちろん、お気に入りの音楽再生ソフトウェアを使うことなど許されない。
  • DRMシステムが駄目と判断した場合、音楽CDをリッピングする際に問答無用でノイズを付加する。

問題

「ほとんどの人はrootkitとは何かを知らないのだから、気に掛けたりしないのではないか」
−ソニーBMGグローバルデジタルビジネス担当社長トーマス・ヘス [ソース]
  • 何が起こっているのかわからなければ、コンピュータの支配権を奪取されたとしてもユーザは気にしない、とソニーBMGが公言していること。 なお、ソニーは謝罪するつもりがないらしいばかりか、新たな試みをしようとしているようだ。
  • 問題CDのEULAが、 ソフトが本当のところ何をするのか説明していないばかりか、 そういった情報が購入に先立って消費者に一切公表されていないこと。
  • 問題ソフト自身にアンインストール機構がないこと。
  • ソフトが隠れているため、アップデートが必要かどうかの判断が難しいどころか、 インストールしてしまったユーザがそれを知ることすらまずないだろうということ。
  • ファイルやプロセスの隠蔽がセキュリティホールを作り出し、 それがすでに複数のコンピュータウィルスによって利用されていること。
  • XCPのプログラムが不出来で、たまに誰かのシステムをクラッシュさせること。
  • システムによっては、プレイヤーソフトが正しく動作しない場合があること。
  • アンインストーラがActiveXバックドアをインストールし、 悪意のある人々がコンピュータを制圧するために使える脆弱性を作り出してしまうこと。
  • 問題DRMシステムに含まれるコンポーネントの数々について、 XCP DRMシステムではなく、さもシステムにとって重要な機能であるかのようにユーザを欺くため、 故意に間違った命名がなされていること。
  • ほとんどの見え透いた素直な方法でXCPを除去しようと試みると、 次回起動時にすべてのCDドライブが無効になってしまい、以後コンピュータが障害を抱えたままになること。
  • 多くのDRMコンポーネントがオープンソースコードの著作権を侵害していること。 (GPLおよびLGPLソフトのライセンスを遵守していないこと)
  • DRMシステムがApple社のDRMシステムFair Playを回避する機構を含んでおり、DMCA違反が疑われること。
  • 提供されるアンインストーラがWebベースのみであるため、インターネット接続不能のシステムでは実行できないこと。
  • 複数の異なるコンピュータからアンインストールする場合、 1回アンインストールするごとにソニーBMGの許可を求めなければならないこと。
  • 十中八九、DMCAに基づく告発をおそれてDRMシステムをリバースエンジニアリングできないため、 ほとんどのセキュリティ企業が問題のDRMシステムを回避させることで顧客の安全確保をするより、 自らの安全確保を優先するであろうということ。
  • 問題のDRMが、ライセンスを承諾しないかぎり音楽を聴く権利がないかのような印象を与えるものであること。 (テクニカルな記述としては正しいのかもしれないが、たとえまったくプロテクトシステムの働かない環境でさえも、 音楽CDを携帯音楽プレイヤーにコピーすることさえも違法よばわりしているかのようだ。 また、そんな主張に耳を傾ける道理などないことを念頭に置いておこう。 そもそも「right to readも何もあったものではないのだから。)
  • 完全なCDリッピングを阻止すべくノイズ付加システムが実装されているものの、 プロテクトされていないCDに対して見事に働くわりには、 たまにプロテクトCDをノイズなしでリッピングできてしまうこと。
  • 実行中プロセスの監視および覗き窓を開くために、常にシステムリソースを消費し続けること。 それにより少なくとも1〜2%はシステムの演算能力を落とすこと。
  • 回収、交換プログラムを実施しているにもかかわらず、 ソニーBMGがそれを大々的に公表しようとする姿勢すら見せないこと。 その上、感染CDは未だに流通しており、今後数年にわたって幾百幾千のシステムに影響を与え続けるであろうということ。
  • どうやらソニーBMGが、引き起こした被害についての補償や問題CDの返金に応じそうにないこと。

その他の情報

  • CDを入れるときにShiftキーを押したままにするか、あらかじめオートランを切っておくことで、 システムにXCPがインストールされることを阻止できる。 これで、問題のDRMシステムをも回避することが可能。 ここで注意せねばならないのは、Windows2000以降では実質的にメディア交換通知がオフになっていて、 いくつかのアプリケーションがこの特性につけ込んでいることだ。 (そのようなシステムではオートランを切っておくのが望ましいのだろうけど、今のところOS単体でそれをする方法がわからない)
  • ソニーBMGは影響を受けるCDとしてWebサイトに52タイトルをリストしているが、 以前は影響を受けるのは20タイトル足らずだと主張していた。
  • XCPに感染したCDを持っているなら、 ソニーBMGの回収、交換プログラムを利用することで、 XCP FAQの言うところのXCPに感染していないCDへと交換してもらえる。 これはきっと、別のコピープロテクトが施されたCDをこっそりばらまくようなことはしないことを意味するに違いない。
  • ソニーBMGの立場に立って、XCP FAQを読んでみよう。 しかし、ほとんどただの宣伝ではないか、と悟ることになるはずだ。
  • 実のところ、こんな正規盤CDを買って使うくらいなら、インターネットから違法ダウンロードしたほうが安全だ。 ユーザが販売業者にきっぱりと「プロテクトのない違法コピー品はないか?」とたずねる新時代の到来なのかもしれない。 それでも販売業者が「本物」を売りつけようとやっきになる悪徳商法の時代のね。
  • CDをリッピングする人間が一人でもいれば(要はShiftキーを押して回避するだけだが)、 問題のDRMシステムはインターネット上の違法流通を阻止はおろか鈍化させることさえできない。
  • ソニーBMGは同時にSunnComm MediaMaxのコピープロテクトシステムも利用しているが、 これはある意味でXCPよりたちが悪い。EULAに同意しなくてもインストールされ、 アンインストーラはなく、本拠地への通報など色々なことをする。

何か間違っているだろうか?追加や訂正があれば、メールして欲しい。(訳注:くれぐれも英語で)

2005/11/24更新 Matti Nikki

posted by 7mm MG at 19:22| Comment(2) | TrackBack(2) | 和訳 | このブログの読者になる | 更新情報をチェックする

MuzzyによるソニーXCP DRMシステム調査報告

Muzzy's research about Sony's XCP DRM systemより。

MuzzyによるソニーXCP DRMシステム調査報告

ソニーのXCP DRM rootkitについて独自に調査した結果をいくらか集めてみた。 どうぞごゆっくり。 新情報を発見するたびにページを書き換えているから、後日また確認するといい。

簡潔なXCP DRMシステムのまとめと、 切り離してある意見のページもある。 このページは事実にこだわろうとするものなので、何かバイアスがかった表記や間違いがあると思ったら、 メールで知らせてくれると嬉しい。

最近の更新

アンインストーラ

このアンインストーラは、ちょうどユーザがアンインストーラのURLをリクエストできるようになる直前、 あるActiveXコントロールをシステムにインストールすることを命じる。 アンインストーラのActiveXは自身の安全を確保すべく注意を払って書かれているのだけれど、結局、 盛りだくさんの興味深いメソッドを、誰もが利用できるようにしてしまう性質を持ってしまっている。 これらについてはそれほど深く検証していないのだけど、とりあえずひとつだけ試してみたら、 そうなるだろうと思った通りに動いた。これはいわゆる「RebootMachine」というやつだ。 もしソニーのActiveXコントロールをインストールしたことがあるなら、 invoke the RebootMachine methodのリンクを踏んでみなよ。(訳注:危ないから踏むなよ) ともかく、ExecuteMethodメソッドのなんたるかは十分わかってもらえたと思う。

このInstallUpdateメソッドは、実はもっと大きなセキュリティホールを持ってるんだけど、それはfreedom-to-tinker.com's post about the uninstaller hole.を参照のこと。 彼らは、脆弱性があるかどうかを試すのに僕のリブート・デモが使われることで、事態が悪化するかもしれないと懸念している。 なぜならこれは、F4Iのサイトからhtmlをコピー&ペーストしたもので、 元々はActiveXコントロールのインストールを催促するのに使われていたからだ。 F4Iだっていつでもどんな方法でもインターフェイスを変更することはできたはずなのだけど。 僕のは変更しといたから、デモにインストール能力を持たせるような用途には役に立たないはずだよ。

アンインストーラが置き去りにしていくスクリプト・メソッドの数々

問題のアンインストーラは数々のメソッドを置き去りにしていく。これはそのリストだ。

  • GenerateRequestPacket
  • ExecuteCode (ブラクラに悪用できる。どうも最新のocxでは除去されているようだ。)
  • Uninstall
  • RebootMachine (デモを見ればわかるとおり、悪用される。)
  • GetProgress
  • OnLoaded
  • InitializeDiscScan
  • GetNumberOfDiscs
  • IsDRMServerValid
  • GetAlbumArtist
  • GetAlbumName
  • GetMaxBurnCount
  • GetCurrentBurnCount
  • GenerateIncrementPacket
  • IsContentOwnerValid
  • DoIncrement
  • GetInstalledSoftwareVersion
  • IsXCPDiscPresent
  • InstallUpdate (exploitable)
  • GetInstallProgress
  • GetCompletionStatus
  • IsXCPDiscPresentAsLong
  • IsAdministrator

これらを使えば誰でもコンピュータを再起動させられることを考えると、 これを開発している間、1秒たりともセキュリティについて考えたことがないのではとさえ思える。 ウィルス作者やその手の世界はこうしたメソッドを解析することにとても興味を持つことだろう。 これらのうちのいくつかは間接的に利用できるだろうから・・・意図的に。

マジックリスト

問題のインストーラとプレイヤーは両方とも、ある興味深いリストを含んでいる。 実行ファイル名、ウィンドウ名、などなどが載っているものだ。 現段階ではこれらが何に使われる物なのかはわからないが、およそブラックリストシステムであろうと推測できる。 あなたも同じような推測をすることだろうけど、だがしかし実は問題のDRMシステムは2秒毎にリストを読み取っているのだ。

これらのリストに載っているプロセスのAPIをフックして、DRMシステムがノイズ付加を行うと伝えてきたけど、 今のところまだ確証は得られていない。

LAMEとの関係は?

問題のCDにあるファイル「Contents\GO.EXE」が、とある文字列を含んでいるのだ。


00056c18  68 74 74 70 3a 2f 2f 77-77 77 2e 6d 70 33 64 65  http://www.mp3de
00056c28  76 2e 6f 72 67 2f 00 00-30 2e 39 30 00 00 00 00  v.org/..0.90....
00056c38  4c 41 4d 45 33 2e 39 35-20 00 00 00 33 2e 39 35  LAME3.95 ...3.95
00056c48  00 00 00 00 33 2e 39 35-20 00 00 00 00 00 00 00  ....3.95 .......

GO.EXEにLAMEがリンクされているのはうっかりミスのように見えるが、 少なくともECDPlayerControl.ocxにおいては完全に利用されており、どう見てもうっかりリンクされたものではない。 LAMEを検知するのに使ったのではないかと推測する人もいるかもしれないが、それは事実と異なる。 GO.EXEはこのデータとはどう見ても無関係、つまりそこでは全く使われていないということだ。 つまり、彼らは混乱してついうっかりインストーラに対してLAMEをリンクしてしまったのである。 本来LAMEが使われ必要とされるはずの、DRMシステムの別のコンポーネントにだけリンクされるべきところを。

問題のCDには、LAMEの文字列を含むファイルが全部で4つもあり(うち3つはXCP.DATに圧縮格納されている)、 その上少なくとも1つは、LAMEのコードをも含んでいるように見える。これは確実に著作権侵害である。 なお、Sebastian Porstのblog記事にもLAMEが問題のDRMとともに出荷されている旨の記載がある。

多くの人々が気づいていることだろうが、ソニーBMGもF4Iも MP3特許のライセンス供与を受けているようには見えない。LAMEのコードを盗用したことは特許権侵害をも引き起こすのである。 しかし昨今、まったくもってとんでもない量の特許があり、表に出ているソフトウェアのほとんどは何らかの意味でそれに囲まれていると考えられることには留意すべきである。 この件に限って言えば事の起こりからしてあまりに露骨すぎる。なにしろ既知の特許範囲にある既知のソフトウェアを含んでいるのだから。 また、ソニーBMGが少しでもリストアップの手を休めたなら、ソニーにも、そして少なくとも僕にも、 特許ライセンス供与というものが実際のところどう働き、誰がそれを求めるのかということの糸口すら見出すことはできやしないのだ。 特許事情に関わらないで何かを公表しようと企図するなら、己の中に真実を問うしかないと考えておいたほうがいい。

XCP.DATにある謎の物体

CDからXCP.DATを取り出して展開してみたところ、あまりに驚くべき代物が中に入っていることを発見してしまった。 その物体達を一見したところ、どうもmpglib.dll、とあるバージョンのbladeenc.dll、などなどのようだ。 両方ともLGPLで、僕の理解が及ぶところでは、これらについては付属文書にて言及しない限り利用してはならない。 (頒布も駄目なんだったかな?)

問題のCDにはAdaptecのASPIなブツも含まれているが、頒布の許可を取ってあるようには見えない。 まああれだ。この上何を調査したものかと途方に暮れてしまったよ。 とはいえこれらのファイルは最終的にシステムにインストールされ、とても目立つ場所(windows\system32\TMPX)に置かれるわけだから、 もしかすると、いくらF4Iでもそこまで露骨な侵害行為を行うほど馬鹿じゃないかもしれん。

この上Id3Libまである。それも極めて目立つ形式でだ。問題のCDに記載はないが、 ソニーは一方でOpenMG関連物と一緒に自社サイトでId3Libのソースを配布しているわけで、 問題のDRMがLGPL版を使っているのか、古いパブリックドメイン版を使っているのかは不明だ。

ECDPlayerControl.OCXファイルはこれらのLGPLライブラリを実際に使っていると考えられ、 付属文書にはライセンスも言及もないのだから、それはおそらくLGPLに従っていないことを意味し、 また、それ故に複数のオープンソースプロジェクトの著作権をも侵害していることになる。 これらのファイルを誰もが等しく確認できるように共有できたらいいなあと思うけれど、 それをやったらそれこそ著作権侵害になってしまうね。

ECDPlayerControl.ocx

LGPLおよびGPLコードの著作権を侵害し、DMCAおよび EUCDにおいて非合法となるもの。

まさに祭り進行中という感じだ。上で述べたLAMEのコード発見に加えて、 GPLなコードまでもが同じように出現してくる。僕は法律家ではないけれど、これはDMCAおよび EUCD違反でもあるんじゃないのか? 問題となっているコードはVLCのdemux/mp4/drms.c−ほかでもないApple社のDRMを回避するための対DRMSコードである。 制御フローは同一で定数はすべて等しく(どうやらひとつだけ例外があるらしいが)、2つのマジックナンバーで構成された配列も同様に一致。 p_secret2という文字列配列も含まれていて、それはrot13暗号化されたAppleの著作権表示文字列だったという(特定のアルゴリズムでデータとして使われているらしい)。

もしXCPをシステムで飼っているなら、system32ディレクトリにECDPlayerControl.ocxを見に行ける。 こいつの中身に"Nccyr"で検索をかけてみるといい。もし逆アセンブラを持っているなら、仮想アドレス0x10089E00にある関数を見て、 drms.cのDoShuffle()関数と比べてみよう。類似点に気づくはずだ。

この件について読んでおくべき記事を挙げるなら、Sebastian Porstのmpglib code found in ECDPlayerControl.ocxと、 それがVLCにおける彼自身の書いたコードに起源を持つものであることを確認した、Sam Hocevar's confirmationがおすすめかな。

First4Internetのocxファイルをダンプしたもの


00108018  aa aa aa aa 00 77 75 01-80 45 55 00 00 45 72 01  .....wu..EU..Er.
00108028  80 45 42 00 00 77 42 01-80 00 00 00 01 9d d5 c1  .EB..wB.........
00108038  81 49 14 80 01 89 5c 81-81 49 54 80 01 5d d4 81  .I....\..IT..]..
00108048  80 00 00 00 03 bb a3 81-82 aa a2 00 03 bb a3 01  ................
00108058  82 a2 22 00 02 a2 3b 81-80 00 00 00 37 57 57 6d  .."...;.....7WWm
00108068  a5 75 52 4a 25 57 52 6d-a5 54 52 4a 37 54 72 6b  .uRJ%WRm.TRJ7Trk
00108078  80 00 00 00 38 b9 dd d5-92 a0 55 54 13 a0 95 5d  ....8.....UT...]
00108088  92 a1 15 44 3a 39 dd c5-80 00 00 00 55 55 55 55  ...D:9......UUUU
00108098  70 62 63 6c 65 76 74 75-67 20 28 70 29 20 4e 63  pbclevtug (p) Nc
001080a8  63 79 72 20 50 62 7a 63-68 67 72 65 2c 20 56 61  cyr Pbzchgre, Va
001080b8  70 2e 20 20 4e 79 79 20-45 76 74 75 67 66 20 45  p.  Nyy Evtugf E
001080c8  72 66 72 65 69 72 71 2e-00 00 00 00 d4 ee 0a 10  rfreirq.........

VLC、drms.c、DoShuffle()関数より抜粋した変数宣言部

p_secret2文字列はAppleの著作権表示文字列をrot13アルゴリズムで暗号化したもので、 DRM処理の過程でデータとして使われている。 僕はこれを、Appleが法廷闘争を想定して埋め込んでおいたものではないかと想像している。 彼らがこのDRMシステムを作った明瞭な印だし、 これでプロテクトされた著作物をデコードしようとする人は誰でもその文字列を使わなければならないのだ。 そしてJonはrot13をプレーンテキスト形式にしてみせることなく処理していた。 もっとも、この文字列がたとえAppleによって作られたものであろうと、 これが存在することだけではAppleの著作権が侵害されているということの印にはなるまい。


    static uint32_t p_secret1[] =
    {
        0xAAAAAAAA, 0x01757700, 0x00554580, 0x01724500, 0x00424580,
        0x01427700, 0x00000080, 0xC1D59D01, 0x80144981, 0x815C8901,
        0x80544981, 0x81D45D01, 0x00000080, 0x81A3BB03, 0x00A2AA82,
        0x01A3BB03, 0x0022A282, 0x813BA202, 0x00000080, 0x6D575737,
        0x4A5275A5, 0x6D525725, 0x4A5254A5, 0x6B725437, 0x00000080,
        0xD5DDB938, 0x5455A092, 0x5D95A013, 0x4415A192, 0xC5DD393A,
        0x00000080, 0x55555555
    };

    static char p_secret2[] =
        "pbclevtug (p) Nccyr Pbzchgre, Vap.  Nyy Evtugf Erfreirq.";

ECDPlayerControl.ocxを逆アセンブルしたもの

最初の3つのswitch・case文は逆アセンブルしたものの外側にあるのに、ジャンプがあることに注目して欲しい。 defaultの場合も明白にコードが一致することを見て取れるだろう。


.text:10089E90  mov     eax, [edx]               ; p_commands[i]
.text:10089E92  test    eax, eax                 ; if zero,
.text:10089E94  jz      loc_10089F21             ;   continue loop
.text:10089E9A  mov     cl, al                   ; i_index
.text:10089E9C  shr     eax, 8                   ; source code ands first
.text:10089E9F  and     eax, 3                   ; same as (&0x300)>>8
.text:10089EA2  dec     eax
.text:10089EA3  jz      short loc_10089F03       ; case 1
.text:10089EA5  dec     eax
.text:10089EA6  jz      short loc_10089EE5       ; case 2
.text:10089EA8  dec     eax
.text:10089EA9  movzx   eax, cl
.text:10089EAC  jz      short loc_10089EC9       ; case 3
.text:10089EAE  mov     ecx, eax
.text:10089EB0  add     eax, eax
.text:10089EB2  mov     ebx, offset unk_100C5D46
.text:10089EB7  sub     ebx, eax
.text:10089EB9  movsx   eax, word ptr [ebx]
.text:10089EBC  shr     ecx, 4                   ; i_index>>4
.text:10089EBF  mov     ebx, [esi+ecx*4]
.text:10089EC2  lea     ecx, [esi+ecx*4]
.text:10089EC5  add     ebx, eax

drms.cから抜粋したコード


        if( !p_shuffle->p_commands[ i ] )
        {
            continue;
        }

        i_command = (p_shuffle->p_commands[ i ] & 0x300) >> 8;
        i_index = p_shuffle->p_commands[ i ] & 0xff;

        switch( i_command )
        {
        case 0x3:
            p_bordel[ i_index & 0xf ] = p_bordel[ i_index >> 4 ]
                                      + p_bordel[ ((i_index + 0x10) >> 4) & 0xf ];
            break;
        case 0x2:
            p_bordel[ i_index >> 4 ] ^= p_shuffle_xor[ 0xff - i_index ];
            break;
        case 0x1:
            p_bordel[ i_index >> 4 ] -= p_shuffle_sub[ 0xff - i_index ];
            break;
        default:
            p_bordel[ i_index >> 4 ] += p_shuffle_add[ 0xff - i_index ];
            break;
        }

DeDRMSがこんなところで何をしているのか?

目下憶測であるが、F4IはGPLコードを非合法に使うことにより、 開発をスピードアップさせたかったのだろうと想像している。 VLCについてもおそらくそうで、結果的に諸々の残存物とともにDeDRMSの欠片を持つ羽目になってしまったのだろう。 BinDiffで照合してみれば、VLCのlibmp4とXCPとの間にいくらか一致する部分はある。 とはいえ、合法的にコードを再利用していた別のやはりGPLなプロジェクトからコードを拾ってきた可能性も捨てきれない。 解析されたコードにおけるVLCとXCPとの間のごくわずかな相違点は、コードのバージョン違いか、 あるいは別のプロジェクトに由来することで説明できるのではあるまいか。 Sebastian Porstによる注釈付き逆アセンブルは、問題のソースとdrms.cとの同一性を如実に表している。 ただひとつの例外を除いてではあるが。

責任は誰にある?

これについて僕は度が過ぎるほどに激しい意見を持っているのだが、それを知りたいと思うなら隔離してあるページ、Rant and Whineを読んでくれるといい。

ソニーの主張するところでは、開発はF4Iによってなされ、 ただ単にソフトウェアのライセンスを受けただけだから自らは潔白だという。 けれどもECDPlayerControl.ocxが、デバッグにでも使われていたであろう興味深い文字列を含んでいる。 開発者のファイルシステム情報を浮き彫りにする文字列だ。 問題となっているプロジェクトの開発に使われたディレクトリ名は「XCP Player Code\Sony ActiveX Player\XCPPlayerControl\」。 これはソニーがF4Iに製品をあつらえるよう依頼したことを示唆している。 ことによると、完全な特注品ということすらあり得るだろう。 問題のDRMシステムがはらむ専門的性質につき、ソニーBMGにどれだけの理解があったかは不明だが、 明らかに知っていたであろうある主要な特性がある−消費者のシステム支配権を奪取する特性だ。 彼らはこれに関していくつもの訴訟に直面している。 もはや彼らが法を破ったのか否か、裁判所の判決を待つのみということだ。

2005/11/23更新 Matti Nikki

posted by 7mm MG at 18:46| Comment(0) | TrackBack(3) | 和訳 | このブログの読者になる | 更新情報をチェックする

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) | 和訳 | このブログの読者になる | 更新情報をチェックする

MediaMaxは一体何を成し遂げるのか?

What Does MediaMax Accomplish?より。

MediaMaxは一体何を成し遂げるのか?

2005/11/23(水) Ed Felten

ソニーの一部音楽CDに採用されているSunnComm MediaMaxのコピープロテクト技術を押しつけられることにより、 セキュリティリスクが発生することは昨日述べた。 (SunnComm MediaMaxのコピープロテクト技術は、ソニーがリコールしたXCP技術とはまた別のものなので混同しないよう注意) MediaMaxは効果的に音楽のコピーを防止するのだから、ユーザをそのようなセキュリティリスクにさらすことくらい仕方ないではないか、 とMediaMax支持者なら論じるかもしれない。 そういう反論からは、ある明確な問題が提起される。 MediaMaxはコピーを阻止する上で実のところどれほど効果的なのか?という問題である。

答え:さっぱりだ。

報道によれば、MediaMaxはある著名なトリックによって無効化される。 CDの外縁付近にサインペンで円を描くか、外縁部を粘着テープで覆うだけで作業完了とのことだ。

MediaMaxはCDを挿入する際Shiftキーを押しっぱなしにするというなじみ深いトリックで無効化される。

MediaMaxはCD挿入後コンピュータを再起動するというありがちなトリックで無効化される。

(最初に挙げたこれら3つの攻撃方法は、MediaMaxがすでにインストールされている場合、全く効果がない。 だが、MediaMaxは誰もが利用できるアンインストーラを公開している。)

MediaMaxはWindows PCを使わないという有名なトリックによって無効化される。 (面白いことに、MacユーザはMediaMaxを必要に応じてインストールする権利を与えられている。 インストールするには、CDの中身を見渡して、MediaMaxインストーラのアイコンをダブルクリックしなければならない。 これでは「クリックすればこのCDをより不便にご利用いただけます。」とでも書いてあるようなもので、 まあまあ賢明なユーザであればそんなことはせず、普段通りに音楽を再生することだろう。)

MediaMaxはiTunesやiPodに曲を移動したい旨をソニーに伝えることで無効化できる。 ソニーは、プロテクトのないコピーCDを作成することによりMediaMaxを無効化する方法を指南してくれることであろう。

これで全部だが、MediaMax技術がどういう働きをするもので、その働きにいかなる不具合があるかということについては、 そういえば詳しいことを話し始めてすらいなかった。

結論:MediaMaxとはコンピュータの安全性を低下させ、音楽の合法利用を妨害し、そのくせ海賊行為に対してなし得ることはごくわずかという代物である。

posted by 7mm MG at 03:17| Comment(0) | TrackBack(1) | 和訳 | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

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