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