29

別の質問、つまりBest .NET obfuscation tools/strategyでは、ツールを使用して難読化を簡単に実装できるかどうかを尋ねます。

私の質問は、難読化は効果的ですか? この回答に返信するコメントで、誰かが「ソースの盗難が心配なら...難読化は本物のクラッカーにとってほとんど些細なことだ」と言っていました。

私は Dotfuscator の Community Edition からの出力を見てきました。難読化されているように見えます。私はそれを維持したくありません！

難読化されたソフトウェアを単純に「クラッキング」するのは比較的簡単かもしれないことを理解しています。なぜなら、クラッキングしたいもの (通常はライセンス保護) を実装しているソフトウェア内の場所を見つけ、それをスキップするジャンプを追加するだけだからです。

しかし、心配がエンドユーザーや「海賊」によるクラッキングだけではない場合: 心配が「ソースの盗難」である場合、つまり、あなたがソフトウェア ベンダーであり、あなたの心配が別のベンダー (潜在的な競合相手) である場合は、逆-ソースをエンジニアリングして、それを自社の製品に使用したり、製品に追加したりできます...単純な難読化は、そのリスクに対する適切または不十分な保護の程度を示していますか?

最初の編集:

問題のコードは、エンド ユーザー マシン (リモート サービスではなくユーザー コントロール) で実行される約 20 KLOC です。

難読化が本当に「本物のクラッカーにとってほとんど些細なこと」である場合、それが効果的でない理由(「どれだけ」効果的でないかだけでなく)についての洞察が欲しいです。

2回目の編集:

私は、誰かがアルゴリズムを逆にすることを心配していません。それよりも、アルゴリズムの実際の実装(つまり、ソース コード) を自分の製品に転用することを心配しています。

20 KLOC の開発に数か月かかると考えた場合、すべての難読化を解除するには、これより (数か月) かかるでしょうか?

何かを「盗む」ために難読化を解除する必要さえありますか? それとも、正気の競合他社が、難読化されたまま製品に大規模に組み込み、メンテナンスの悪夢であることをそのまま受け入れ、メンテナンスがほとんど必要ないことを望んでいるでしょうか? このシナリオが可能である場合、難読化された.Netコードは、コンパイルされたマシンコードよりも脆弱ですか?

難読化の「軍拡競争」のほとんどは、「ソースの盗難」を防ぐことよりも、人々が何かを「クラッキング」することさえ防ぐこと (たとえば、ライセンス保護/強制を実装するコードフラグメントを見つけて削除すること) を主に目的としていますか?

4

9 に答える 9

42

ここで、難読化がクラッキングに対する効果的な保護手段であるとは思わない理由について説明しました:
リバース エンジニアリングから .NET コードを保護する

ただし、あなたの質問は特に興味深いトピックであるソースの盗難に関するものです。Eldad Eiliams の著書「Reversing: Secrets of Reverse Engineering」では、最初の 2 つの章でリバース エンジニアリングの背後にある理由の 1 つとしてソースの盗難について説明しています。

基本的に、ソース盗難の標的になる唯一の可能性は、ドメインに関連する非常に具体的でエンジニアリングが難しいアルゴリズムを持っている場合であり、それによって競合他社に有利になります. これは、アプリケーションのごく一部のリバース エンジニアリングを試みることが費用対効果の高い唯一の機会です。

したがって、競合他社に持たせたくない極秘アルゴリズムを持っていない限り、ソースの盗難について心配する必要はありません。アプリケーションから大量のソース コードをリバースするためのコストは、最初から書き直すコストをすぐに上回ります。

アルゴリズムを持ってほしくない場合でも、(アプリケーションが彼らのマシンで実行されている場合) 決定的で熟練した個人がそれを取得するのを止めるためにできることはあまりありません。

いくつかの一般的な逆転防止対策は次のとおりです。

  • 難読化 - ソースの保護やクラッキングの防止に関してはあまり効果がありません。しかし、それを完全に簡単にすることはできませんよね？
  • サードパーティのパッカー - Themidaは優れたパッカーの 1 つです。実行可能ファイルを暗号化された win32 アプリケーションにパックします。アプリケーションが .NET アプリでもある場合、反射を防ぎます。
  • カスタム パッカー - アプリケーションのアンパック方法に関するクラッキング シーンの情報がほとんどないため、スキルがあれば独自のパッカーを作成すると効果的な場合があります。これにより、経験の浅い RE を止めることができます。このチュートリアルでは、独自のパッカーを作成するための優れた情報を提供します。
  • 業界秘密のアルゴリズムをユーザーのマシンから遠ざけてください。命令がローカルで実行されないように、それらをリモート サービスとして実行します。唯一の「フールプルーフ」保護方法。

ただし、パッカーはアンパックできます。難読化は、アプリケーションが何をしているかを見たい人を実際には妨げません。プログラムがユーザーのマシンで実行されている場合、脆弱です。

最終的にそのコードはマシン コードとして実行する必要があり、通常はデバッガーを起動し、いくつかのブレークポイントを設定して、関連するアクション中に実行される命令を監視し、このデータを精査するのに時間を費やします。

あなたは、アプリケーション用に ~20kLOC を作成するのに数か月かかったとおっしゃいました。最低限の予防策を講じた場合、アプリケーションからこれらの同等の 20kLOC を実行可能なソースに戻すには、ほぼ桁違いの時間がかかります。

これが、アプリケーションから小規模な業界固有のアルゴリズムをリバースすることが費用対効果に優れている理由です。それ以外のものは価値がありません。

次の架空の例を見てみましょう。たとえば、iTunes 向けのまったく新しい競合アプリケーションを開発したとしましょう。数百万の LOC と開発に 2 年かかったとしましょう。私が持っている重要な機能の 1 つは、音楽を聴く好みに基づいて音楽を提供する新しい方法です。

Apple (彼らは海賊です) はこれを知り、あなたの音楽提案機能が本当に気に入ったと判断したため、元に戻すことにしました。次に、そのアルゴリズムのみに焦点を合わせ、リバース エンジニアは最終的に、同じデータが与えられた場合に同等の提案を提供する実行可能なアルゴリズムを考え出します。次に、そのアルゴリズムを独自のアプリケーションに実装し、それを「天才」と呼び、次の 10 兆ドルを稼ぎます。

それがソースの盗難が減少する方法です。

100k LOC をすべて逆にして、コンパイル済みアプリケーションのかなりの部分を盗む人はいません。それは単に費用がかかりすぎ、時間がかかりすぎます。約 90% の時間で、ボタンの押下やユーザー入力を処理するだけの、退屈で業界機密ではないコードをリバースしていました。代わりに、独自の開発者を雇って、より少ない費用でほとんどをゼロから書き直し、エンジニアリングが難しく、優位性をもたらす重要なアルゴリズム (つまり、音楽の提案機能) を単純に逆にすることができます。

于 2009-02-16T01:26:41.473 に答える
10

難読化は、あいまいさによるセキュリティの一種であり、ある程度の保護を提供しますが、セキュリティは明らかにかなり制限されています。

あなたが説明した目的のために、あいまいさは確かに役立ち、多くの場合、コード盗難のリスクに対する適切な保護です. ただし、十分な時間と労力があれば、コードが「難読化されていない」というリスクは確かにあります。コードベース全体の難読化を解除することは事実上不可能ですが、利害関係者が実装の特定の部分をどのように行ったかを判断したいだけの場合、リスクは高くなります。

最終的に、リスクがあなたやあなたのビジネスにとって価値があるかどうかを判断できるのはあなただけです。ただし、多くの場合、顧客に自社の環境で使用する製品を販売したい場合は、これが唯一のオプションです。

「効果がない理由」については、クラッカーがデバッガーを使用して、使用されている難読化手法に関係なく、コードが実行されている場所を確認できるためです。その後、彼らはこれを使用して、シリアル番号や「テレフォン」システムなど、導入した保護メカニズムを回避できます。

あなたのコードが盗まれて別のプロジェクトで使用されるという意味で、コメントが本当に「コードの盗難」に言及しているとは思いません。彼らは「クラッカー」という言葉を使っていたので、ソフトウェアの著作権侵害の観点から「窃盗」について話していたと思います。クラッカーは、保護メカニズムを回避することに特化しています。彼らはあなたのソースコードを他の目的に使用することに興味がありません。

于 2009-02-16T00:19:59.340 に答える
7

ほとんどの人は難読化されたコードのように見えるものを書く傾向がありますが、それはクラッカーを止めていません。違いは何ですか?

編集：

よし、真剣な時間だ。本当に壊れにくいものを作りたいのなら、ポリモーフィックコーディングを調べてください (ポリモーフィズムと混同しないでください)。自己変異するコードを作成してください。壊すのは非常に苦痛であり、推測を続けることになります。

http://en.wikipedia.org/wiki/Polymorphic_code

結局のところ、リバース エンジニアリングが不可能なことはありません。

于 2009-02-16T00:38:23.147 に答える
6

あなたは、あなたの製品で使用されている特定のアルゴリズムを人々が盗むことを心配しています。あなたはFairIsaacであるか、 x++;よりも多くの方法を使用して差別化する必要があります。他の誰かが数時間それを困惑させることによって解決できないコードの問題を解決した場合は、発明を保護するためにコンピュータサイエンスおよび/または特許の博士号を取得する必要があります。ソフトウェア製品の99％は、アルゴリズムが原因で成功または特別ではありません。彼らの作者は、よく知られていて簡単に理解できる概念を、顧客が必要とすることを実行し、他の人に同じことをやり直すために支払うよりも安い価格で販売する製品にまとめるために手間をかけたので成功しています。

于 2009-02-16T02:45:00.317 に答える
3

このように見てください。あなたが質問を入力した WMD エディターは、いくつかのバグを修正し、いくつかの拡張を行うために、SO チームによってリバース エンジニアリングされました。そのコードは難読化されていました。知的で意欲的な人々があなたのコードをハッキングするのを止めることは決してできません。期待できる最善の方法は、正直な人々を正直に保ち、コードを解読するのをやや難しくすることです。

于 2009-02-16T01:37:21.523 に答える
2

逆アセンブラーからの出力を見たことがある場合は、難読化が常に失敗する理由がわかるでしょう。

于 2009-02-16T03:20:43.367 に答える
1

ソースを保護したい場合、難読化はあまり効果的ではないと私は考える傾向があります。その分野の真の専門家 (ここではソフトウェアの専門家やクラッカーを意味するのではなく、コードの機能の分野の専門家を意味します) の場合、通常、彼または彼女はコードを見る必要はありません。特別な入力やエッジ ケースなどに対してどのように反応するかを確認して、その保護された機能と同等のコピーまたはコードを実装する方法を理解してください。したがって、ノウハウの保護にはあまり役立ちません。

于 2009-02-16T00:17:58.720 に答える
1

どんな犠牲を払っても保護しなければならない IP がコードに含まれている場合は、セキュリティで保護されたリモート サーバー上で、ソフトウェアの機能をサービスとして利用できるようにする必要があります。

適切な難読化によってある程度は保護されますが、コードを取得するという「報酬」に対して難読化を破るために必要な労力がすべてです。平均的なビジネス ユーザーを停止することについて話している場合は、商用の難読化ツールで十分です。

于 2009-02-16T00:18:28.033 に答える
0

簡単な答えは「はい」と「いいえ」です。それは、何を防ごうとしているかに完全に依存します。セキュア プログラミング クックブックのセクション 12653ページにこれに関する興味深いコメントがあります（Googleブックスのプレビューでは便利に利用できません）。改ざん防止を次の 4 つのカテゴリに分類します。ゼロデイ (攻撃者の速度を低下させて、攻撃者が目的を達成するのに長い時間がかかるようにする)、リバース エンジニアリングを防止するための独自のアルゴリズムの保護、攻撃を「できるから」、「できるから」です。 4番目を思い出してください。私が何を防ごうとしているのかを尋ねる必要があります。ソース コードを誰かに見られることを本当に懸念しているのであれば、難読化には何らかの価値があります。単独で使用すると、通常、誰かがアプリケーションをいじろうとするのを邪魔するだけであり、優れたセキュリティ対策と同様に、他の改ざん防止技術と組み合わせて使用​​すると最も効果的です。

于 2009-02-16T00:35:42.280 に答える