none
逆コンパイル対策について RRS feed

  • 質問

  • blue200102と申します。

    逆コンパイル対策について、頭を悩ませています。

     

    開発環境

    Visual Studio 2003 VB.Net

    SQL Server2000

    VB 6.0

    元々は、VB6.0をベースに開発を続けていましたが4年ほど前からVB.Netに、徐々に移行しています。

     

    .Netプログラムは、中間言語MSILベースですので、かなりの精度で逆コンパイル出来てしまうようです。これは、著作権保護、ノウハウ保護という点で非常に問題です。Visual Studioには、おまけでDotfuscator Community Editionなるものが付いてきますが、名前空間、型、メソッドの名前を変更するだけで、全然、対策になってない気がします。

    そこで、皆さんに以下の事を伺いたいと思います。

     

    一、

    逆コンパイルに対してどの程度の危機感を持たれていますか?

    根幹に関わる問題だ、或いは、別に俺のプログラムを読ませたいやつには読ませてやる等の色んな見解があると思いますが・・・

     

    二、

    そもそも、逆コンパイルされるとどんな事が起こるのですか?

    自分の作ったプログラムをチョト変えてそのまま売られちゃうとか、一部のロジックを真似されてしまうとかですか・・・

     

    三、

    逆コンパイル対策としては、どの様な対策がありますか?

    難読化については、難読化するプログラムが発売されているようですか、どれも高額ですね。フリーの難読化プログラムとかないのでしょうか?Javaとかだと有名なフリーの難読化ツールが複数あるようですね。

    また、EXE自体を暗号化してしまうという不正コピー防止ツールが、昔からありましたが、あれなんか逆コンパイル対策として有効なんですか?

     

    四、

    VB 6.0で開発してコンパイルしたEXEは、マシン語なので、逆コンパイルされても精度が悪く、難解で、解析するには、高いスキルと根気と多大な労力が掛かると聞きましたが、これは、本当なのですか?

     

    五、

    逆コンパイル、難読化、EXEの暗号化等について、何か意見や見解、体験談等が御座いましたら、是非、聞かせてください。

     

     

    以上、長くなりましたが、よろしくお願いします。

     

     

     

     

     

    2007年5月4日 7:44

すべての返信

  • 私は、以下の場合で逆コンパイル対策が必要だと思っています。

     

    ①セキュリティ対策(ソースを見ることでセキュリティホールを見つけるのが容易になってしまうため)

    ②ソースもしくはソースから読み取れる仕様自体に製品の価値がある場合

     

    上記より、

    ・①、②共に考慮すべきであるパッケージ製品などは絶対対策を施したい。

    ・業務内容にもよりますが、利用者が制限され、①、②共にパッケージ程厳密に

     しなくてもいいであろう業務アプリケーションなどは、できれば対策を施したい。

     

    という感じで考えてます。

     

    2007年5月4日 15:11
  •  blue200102 さんからの引用

    Visual Studioには、おまけでDotfuscator Community Editionなるものが付いてきますが、名前空間、型、メソッドの名前を変更するだけで、全然、対策になってない気がします。

     

    なにを目的とするかですね。Dotfuscator Community Edition はかなりの機能が省略されていますが、製品版の体験版もありますのでそちらも試してみるとよいかもしれません。製品版で最大限に難読化されたアセンブリはかなり読みにくいと思います。

    また、Community Edition の主機能である Renaming obfuscation は、確かにある有る程度の環境がそろってれば大きな障害になりませんが、最初の一歩目をくじけさせるという意味での効果はそれなりに高いと思います。(コードフローの変更とは異なり Renaming は実行時のコストがないという大きな利点があります)

     

    Renaming を通した後の

     



    public void a(int a, short a, string a)
    {
      long a; double a; float a; object a;
     
      a = a(a + 3, a);
    }

     

     

    みたいなコードを見て、どの a に 3 を足したものを、どの a に代入しているか、そなりの割合の解析者をこの時点でくじけさせることはできていると思います。

    さらに、このクラスに a() というメソッドが50個オーバーロードされているような状況であれば、なおさらです。

    # DotFuscator 製品版の Renaming は、極力 上記のようなコードを作成するようになっています。

     

     blue200102 さんからの引用

    逆コンパイルに対してどの程度の危機感を持たれていますか?

    根幹に関わる問題だ、或いは、別に俺のプログラムを読ませたいやつには読ませてやる等の色んな見解があると思いますが・・・

     

    プロダクトの性質によって意見は180度はかわるので、あまり意味のない問いかけだと思います。

    問題になるのはコードを保護したいと考えた場合に、どのような手段があって、どのような行為に対する抑制力を発揮するか、といったところでしょうか。

    基本的には、利用規約等による法的な保護と、 Dotfuscator などのツールによる物理的な保護を、プロダクトの目的にあわせて採用すればよい問題に思います。

     

    たとえば、プロダクトで生成されるデータを十分な強度で暗号化したいと考えたとき、暗号化のロジックが丸見えでは意味がなくなるものもあれば、ロジックが見えているだけでは大きな障害とならないケースもあったりするわけです。このような違いのある2つのプロダクト開発者にたいして質問を投げたとして、似通った回答を得ることはできないでしょう。

     

     

     blue200102 さんからの引用

    そもそも、逆コンパイルされるとどんな事が起こるのですか?

    自分の作ったプログラムをチョト変えてそのまま売られちゃうとか、一部のロジックを真似されてしまうとかですか・・・

     

    複製そのものも問題がありますが、オープンでないシステムの実装を知られることで、競合他者に市場競争で敗北するなどの問題もありますよ。 

     

     blue200102 さんからの引用

    逆コンパイル対策としては、どの様な対策がありますか?

    難読化については、難読化するプログラムが発売されているようですか、どれも高額ですね。

     

    難読化関連は確かにお高いですね。

    1つには、多くのコンシューマが逆コンパイルに関して強い問題意識を抱えており、それに対して見合うだけの機能を提供しているからではあると思います。

    もう1つには、フロー制御に手をだしている難読化ツールの技術サポートにかかるコストが高いのではないかと思います。

     

    フロー制御の難読化は、コードをおなじ結果を生む違う内容に書き換えるわけですが、機械的に判断して書き換えた結果が同じではない場合は少なくは無く、難読化を実施したらアプリケーションが動作しなくなるということは珍しくないでしょう。また、そのような問題が発生した場合に、問題点を明確にしたり単純化するのが非常に困難です。難読化ツールの顧客は、ソースコードを知られたくないから難読化ツールを通しているのであって、「こういうソースコードを難読化したら動かない」という報告を実施することができません(当然ですね、知られたくないんですから)

    顧客が開発会社とは限らず、完成したプロダクトをリリースする販売会社が難読化を実施している場合だってあるでしょう 

     

     blue200102 さんからの引用

    フリーの難読化プログラムとかないのでしょうか?Javaとかだと有名なフリーの難読化ツールが複数あるようですね。

     

    2~4年前に google 等で検索したときは、それなりの量の難読化ツールがフリーでも公開されていました。ほとんどのツールは Dotfuscator Community Edition と比較して、機能が少ないか同じ程度であったと思います。フロー制御にまで手をだしているものが、1つぐらいはあったように記憶していますが、現状がどうなっているかわかりません。

     

     blue200102 さんからの引用

    また、EXE自体を暗号化してしまうという不正コピー防止ツールが、昔からありましたが、あれなんか逆コンパイル対策として有効なんですか?

     

    すこし上に書きましたが、「保護したいと考えた場合に、どのような手段があって、どのような行為に対する抑制力を発揮するか」ということを考えてください。

    実行ファイルのバイナリが暗号化されることによって抑制力を発揮できる行為もあれば、まったく意味がない行為もあります。それが各自の要求する目的にかなっているかどうかというのは、プロダクトの性質によって yes でもあり、 no でもあるので、判断できるのはプロダクトの開発・リリース元たる自分自身だけです。

     

     blue200102 さんからの引用

    VB 6.0で開発してコンパイルしたEXEは、マシン語なので、逆コンパイルされても精度が悪く、難解で、解析するには、高いスキルと根気と多大な労力が掛かると聞きましたが、これは、本当なのですか?

     

    どうでしょう? (VB6 は pcode と native code の2種類が選べた気もしますがそれはおいといて)

    その手の実務に携わったことはないのですが、meta data 的な要素がないことを別にすれば、低レベルな IL の命令と IA32 の OpCode にそれほど大きな差異があるようには見えませんので、単純に IL とマシン語を比較するのであれば、マシン語にすれば精度が悪くて難解になるということは、まったく期待できないと思います。

    # どちらかというと JIT による最適化を前提とした IL コードの単純化のほうが問題なんだろう、とか。

     

    2007年5月4日 20:36