- - PR -
逆コンパイル対策について
| 投票結果総投票数：131 | |||
|---|---|---|---|
| 必ずするようにしている |  |
2票 | 1.53% |
| 高価なものだけしている | |
1票 | 0.76% |
| 全くしていない | |
128票 | 97.71% |
| |||
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-05-14 21:58
まず、blue200102さんが何を主張したいのか、わかりません。当初の私の理解は、「自分の思い通りではないことついてマイクロソフトに文句を言っている」です。
これは誤解だと思ったので、最初は関わりませんでした。が、2ページ目の投稿内容から、あながち誤解ではないのかもしれないと思い、3ページ目の投稿をしました。ここで私は、マイクロソフトに“要望”を送るコツを書いており、また、内容によっては私が代わって要望を送りますよと書いているのですが、それに添った投稿は、今のところ（5/13まで）無いと判断しています。 さて、この会議室の<strike>投稿</strike>投票機能を利用されているわけですが、今のところ、 ＊ 必ずするようにしている・・・ 1 ＊ 高価なものだけしている・・・ 0 ＊ 全くしていない・・・・・・・94 となっています。もしこの選択肢が、 ＊ 必ず行いたい ＊ 場合によっては行いたい ＊ 行う必要を感じない であれば、どこに票が集まったでしょう？ 上2つに集まったことによって、「これだけの要望がある。だから難読化できるようにして欲しい。」とすることはできるのです。 あるいは、新たにスレッドを起こして、「これだけの潜在的要求があるにもかかわらず、ツールが高価なためにできていない。だから追加してくれ。」とも言えます。 せっかく MSDN フォーラムでスレッドを作られているのですから、そこで続ければ良かったのではないかと思います。向こうであれば、どう理解されるかはともかく、マイクロソフト社内の人や、開発チームの人の目にもとまるでしょうから。しかし、こちらに投稿されている頻度から見ても、向こうは“放置している”ように思われます。 これらのことから、ただの文句であると判断します。ただの文句であれば、こういうところで行わず、自分のブログなど、プライベートなところでやって欲しいと思います。 難読化という行為について。 難読化という行為には、興味はあります。しかし、行うかどうかは、また別の話です。 単に変数名を a や b など、単純化するだけなら、Refactor とかでもできるので、まぁ、間違いはないでしょう。しかし、MSDN フォーラム<microsoft.com> で返答されているように、
こうなると、ちょっと別ですね。このように変更されたコードが、元のコードと同一の動作をすることの検証をしなければなりません。また、何らかの不具合があったときに、どうやって元のコードの場所を割り出すか、検討しなければなりません。 そういった検証の結果、変更されたロジックに元のロジックと同一性がないとわかったときに、どのような対応を行うか、事前に検討が必要でしょう。コーディングパターンを分類できるなら、検証しなければならない項目を減らせるでしょうが、そうでないなら、元のコードを変更する都度、同一性の検証が必要ではないでしょうか。 元の投稿は、そのような難読化することのデメリットについて、考慮されていないように思います。 『Writing Secure Code』<microsoft.com> という本に書いてあることですが、どんなアタッカーから守らなければならないかを明らかにすることが必要ではないでしょうか。この本の中では、確か、「スクリプト キディ」「興味本位のクラッカー」「プロのクラッカー」「スパイ」と分けていたと思います。スクリプト キディや興味本位のクラッカー相手であれば、Dotfuscator Community Edition で十分ではないでしょうか。しかし、スパイ相手であれば、最上位エディションでも難しいでしょう（アセンブリから解読をかけられれば）。 では、プロのクラッカーを想定しなければならない場合がどれくらいあるか。あるいは、本当にプロのクラッカーを相手にしなければならないのか。「本当に危惧しなければならない状況って、ほとんど無いんじゃない？」というのが、私の意見です。 # 少なくとも、「高価だからする」ではないはず。 つまり、私は2投稿目以降「ただの文句じゃもったいない。要望にまで昇華しましょう」というスタンスで書いています。したがって、「保護対象のソースや技術に市場価値があるか問うてはいない」ではなく、問うて欲しいのです。要望を出すには、そうしなければならない、あるいはそうしたいコードがどれくらいあるのかということが重要ですから。「保護対象のソースや技術に市場価値があるか問」わず、単に「難読化させたいか？」であれば、こと @IT の場合、「場合による」という回答が多数を占めるのではないでしょうか。 なぜ「要望まで昇華」かというと、この辺り。（あるいは、ただの文句と判断したか）
繰り返しますが、100% 正しくて尤もだとしても、本人だけが考える不満は、受け取られた後、考慮されることは少ないです。強調したように、本人だけがそう思っているというところが肝心です。なので、そう思っているのが本人だけではないということ、製品のユーザに対して多くの割合の人がそう思っていることを示すことが重要です。 たとえば、ユーザが50人しかいなくても、50人のユーザ全員が同じことを思っているなら、それは要望として強い力を持っています。しかし、たとえ1万人が要望したとしても、全ユーザが100万人いて、その他99万人のユーザが必要と感じないなら、要望としては強い力を持ちません。 この事例を要望とするには、 ＊ プロダクトにおけるどれくらいの割合で、どの程度のレベルの難読化が必要か ＊ 実現されたときに、全ユーザに対するどれくらいの割合のユーザが恩恵を受けるか 位は、要望する側が調べなければ（推測しなければ）なりません。 要望が通った例としては、Unit Test が挙げられるでしょう。VS2005 では、TS エディション以上のみ、Unit Test が付属していましたが、Orcas ではProfessional エディション以上に追加される予定です。この場合、要望を出した時点で統計的情報はありませんが、適切な場所に適切な形で、理由とともに要望を出したため、統計情報も集まり、実現につながったと言えるでしょう。 → もと http://blogs.wankuma.com/naka/archive/2004/11/29/6351.aspx → 結果 http://blogs.wankuma.com/naka/archive/2007/03/28/69285.aspx 逆に言うと、マイクロソフトも難読化は必要だと感じているが、おおかたの事例は Dotfuscator Comunity Edition で十分にまかなえると考えている、とも言えます。 守りたいものに対する利権と、$4,950 (￥595,039) という値段（dotfuscator）の天秤ということになるかと思います。難読化したソフトウェアが何本売れると見込んでおり、1本あたりの利益がいくらで、それらから得られる予定の利益に対して $4,950 という値段がどうかという見方をすれば、あるいは「安い」と感じるかもしれません。 [ メッセージ編集済み 編集者: Jitta 編集日時 2007-05-14 22:17 ] | ||||||||||||||||||||||||
|
投稿日時: 2007-05-16 06:30
最初の質問の、根本的なところだけど。。。
.NET アセンブリ（JIT コンパイル や ngen 前のコード）から、VB.NET, VB2005 や C#、あるいは COBOL.NET でも J# でも Ruby.NET でもなんでもいいや。そういう「高級言語」（？）へ逆コンパイルすることって、できるのですか？ ildasm の結果は、少なくとも上に挙げた言語じゃないよね？Portable Executable と比較すると、どちらかというと link 前のアセンブリって気がする。 _________________ | ||||||||||||||||||||||||
|
投稿日時: 2007-05-16 08:18
皆さん、ご投稿ありがとうございます。引き続き、活発なご投稿と議論を期待しております。
放置しているわけではないのですが、こちらの方が反響が大きかったので、やり取りを繰り返す内にこの様になってしまいました。 別に文句を言っている訳ではなく、「Reflector for .NET」で自分のプログラム（Dotfuscator Comunity Editionで難読化した）を逆コンパイルした時、あまりに、詳細に元のコードが再現されたので、その時の第一感想を書いただけです。私は、数行程度の感想は、ここで書いても良いのではないかと思っていますし、皆さんの感想も、大歓迎します。
難読化の同一性についてですが、「暗号化と違い、難読化とは不可逆性のものである」ですから、同一性の保障は、重要と考えています。要するに、難読化したら、ロジックが変わってしまうような事が起こる事を大変懸念しています。難読化後、計算ロジックが、微妙（端数の処理とか？）に変わってしまって、間違った結果値がそれらしく出でしまう事があれば、本末転倒です。 皆さんは、この件については、どの様にお考えになっているのでしょうか？
当たり前だけど、リスク判断というのは、大変難しい事だし、一番重要な事だと思います。例えば、社内機構の風通しが悪く、社内に不満や怒りが鬱積したような所では、社内融和にまず取り組むべきですし、そちらに、そのお金を投資した方がいいかもしれません。鬱積した社員がリスク要因になるかもしれないからです。不正アクセスで、流出する事も考えられるので、そちらに、そのお金を投資した方が良い場合もあるでしょう。確か、Windows2000のソースコード流出は、不正アクセスが原因だった筈です。 従って、Dotfuscator Comunity Editionで、どこまでソースコードを保護（てこずらせられるか）できるか、という議論になってくるのではないでしょうか？
ここに、「Reflector for .NET」という逆コンパイラを使った実証例が出でいます。 http://www.atmarkit.co.jp/fdotnet/tools/dotfuscator/dotfuscator_02.html [ メッセージ編集済み 編集者: blue200102 編集日時 2007-05-16 08:22 ] | ||||||||||||||||||||||||
|
投稿日時: 2007-05-16 09:41
文句や要望ではなく、ソースコード保護の重要性について、マイクロソフトの 方針を例示しているに過ぎないのでは？ | ||||||||||||||||||||||||
|
投稿日時: 2007-05-17 13:34
皆さん、ご投稿ありがとうございます。
受託開発で、お客さんに、ソースコードを納品したり逆コンパイルされた場合、私が懸念しているの事は、結局、お客さんが、当方に難しい所だけをやらせて、後は、安い価格の会社に開発を引き継がせる事です。 この様な事を法律や契約内容で、防ぐ事は出来るのでしょうか？ [ メッセージ編集済み 編集者: blue200102 編集日時 2007-05-17 13:54 ] | ||||||||||||||||||||||||
|
投稿日時: 2007-05-17 15:52
お客様の業界/業種、開発会社の提供サービスにもよるところはあるかもしれませんが、
私自身の感覚としては以下のように思いました。
私には杞憂に思えます。 ○まずソースコードを納品している場合。 受託した開発会社をA社としましょう。 ソースコードを納品する意図は、A社にしか開発できないような状態に しないためだと思います。これはお客様視点で見た場合、 品質が悪いなどの理由でA社への依頼を止めたければ止めることができます。 あるいはA社の不得手な分野に関しては他社に依頼することもできます。 これはA社にとって不利なことでしょうか？ お客様からすれば、A社に依頼してコストパフォーマンスが悪くなければ、 次もA社に依頼するでしょう。A社製ソースコードを改修したり、 機能追加したりするのは、間違いなくA社が一番低コストで行えるはずですから。 お客様とA社が良好な信頼関係を築くことができていれば、 そんなに簡単に別の会社には乗り換えたりしないと思います。 継続的に取引のあるA社に発注することのお客様のメリットとしては、 ・新しい案件でも打合せもスムーズに行く ・(プログラム、ドキュメント、納期を守るなど総合的な)サービスの品質が 発注前からある程度確保できる などが挙げられると思います。 A社が一定の水準でお客様の期待に応えている限り、これらのアドバンテージのため、 他社に仕事を持っていかれることはないと思います。 理想論かもしれませんが、このアドバンテージは発注金額が高い安いという理由だけで 揺らぐものではないと思います。（最終的には金額だけでなくサービスの品質との トータルで判断されるものだと思います。) ソースコードが手に入ったことで、A社への発注を止める/減らすなどしたとしても、 それはソースコードが手に入ったことが主要因ではなく、 その前からA社に不満を持っていたということじゃないでしょうか。 ○逆コンパイルまでする場合。 一般に、すべてのソースコードを見ることができる場合でも、 製作者以外がそれらを全体通して解析するのは非常にコストがかかりますよね。 まして難読化されたプログラムを逆コンパイルして そのソースを解析するには途方もないのコストがかかると思います。 (簡易的な難読化でも) それほどのコストをかけるとしたら理由は何でしょうか？ ・A社の提供しているサービス品質に不満がある （提供しているサービスに対して価格が高すぎるとか、プログラムの品質がよくないとか)、 ・そうでなければ、サービスの価値など無視してとにかくコストを抑えたい アコギなお客様である のどちらかじゃないでしょうか？
ソースコードを納品しないで、リバースエンジニアリングの禁止を契約条項 に入れるという既に挙がっている対策では不十分なのでしょうか？ ＃法律に詳しくないですが、他社に発注するなとかいうのはたぶん無効でしょう。 | ||||||||||||||||||||||||
|
投稿日時: 2007-05-17 21:54
だったら、2007-05-14 21:58 の引用内で太字強調している部分は不要でしょ？そこがあるから「文句と判断した」と書いているでしょ？ ところで、よくわからないのですが、blue200102さんの投稿のどこに、「マイクロソフトの方針（が）例示して（ある）」のでしょう？ ここ、３通りに意味が取れます。 １．「ソースコード保護は重要だ。マイクロソフトはそのことを理解し、方針を打ち出している。この辺がその例だ。」 ２．「ソースコード保護は重要だ。しかし、現在のマイクロソフトの方針では、重要視されていない。だから、こうするべきだという例を示した。」 ３．「ソースコード保護は重要だ。しかし、マイクロソフトはそのことを理解していない。理解していない例は、この通りだ。」 １なら議題にする必要を感じません。２なら要望ではないでしょうか。３なら文句ではないでしょうか。 まとめてしまいます。
dotfuscator のヘルプ ファイルに、こういう場合はダメ、という例があります。 リスクつながりでいけば、やはり先行技術、類似技術がないか調べることも重要でしょう。私もつい最近、ある提案をしたら「特許登録する？」と言われました。調べてみると、すでに登録されていました。しかし、つぶせるだけの先行技術ネタはつかんでいるつもり。 それと、難読化よりもネイティブ コンパイルしてしまった方が早いと思ったので、検索してみた。 （キーワードは「msil native compile」）
もひとつまとめます。
契約で防ぎます。どちらも（委託者も受託者も）再利用できるが、他方の了解がなければならない、と。 そういう契約で納めたコードは、お客さん自身にコードを変更する能力があっても、契約上、できません。（そのため、「メーカーさんもオープンソースにしなさいよ」と、言われたことがある） もちろん、「今話題になっている、国営遊園地でミッキーマウスを平気でパクっているような国」とかを持ち出されると、どうしようもありませんけど。 受託者が勝手に使えないのは不便ですか？でも、依頼がなければ思いつかないはずですから、委託者によって縛られます。 （一人勝ちしようとするから、リスクも大きくなるのではないか、と） _________________ | ||||||||||||||||||||||||
|
投稿日時: 2007-05-18 00:30
ソフトウェアの保護は、先行している音楽・映像業界からして見て、知的財産権の法整備と法律を具現化する技術の２本立てが必須でしょう。さらにソフトウェアシステムは、サービスの提供方法が多用しているため契約制度（取引方式）をあわせた３本柱で対応しなければ片手落の話になると僕は考えます。 つまりソフトウェアは、法律、契約（取引方式）、技術の３つで保護する必要があると考えます。 この話はシステム開発の視点ではなく、音楽・映像業界に見るソフトウェア保護の延長線上で考えた方が議論としては面白く実務的に即した有益な情報が得られると思います。 | ||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。