逆コンパイルを防ぐためにCベースの実行可能ファイルまたはライブラリを難読化する方法はありますか?
13 に答える
いいえ。逆コンパイルをより困難にすることはできますが、防ぐことはできません。私のアドバイスは、時間を無駄にするのをやめ、代わりに、常に改善されている機能を備えた素晴らしい製品を提供することに集中することです。
そうすれば、人々は喜んでそれを支払うでしょう。
主な問題は、コードを解読不能にする唯一の方法は、コードを実行不能にすることです。PCにロードできるものはすべてクラックされる可能性があります。楽しみ、利益、名声のためにリバースエンジニアリングを行う人々は、一般的にそれが非常に得意であり、彼らを止めようとするためにあなたがすることによって、実際には少しずつ段階的に行われることはありません。
彼らはあなたがコードを難読化する仕事よりもはるかに簡単にあなたのコードを解読する仕事をするツールにアクセスできます:-)あなたのソフトウェアが購入する価値があることを世界中に納得させるためにはるかに良いです本物のユーザーへの「泥棒」。
たとえば、彼らがあなたのソフトウェアにお金を払っていない理由を見つけて、それを修正してみてください。100%の人を変換することは決してありません。楽しみのためだけに、コードを海賊版にする人もいます。
CwF + RtBに関するtechdirtに掲載されている一連の記事をチェックしてください(ファンとつながり、購入する理由)。そこで提起されたポイントの多くは、ソフトウェア業界にも当てはまる可能性があることがわかりました。
簡単な方法:パッカー/クリプター/難読化製品を購入します。高価でゲームで使用されるものもあれば、そうでないものもあります。「コピー防止」などの流行語で彼らのためにグーグル。
高速な方法: UPXをパックしてから、ヘッダーをどこかにマングルして、メモリにロードされて正常に実行されるようにしますが、upxユーティリティはエラーで失敗します(バージョンフィールドを試してください)。upxユーティリティが失敗した場合、95%はあきらめます。
難しい方法:独自のパッカーを作成します。
ああ、私は忘れました:
本当に簡単な方法:そのまま出荷するだけです。いいえ、実際には-あなたが何をしても、人々はあなたのコードをリバースエンジニアリングすることができます。あなたがそれを投入する努力の量は、それを元に戻すことができる数を制限するだけです。
完全に最適化してコンパイルします。
逆コンパイル(No More Gotos)と難読化の実践(Flowtables)と理論(Indistinguishability Obfuscation)の両方が活発な研究分野であるため、解決策はなく、ツール、技術、専門知識のみです。コードを本当に非コンパイルの影響を受けないようにしたい場合は、Webアプリを作成し、機密性の高いコードサーバー側を配置します。しかし、誰かにバイナリを与えるというモデルに固執している場合は、セキュリティとパフォーマンスの間で行いたいトレードオフを賢明に判断する必要があります。難読化にはコストがかかりますが、それでも完璧ではありません。いくつかのオプション
- UPX以外のパッカーを使用します(UPXは多くのLinuxディストリビューションにインストールされています)。パフォーマンスコストは低く、ほとんどの人は静的分析のためにバイナリを手動で解凍するスキルを持っていません。しかし、経験豊富なリバーサーにとって、開梱のコストは重要ではありません
- Cのソース間難読化のための豊富な機能を備えた多様な仮想化/難読化ツールであるTigressをチェックしてください。パフォーマンスを向上させるには、サポートする変換、制御フローのフラット化、関数のマージ/分割、リテラルエンコーディングに依存します
- さらに強力な保護が必要な場合は、仮想化、JITingなどのTigressの主要な変換を確認してください。ただし、これらの変換を使用すると、ユーザーは速度が低下する可能性があります。
ブラックボックスの難読化の不可能性に関するBaraketalの独創的な研究に落胆しないでください。彼はブラックボックス難読化の不可能性を証明するだけであり、多くの実用的で価値のある難読化の不可能性を証明していません。(プログラムの内部動作であるブラックボックスの難読化は完全に理解できません)また、海賊に落胆しないでください。それが良ければあなたの製品を買うことを重要視する人々は常にいます。
最適化コンパイラを使用してCコードをコンパイルすると、元のソースコードや、リモートで類似しているものを復元することができなくなります。最近人気のあるJavaや.NETの難読化ツールよりもはるかに安全です。リリース前に実行可能ファイルを小さくし、シンボル名を非表示にする場合は、必ず実行可能ファイルを削除してください。ただし、これにより(アプリケーションがクラッシュしたときの)デバッグもほとんど不可能になることに注意してください。
それでも、誰かが本当にあなたのソフトウェアをハッキングしたいのなら、彼はアセンブリレベルで、おそらくローダーソフトウェアや他のトリックを使ってそうします-あなたが彼を防ぐために何をしようとしても。多くの企業が試みましたが、成功した企業はありません。このようなハックを使用すると、アプリケーションがクラッシュしたり、Windowsの組み込みデバッガーがクラッシュしたりする可能性があるため、エンドユーザーを苛立たせるだけです。
代わりにプログラムを改善する必要がある間、難読化について考える時間を無駄にするのをやめてください。
それを難しくするには?もちろん。お願い、それはやめて。
それを防ぐために?いいえ。バイナリを実行するシステムには、思いついたスキームを復号化するためのソフトウェアが必要です。そして、彼らはそれを逆コンパイルして、あなたの隠されたバイナリがどのように解釈されるかを見ることができます。
コンパイルされたバイナリについて話す場合、できることはあまりないと思います(おそらく、UPXまたは関連ツールのみを適用します)。これは、元に戻すことができるため、あまり意味がありません。
新しいコードの記述について話す場合は、Self Modyfing Cコードを試してください。これは、アプリケーションを再設計するのにおそらく最も難しい方法です。
「難読化された実行可能ファイル」は意味がありません。ハードウェアは、コードを実行できるようにコードを「理解」できなければなりません。ハードウェアがそれを理解できれば、リバースエンジニアリングの人間もそれを理解できます。あなたができることのほとんどは、理解するのをより面倒にすることですが、おそらくそれほど多くはなく、コストがかかります。
商業的な利益があるのに、なぜコードを難読化するのですか?正直なところ、商用コードが十分に最適化されて難読化されて機能しているとすると、すべての恥ずかしいことの母が起こったと仮定します-グリッチ....本番のバイナリコードが難読化されているため、グリッチが発生していて複製が難しい場所をデバッグすると、バグリストに永久に残ります...
たとえば、スタックトレースを見つけようとすると、より多くの髪の毛を失うことになり、WTFを解決するために分解されたコードを理解しようとすると、スパゲッティループの無限の連なりが発生します。要するに、しないでください!
グリッチをデバッグしようとするとお金を失うことになります...メモリダンプを読み取って難読化されたコードから解決するには、優れたアセンブラの専門家である必要があります...捨てないでください。あなたの美しい製品を動かしてそれを売ってください...確かに、コードをリバースエンジニアリングすることによってそれを壊すために彼らの手に時間を持っているたくさんの人々がいます...
原則に従っている打撃の秘訣-頻繁にリリースし、頻繁にリリースし、頻繁にリリースするにつれて改善を行います。そうすることで、クラッカーが分解するのにかかる時間よりも最新かつ最高の機能がより最新になります。そしてうまくいく!Linuxのソースコードを見てください。パッチが入ってからリリースされます...その原則を念頭に置いて、より多くの機能を備えた新しいバージョンをはるかに速いペースでリリースすることで、勝ちです!
物事を少し難しくする1つの方法は、それらを梱包することです。 UPXはバイナリをパックするため、箱から出して逆コンパイルするのが難しくなります。技術的には、解凍してから逆コンパイルすることは可能ですが、それは少しバーを上げます。バニラユーザーのオペレーティングシステムで実行していると仮定すると、厄介なトリックを使用せずに逆コンパイルを防ぐためにできることはたくさんありません。
あなたが本当にそれを混乱させたいならば、あなたはそれをするために別のプログラムを必要とします。開発者は、最もクリーンで読みやすい形式でコードを記述します。コンパイル後、別のアプリケーションを実行して難読化を行います。このようなアプリケーションは約10万ドルで購入できます。
コードがリバースエンジニアリングされないようにすることが目的の場合は、おそらく機能します。誰かがセキュリティを破るのを阻止することがあなたの意図である場合、難読化だけでは断固とした攻撃者を阻止することはできません。ある時点で、コードを理解してそれを見つけたり、回避したりする必要がないという、はい/いいえの決定があります。
難読化されたコードを生成するように変更された小さなCコンパイラ:http://blogs.conus.info/node/58
ここでの答えに理論的なサポートを提供するために:2001年にBaraket。al。プログラムの難読化は一般的に不可能であることを証明しました。