最近、私はアプリケーションのセキュリティとバイナリと逆コンパイラを考えています。 (FYI- Decompilersは単なる反コンパイラであり、目的はバイナリからソースを取得することです)
「Perfect Decompiler」のようなものはありますか?
元のソースは-一部の言語では-回復不能です。ソースのバージョンを作成できますが、変数の意味のある名前が不足します。また、コメントが不足し、インラインコードの展開が混乱を招くほど繰り返される可能性があります。
コンパイラを最適化すると、復元されたソースがかなり不明瞭になる可能性があることに注意してください。
他の言語では、ソースの合理的に読み取り可能なバージョンを復元できる十分なデバッグ情報があります。
[完全]は、すべての変数名/マクロ/関数/クラス/可能であればコメントをそれぞれのヘッダーに含む元のソースファイルと、バイナリの取得に使用されるソースファイルを意味します)
決して。プリプロセッサからのマクロはソースの一部ではなく、常に永久に失われます。
「可能であればコメント」はあまり意味がありません。私はあなたがコメントを望んでいることを意味すると仮定します。彼らはまた、一般に永遠に消え去っています。
ただし、マクロやコメントが欠落しているものからバイナリを取り戻すことはできます。したがって、「完璧」の定義に一貫性がありません。
バイナリはリバースエンジニアリングから安全ですか?
番号。
ソフトウェアのリバースエンジニアリングを防止するために使用されるベストプラクティスにはどのようなものがありますか?
新しいバージョンをすばやく提供するため、前のバージョンをリバースエンジニアリングする価値はありません。
それは大きな懸念事項ですか?
弁護士のみ。
また、スクリプトの不正なハッキングを防ぐ唯一の方法は、難読化/ファイルのアクセス許可ですか?
「不正なハッキング」とは何ですか?実際、スクリプトの "ハック"とはどういう意味ですか?
スクリプトをいじくり回したい場合は、スクリプトをいじってください。もちろん、それがWebサーバー上になければ、そうではありません。次に、スクリプトにアクセスするのではなく、スクリプトが表示するWebページにアクセスします。
デコンパイラーは間違いなく事実です Reflector は優れた例です。
私が知っていることによって、十分に賢く、十分に決定されている場合に、実際にコードを逆コンパイルするのを止めることはできません。それが弁護士とソフトウェア特許です。
しかし、難読化はほとんどの人を阻止するための適切な方法です。たとえば、個人的にはハッキングに興味はありませんが、何かを修正しようとしていて、Reflectorを使用して簡単に逆コンパイルできる場合は、それを行います。
彼らが物理的に持っている場合、「経験則」はハッキングされているのと同じです。
暗号化されている場合でも、アプリ内のどこかにキーが保存されていれば、そのデータを取得できます。
何かを保護する唯一の方法は、それをサーバーに保持し、ゲートキーパー(つまり、安全なWebサービス)を用意することです。
逆コンパイルするのが最も難しいバイナリは、あなたが持っていないバイナリです。オンラインサブスクリプションモデルに移行するソフトウェアが増えるにつれ、クライアントのリバースエンジニアリングにはある程度の価値がありますが、すべてを提供できるわけではありません。確かに、受信した出力からコードを特定するために、多くの入力で何度もサーバーサービスにアクセスしてみることができますが、最も単純な場合を除いて、ほとんどの場合、エラーが発生しやすくなります。
また、逆コンパイルは双方向の方法です。誰かがあなたのソフトウェアを逆コンパイルして、変更されたバージョンを販売または譲渡しようとした場合、そのコードを逆コンパイルして比較できます。大量のオーバーラップが彼らの行動を裏切ることになります。誰かに見せたくないかなりスマートなアルゴリズムや、企業秘密と見なされるプログラムの何かがある場合は、リモートサーバーへのサービス呼び出しを行うことが最善の保護になります(ただし、すべてのケース)。
私はそれが得意ではありませんでしたが、試してみたところ、数年前に単純なモニター/デバッガー/逆アセンブラーで驚くほど(つまり、試したことがない人にとって)複雑なことを行うことができました。
したがって、これまでに考案されたすべての保護スキームがどのようにして解読されたかを想像するのは難しくありません。 (通常、開発にかかる時間よりも短い時間です。)
人間の頑固さと忍耐力は、しばしば過小評価されています。
ソフトウェアのリバースエンジニアリングを防止するために使用されるベストプラクティスにはどのようなものがありますか?それは大きな懸念事項ですか?
あなたが提供するすべてがコードであるならば、あなたは外の訴訟を多くすることができないので、それは大きな懸念です。したがって、コードを提供するだけではいけません。コードを補完するサポート、トレーニング、その他のサービスを提供します。コードは、刻々と変化する市場に適応できるようにしてください。コードはソフトウェアビジネスの「コア」となる可能性があり、またそうである必要がありますが、コード自体が存在することはないと思います。
C/C++/Delphiバイナリの逆コンパイルの可能性について本当に理解したい場合は、Stuxnetに関するSymantecのテクニカルホワイトペーパーを参照してください。
ネイティブコードに直接コンパイルしないほとんどすべての言語は、逆コンパイルが比較的簡単なようです。
これが問題である場合は、特別なソースをWebサーバーに配置する方法を考えてみてください。使用される他のメカニズムの1つは、暗号化キーまたはコードの一部を保持する物理ドングルです。 YMMV、アプリケーションによって異なります。
それは本当に言語に依存します、バイナリをパックしてセキュリティの追加レイヤーを提供できますが、ほとんどの場合、逆コンパイルは何も役に立たず、コードに機密情報が文字列として含まれている場合、多くの逆コンパイラは文字列参照を抽出できます悪いことができます。
他の逆コンパイラは、フォーム定義などの情報を抽出できます。
これについての考えや労力を無駄にしないでください。デコンパイラ保護は基本的にコピー保護と同等であり、不可能であることがわかっている問題を解決しようとしています。
CPUがそれを実行するには、プログラムが機械可読形式である必要があり、それを回避する方法はありません。日曜日から7つの方法で暗号化したとしても、実行する前に再度復号化する必要があり、その時点でデバッガーがメモリを調べてコードを読み取ることができます。他の何人かの人々が述べたように、誰かがあなたのプログラムを逆コンパイルしないようにする唯一の方法は、例えばウェブサービスを使用して、彼らのシステムから完全にそれを遠ざけることです。
デコンパイラーはアンチコンパイラーではなく、CまたはC++コードがどのように見えるかを提供するだけです(コンパイルされた言語について話しているため、これは例です)。
コンパイラがC/C++をどのように変換するかを確認するには、実際にアセンブリコードがどのように見えるかを確認してください。
難読化は逆コンパイルとは関係ありません。コンパイルしたコードではなく、実際に記述したコードを誰かが読み取れるようになると、JavaScriptなどの解釈されたコードのみを難読化します。
しかし、おそらく内部オフセットアドレスを暗号化するなど、一部のコードを逆コンパイルしにくくするいくつかの方法があると思います。もちろん、実行時間が重要でない場合は、これは興味深いテーマです。
一方、純粋なCの方がC++よりも逆コンパイルが簡単かもしれません。テンプレートの逆コンパイルを想像してみてください。すでにコードの悪夢である場合、どのように逆コンパイルできるか想像できません。
C#コードの逆コンパイルは非常に簡単です。
競合他社がコードを逆コンパイルして自分で使用することはないと思いますが、それが難読化を使用する理由です。すべてのハッカーの99%を止めるのに十分であり、私たちの管理者を幸せに保ちます。
必要なセキュリティのレベルは、実際にはアプリケーションによって異なります。何百万人ものハイテクユーザーに使用されますか?ほとんどの場合、単純な難読化で十分です。
デコンパイラーを使用して、ソースコードを少しの労力で魔法のように見せるためにリバースエンジニアリングが問題になるとは思いません。コンパイラで完全に取得できるほど単純なアプリケーションは、おそらく他の誰かが作成したものである可能性があります(おそらくそうです)。
10万ドル以上の企業向けアプリケーションには、Webサイトからプログラムをダウンロードできないものがたくさんあります。彼らはニッチ市場を有しており、デモをインストールした場合、潜在的なビジネス顧客のいずれかがソースコードを盗もうとすることはほとんどありません。
あなたは本当に買う価値のあるものを作り、あなたが周りにいる人々にそれをサポートし改善するよう説得する必要があります。