- - PR -
逆コンパイル対策について
| 投票結果総投票数：131 | |||
|---|---|---|---|
| 必ずするようにしている |  |
2票 | 1.53% |
| 高価なものだけしている | |
1票 | 0.76% |
| 全くしていない | |
128票 | 97.71% |
| |||
| 投稿者 | 投稿内容 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-05-07 22:29
※これまでのコメントをあまり読まずに逆コンパイル対策に関する意見を書きます。
逆コンパイル対策を施すかどうかというのは、ソフトウェアの形態によって大きく変わってくると、私は思っています。 例えば、日本は受託によるカスタム開発が多く、パッケージ アプリケーションはほとんどありませんが、特に市販パッケージ アプリケーションであれば逆コンパイル対策はすべきだと思います。 市販パッケージ アプリケーションの例として、Visual Studio 2005やMicrosoft Office 2007がすべて.NETで書かれていたと仮定してそのすべてのコードを誰でも逆コンパイルできるとしたら「これは危険じゃないか」と思います。例えば「パスワードなどの認証」のクラック方法が簡単に解明されてしまうなどの問題があると思います。パッケージ アプリケーションを再コンパイルした海賊版がこれまで以上に簡単に作れるという状況になるのではないでしょうか。 もちろんソフトウェアである限り解析すればどれでもクラック可能だと思いますが、逆コンパイル対策がされていれば「簡単にはクラックできない。意味不明なクラス名などを読み込んで調べるのが面倒くさい」という心理障壁になり得ます。特に素人に近いクラッカーは手を出さない可能性が高くなると考えます。 パスワード認証のロジックや逆コンパイル対策は、クラックなどの問題を完全に防ぐ解決策ではないと思いますが、心理障壁を作るうえで有効なのではないでしょうか。それ以上の対策をしようとすれば、クラッカーとのいたちごっこになってしまい、（製品の競争力を高めるために最も重要な）開発生産性を落とす結果になってしまいます。要はバランスが大事で、最低限の心理障壁を作ったうえで、いたちごっこはせずに開発生産性を保つのがベストだというのが、わたしの意見です。その最低限の心理障壁が逆コンパイル対策というわけです。 | ||||||||||||||||||||
|
投稿日時: 2007-05-07 22:59
たとえば、RSA暗号方式は、その暗号化のアルゴリズムが公開されているわけですが、（十分に長いビットを用いれば）安全な暗号化手法のひとつです。ということは、ソースが読めるからといって、必ずしもセキュリティ的に問題が発生するとは言えないでしょう。 http://ja.wikipedia.org/wiki/RSA まぁ、車輪の再発明をしていたり、既知のアルゴリズムの応用、組み合わせであることがほとんどですよ。 ただし、.NET Framework の System.String は要注意です。これは Dispose 出来ませんので、いつまでもメモリに残ります。つまり、パスワードを System.String 型に放り込むと、メモリを覗き込むようなソフトに対してパスワードが丸見えになるということです。2.0 では対策された文字列が用意されましたが、それだけですべてを扱うことが出来ない（ファイルの入出力などは System.String を使わなければならない）ので、未だに中途半端です。 もちろんこれは、難読化とは別の問題です。 _________________ | ||||||||||||||||||||
|
投稿日時: 2007-05-07 23:41
まったくその通りですね。 --- 逆にいえばコードが読めることによるセキュリティ問題が発生することもあるわけで、例えば海賊版などでは、恐らく暗号化のアルゴリズム自体をクラックしているのではなく、そのアルゴリズム自体をジャンプ（スキップ）してしまっているのではないかと思っています（つまり技術力やアルゴリズム自体を解析する能力はあまり要らない…）。そういうケースで、ソースコードが露呈してしまうと問題になるかもしれません。 クラックについては1つの例で、そういう細かいところを意見したいわけではなく、「逆コンパイル対策はソース コードを読みたいと思う人に対する心理障壁として1つの有効な手段になり得る」と思っています（つまり開発者にとっては「逆コンパイル対策しても苦労すれば読めるから意味がない」と思うかもしれませんが、コードを逆コンパイルして読みたい人に対しては「心理障壁としての効果はあると思うよ」ということです）。 もちろんこの主張が成り立つのはコードを読ませたくないという動機が前提です。動機としていろいろあると思いますが、例えばクライアントで動くパッケージ アプリケーションの場合、他社と違う機能を売りにして競争力を出す場合もあるので、そういう企業では逆コンパイル対策をしておきたいということもあるんじゃないかと思います。 ＃逆コンパイル対策が必要な状況というのは、すべての企業で一様ではないと思うので、それが必要か不要かというのを一般的な回答として導き出すのは無理じゃないかと思います。 以上。 | ||||||||||||||||||||
|
投稿日時: 2007-05-08 09:01
皆さん、色々なご意見ご指摘ありがとうございます。
もちろん、著作権については、知っているつもりです。ただ、法律で罰せられるからと言って抑止力としては不十分な場合もあると思います。例えば、万引きを例に取りますと、万引きは、窃盗罪になりますが、実際に万引きをする者たちが後を絶たず、それで潰れてしまう店もあります。だから、店側は、防犯カメラや万引き防止ゲート（レジを通さずに商品を持ち出すとゲートを通過時に警報が鳴るやつ）等の技術的抑止力（心理的抑止力も）を持って対抗しています。この防犯カメラや万引き防止ゲートにあたるものが、逆コンパイル対策とか不正コピー対策だと考えます。それに、いざ、法的に立証するとなると、なかなか難しいと思います。逆コンパイルに纏わる裁判とか事件とかってありますか？ よく同意事項とかで逆コンパイル及びリバースエジニアリングの禁止とか書いてありますが・・・ うちは、一般向けアプリケーション開発でも、受託開発でも、ソースコードで納品するような事はしないで、EXEにして納品しています。 それに、MSもソースコードは、公開してないじゃないですか。それが、MSの利益と独占の源ではないですか。 # 別に、MSと、張り合う気はないですが。 | ||||||||||||||||||||
|
投稿日時: 2007-05-08 10:09
逆コンパイルされて損害がでる可能性がまったく０だとはいいきれませんが
プログラムを見られて死活問題になるような.NETのコードって思いつきません。 言い方を変えると、唯一その会社にしかかけない.NETのコードってあるんでしょうか。 コピーする側からみると、コードだけ持ってたとして、それを自分の想定する動作に 改造するのにどれだけの労力がいるか、とか考えたら、作った方が早いのかもしれません。 ちゃんとした会社は不正コピーなんかしない、そうでない場合はコピーされてもたいした 損害にならない、ともいえるかもしれません。 万引きの場合は商品そのものが奪われるので店がつぶれてしまうのですね。 ソースを見られることが直接損害につながるわけではないので少し違いますね。
詳細設計書を納品する場合もあると思いますが、それを元にプログラムを作られたら、、とか。
これは個人的な意見ですが、もし自分が先進的なコードを書いたとしたら、それを真似して もらって業界全体の技術が向上した方が結果的には自分にもプラスになる、と考えます。 (自分がそういう立場になることはありえないですが) | ||||||||||||||||||||
|
投稿日時: 2007-05-08 10:31
ソースを納品しないで納得するお客さんって、結構いるんですかね。 僕は、実行モジュールだけの納品って経験したことないので。 僕が発注側なら、嫌ですね。 だって、改修時に困るじゃないですか。 システム構築時には安価であっても、改修時にボラれるかもしれないし。 脱線、失礼。 | ||||||||||||||||||||
|
投稿日時: 2007-05-08 11:24
一般向けでも、受託開発でも、最初は利益（赤字にしても）は考えず、改修やバージョンアップの時に、初めて費用や利益を回収するという場合もあるのではないかと思います。
そうですね。EXEの不正コピー対策も必要と考えています。 昔、パソコンのプリンターポートか何かに付けて不正コピーを防止するようなものを見た事があります。
ExcelやWordも、いつか、.NETで書かれる日が来るのでしょうか・・・ | ||||||||||||||||||||
|
投稿日時: 2007-05-08 11:47
ドングルですよね。結局本気でクラックすれば回避できます。
ExcelやWordもソースが見られて困るような、 先進のアルゴリズムを採用しているのではなく、 単に改良の積み重ねによるコードのような気がしますが。 | ||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。