実行可能ファイルをリバースエンジニアリングから保護しますか？
私は、C/C++コードを逆アセンブリおよびリバースエンジニアリングから保護する方法を検討してきました。通常、私は自分のコードでこの動作を決して容認しません。しかし、私が取り組んでいる現在のプロトコルは、さまざまな人々のセキュリティのために、検査したり理解したりしてはなりません。
今、これは私にとって新しいテーマであり、インターネットはリバースエンジニアリングに対する予防に対して本当に機知に富んでいるのではなく、むしろリバースエンジニアリングの方法に関する多くの情報を示しています
私がこれまで考えてきたことのいくつかは次のとおりです。
- コード挿入（実際の関数呼び出しの前後にダミー関数を呼び出す）
- コードの難読化（バイナリの逆アセンブリを破壊します）
独自のスタートアップルーチンを作成する（デバッガーがバインドしにくい）
void startup(); int _start() { startup( ); exit (0) } void startup() { /* code here */ }デバッガーのランタイムチェック（および検出された場合は強制終了）
機能トランポリン
void trampoline(void (*fnptr)(), bool ping = false) { if(ping) fnptr(); else trampoline(fnptr, true); }無意味な割り振りと割り振り解除（スタックの大幅な変更）
- 無意味なダミー呼び出しとトランポリン（逆アセンブリ出力のジャンプのトン）
- 大量の鋳造（難読化された分解用）
これらは私が考えていたもののいくつかですが、適切な時間枠が与えられれば、コードアナリストが回避したり把握したりすることができます。私が持っている他の選択肢はありますか？
アンバーが言ったことはまさに正しい。リバースエンジニアリングを難しくすることはできますが、それを防ぐことはできません。 リバースエンジニアリングの防止に依存する「セキュリティ」 を信頼しないでください。
とはいえ、私が見た中で最も優れたリバースエンジニアリング技術は、コードを難読化することではなく、コードがどのように機能するかを理解するために通常使用するツールを破壊することに焦点を当てています。逆アセンブラー、デバッガーなどを破壊する創造的な方法を見つけることは、恐ろしいスパゲッティコードを大量に生成するよりも効果的であり、知的に満足できる可能性があります。これは決意した攻撃者をブロックするものではありませんが、Jランダムクラッカーが迷い出て、より簡単なものに取り組む可能性を高めます。
しかし、それらはすべて適切な時間枠が与えられたコード分析者によって回避および/または把握することができます。
実行可能なプログラムを提供すると、十分な時間を与えてリバースエンジニアリングすることもできます。それがプログラムの性質です。バイナリを解読したい人がすぐに利用できるようになると、最終的なリバースエンジニアリングを防ぐことはできません。結局のところ、コンピューターはそれを実行するために解読できる必要があり、人間は単に遅いコンピューターです。
Safe Net Sentinel （以前のアラジン）。ただし、APIがひどく、ドキュメントがひどく、どちらもSDKツールと比較すると優れています。
私は彼らのハードウェア保護方法（ Sentinel HASP HL ）を長年使用してきました。ソフトウェアの「ライセンス」として機能する独自のUSBキーフォブが必要です。 SDKは、実行可能ファイルとライブラリを暗号化および難読化し、アプリケーションのさまざまな機能をキーに焼き付けられた機能に関連付けることができます。ライセンサーによって提供およびアクティブ化されたUSBキーがないと、ソフトウェアは復号化できないため、実行されません。キーは、カスタマイズされたUSB通信プロトコル（私の知識の範囲外、私はデバイスドライバーの男ではありません）を使用して、仮想キーの構築、またはランタイムラッパーとキー間の通信の改ざんを困難にします。彼らのSDKは開発者にとってあまりフレンドリーではなく、追加の保護を自動化されたビルドプロセスと統合するのは非常に苦痛です（しかし可能です）。
HASP HL保護を実装する前に、製品からdotfuscatorの「保護」を剥奪した7人の既知の海賊がいました。 HASP保護をソフトウェアのメジャーアップデートと同時に追加しました。このアップデートでは、ビデオに対してリアルタイムで重い計算を実行します。プロファイリングとベンチマークからわかるように、HASP HL保護は集中的な計算を約3％だけ遅くしました。そのソフトウェアは約5年前にリリースされて以来、この製品の新しい海賊は1人も見つかりませんでした。保護するソフトウェアは、その市場セグメントで高い需要があり、クライアントは、リバースエンジニアリングを積極的に試みているいくつかの競合他社を認識しています（これまでのところ成功していません）。さまざまなニュースグループやフォーラムに多数の投稿が保護された製品の新しいバージョンを含んでいるので、彼らはソフトウェア保護を破るサービスを宣伝するロシアのいくつかのグループから助けを求めようとしたことを知っています。
最近、私たちは小規模なプロジェクトでソフトウェアライセンスソリューション（HASP SL）を試してみました。これは、既にHL製品に精通していれば作業を始めるのに十分なほど簡単でした。動作しているようです。著作権侵害の事例は報告されていませんが、この製品の需要ははるかに低くなっています。
もちろん、完璧な保護はありません。誰かが十分に動機付けられ、燃やすために深刻な現金を持っている場合、HASPによって提供される保護は回避されると確信しています。
たとえば、 AESアルゴリズム を使用します。これは非常に公開されたアルゴリズムであり、非常に安全です。どうして？ 2つの理由：多くの賢い人々によってレビューされており、「秘密」の部分はアルゴリズム自体ではありません-秘密の部分はアルゴリズムへの入力の1つであるキーです。コード自体を秘密にするのではなく、コードの外部に生成された「秘密」を使用してプロトコルを設計する方がはるかに優れたアプローチです。コードは、何をしようとも常に解釈できます。また、（理想的には）生成されたシークレットは、大規模なブルートフォースアプローチまたは盗難によってのみ危険にさらされる可能性があります。
興味深い質問は、「なぜコードを難読化するのですか？」攻撃者がアルゴリズムを解読するのを困難にしたいですか？コード内の悪用可能なバグを見つけにくくするために？そもそもコードが解読不能であれば、コードを難読化する必要はありません。問題の根本は、クラック可能なソフトウェアです。問題の根本を修正してください。単に難読化しないでください。
また、コードを混乱させるほど、セキュリティバグを見つけるのが難しくなります。はい、ハッカーにとっては難しいでしょうが、バグも見つける必要があります。コードは今から何年も維持しやすいはずです。また、明確に書かれた明確なコードでさえも維持するのは難しいでしょう。悪化させないでください。
特に可変ワード長の命令セットでの最良の逆アセンブラーのトリックは、Cではなくアセンブラー/マシンコードにあります。たとえば、
CLC
BCC over
.byte 0x09
over:
逆アセンブラは、分岐先がマルチバイト命令の2番目のバイトであるという問題を解決する必要があります。ただし、命令セットシミュレータには問題はありません。 Cから発生する可能性のある計算されたアドレスへの分岐も、逆アセンブリを困難から不可能にします。命令セットシミュレータには問題ありません。シミュレータを使用して分岐先を整理すると、分解プロセスを支援できます。コンパイルされたコードは比較的きれいで、逆アセンブラーにとって簡単です。だから、いくつかのアセンブリが必要だと思います。
私は、Michael AbrashのZen of Assembly Languageの始まりに近づいたと思います。彼は、単純なアンチ逆アセンブラーとアンチデバッガーのトリックを示しました。 8088/6にはプリフェッチキューがありましたが、次の命令を変更する命令または数個先の命令がありました。シングルステップの場合、変更された命令を実行し、命令セットシミュレーターがハードウェアを完全にシミュレートしなかった場合、変更された命令を実行しました。通常実行されている実際のハードウェアでは、実際の命令は既にキューにあり、変更されたメモリ位置は、その命令の文字列を再度実行しなかった限り、損害を引き起こしません。パイプラインプロセッサが次の命令をフェッチするため、おそらく今日でもこのようなトリックを使用できます。または、ハードウェアに個別の命令およびデータキャッシュがあることがわかっている場合、キャッシュラインでこのコードを適切に調整すると、先のバイト数を変更できます。変更されたバイトは、命令キャッシュではなくデータキャッシュを通じて書き込まれます。適切なキャッシュシミュレーターを持たない命令セットシミュレーターは、適切に実行できません。ソフトウェアのみのソリューションは、あなたをあまり遠くまで連れて行かないと思います。
上記は古く、よく知られていますが、現在のツールについて既に十分に知りません。自己修正コードはデバッガーをトリップさせる可能性がありますが、人間は問題を絞り込んで、自己修正コードを確認して回避することができます。
これまでは、ハッカーが何かを解決するのに約18か月かかることがありました（DVDなど）。現在、彼らは平均して約2日から2週間です（やる気がある場合）（ブルーレイ、iphoneなど）。つまり、セキュリティに数日以上費やしている場合、時間を無駄にしている可能性があります。唯一の本当のセキュリティはハードウェアを介して得られます（たとえば、命令は暗号化され、チップ内のプロセッサコアのみが実行直前に復号化され、復号化された命令を公開できません）。それはあなたを数日ではなく数ヶ月買うかもしれません。
また、Kevin Mitnickの本The Art of Deceptionを読んでください。そのような人は電話を取り、あなたまたは同僚に、会社の別の部分のマネージャーまたは別の同僚またはハードウェアエンジニアであると考えて、システムに秘密を渡すことができます。そして、あなたのセキュリティは吹き飛ばされます。セキュリティはテクノロジーの管理だけではありません。人間も管理する必要があります。
コードのリバースエンジニアリングを困難にすることをコード難読化と呼びます。
あなたが言及するテクニックのほとんどは、かなり簡単に回避できます。彼らはいくつかの役に立たないコードを追加することに集中しています。しかし、役に立たないコードは簡単に検出して削除できるため、クリーンなプログラムが残ります。
効果的な難読化のために、プログラムの動作を実行中の無駄なビットに依存させる必要があります。たとえば、これを行うのではなく：
a = useless_computation();
a = 42;
これを行う：
a = complicated_computation_that_uses_many_inputs_but_always_returns_42();
または、これを行う代わりに：
if (running_under_a_debugger()) abort();
a = 42;
これを行います（running_under_a_debuggerは、コードがデバッガーで実行されているかどうかをテストする関数として簡単に識別できないようにする必要があります—有用な計算とデバッガー検出を組み合わせる必要があります）。
a = 42 - running_under_a_debugger();
効果的な難読化は、コンパイル段階で純粋にできることではありません。コンパイラーができることは何でも、逆コンパイラーができます。確かに、逆コンパイラの負担を増やすことはできますが、それは遠くまでは行かないでしょう。効果的な難読化手法は、存在する限り、1日目から難読化されたソースを作成することを伴います。コードを自己修正します。多数の入力から派生した計算されたジャンプでコードを散らかします。たとえば、単純な呼び出しの代わりに
some_function();
some_data_structureのビットの予想される正確なレイアウトを知っている場所でこれを行います：
goto (md5sum(&some_data_structure, 42) & 0xffffffff) + MAGIC_CONSTANT;
難読化を真剣に考えている場合は、計画に数か月を追加します。難読化は安くなりません。そして、人々があなたのコードをリバースエンジニアリングすることを避けるための最良の方法は、彼らが気にしないようにそれを役に立たなくすることであると考えてください。これは単純な経済的考慮事項です。コストよりも価値が高い場合、リバースエンジニアリングされます。コストを上げるとコストも大幅に上昇するので、値を下げてみてください。
難読化は難しく高価であると言ったので、教えますとにかく。あなたが書く
私が取り組んでいる現在のプロトコルは、さまざまな人々のセキュリティのために、検査したり理解したりしてはいけません
それは赤旗を上げます。それは 隠蔽によるセキュリティ で、非常に悪い記録を持っています。プロトコルのセキュリティがプロトコルを知らない人に依存している場合、 すでに失っている 。
推奨読書：
- セキュリティ聖書： Security Engineering by Ross Anderson
- 難読化聖書： Sureptitious software by Christian Collberg and Jasvir Nagra
多くの場合、製品がリバースエンジニアリングされるのではないかという恐れが見当違いです。はい、リバースエンジニアリングが可能です。しかし、ハッカーは短期間に非常に有名になるので、ハッカーはenggを逆転する価値があると思うでしょうか？（この仕事はコードのかなりの行にとって、短時間の活動ではありません）。
それが本当にお金を稼ぐ人になったら、特許や著作権のような法的方法を使ってそれを保護するのに十分なお金を集めたはずです。
私見、あなたが取ろうとしている基本的な予防策を取り、それを解放します。それがリバースエンジニアリングのポイントになり、本当に良い仕事をしたということなら、あなた自身がそれを克服するより良い方法を見つけるでしょう。幸運を。
http://en.wikipedia.org/wiki/Security_by_obscurity#Arguments_against を読んでください。他の人もおそらく、不明瞭によるセキュリティが悪いことのより良い情報源を提供できると確信しています。
最新の暗号化技術を使用して、システムをオープンにすることは完全に可能であるべきです（shouldオープンであると言っているわけではありません）暗号化アルゴリズムに穴が開いていない限り（完全なセキュリティを選択する可能性は低い）、秘密キー/パスワードは秘密のままであり、セキュリティホールはありませんあなたのコードで（thisはあなたが心配すべきことです）。
2013年7月以降、暗号的に堅牢な難読化（識別不能難読化の形式）に対する新たな関心があり、これは Amit Sahai 。
- Sahai、Garg、Gentry、Halevi、Raykova、Waters、- すべての回線の識別不能性の難読化と機能暗号化の候補 （2013年7月21日）。
- Sahai、Waters、 区別できない難読化の使用方法：拒否可能な暗号化など 。
- Sahai、Barak、Garg、Kalai、Paneth、 代数攻撃に対する難読化の保護 （2014年2月4日）。
この Quanta Magazineの記事 と、その中の IEEE Spectrumの記事 にいくつかの詳細な情報があります。
現在、この手法を利用するために必要なリソースの量は非実用的ですが、AFAICTのコンセンサスは将来についてかなり楽観的です。
私はこれを非常にさりげなく言いますが、難読化技術を本能的に却下することに慣れているすべての人に-これは異なります。難読化だけではありません。
自分自身に知らせるには、コードの難読化に関する学術文献を読んでください。アリゾナ大学のクリスチャンコルバーグは、この分野の評判の高い学者です。ハーバード大学のサリル・バダンもいくつか良い仕事をしました。
私はこの文献に遅れをとっていますが、私が知っている本質的な考え方は、攻撃者が実行するコードを見るのを防ぐことはできませんが、notを実行します。コードのどのフラグメントが実行され、どのフラグメントが実行されないかを発見するには、攻撃者の指数関数的な時間（最もよく知られた手法を使用）がかかります。
「 プログラムの難読化とワンタイムプログラム 」という最近の論文があります。アプリケーションの保護に真剣に取り組んでいる場合。一般に、この論文は、単純で汎用的なハードウェアを使用することによる理論的な不可能性の結果を取り上げています。
追加のハードウェアを必要とする余裕がない場合は、同じ機能と同じサイズのすべてのプログラムの中で、理論的に最も可能性のある難読化 " On-best-possible obfuscation "を提供する別の論文もあります。しかし、この論文は、情報理論的に最良の可能性が多項式階層の崩壊を意味することを示しています。
これらの論文は、これらの結果があなたのニーズに合わない場合、少なくとも関連文献を読むのに十分な書誌情報を提供する必要があります。
更新：区別できない難読化と呼ばれる難読化の新しい概念は、不可能性の結果を緩和することができます （paper）
誰かがあなたのバイナリをリバースするために時間を費やしたいなら、それらを止めるためにあなたができることは絶対にありません。適度に難しい場合は作成できますが、それだけです。これについて本当に知りたい場合は、 http://www.hex-rays.com/idapro/ のコピーを入手し、いくつかのバイナリを逆アセンブルしてください。
CPUがコードを実行する必要があるという事実は、元に戻すことです。 CPUはマシンコードのみを実行し、プログラマはマシンコードを読み取ることができます。
そうは言っても...別の方法で解決できる別の問題がある可能性があります。何を保護しようとしていますか？問題に応じて、暗号化を使用して製品を保護できます。
適切なオプションを選択できるようにするには、次の側面を考慮する必要があります。
- 「新しいユーザー」は支払いをしたくはないが、あなたのソフトウェアを使用したいのでしょうか？
- 既存の顧客が持っているよりも多くのライセンスを必要とする可能性はありますか？
- 潜在的なユーザーはいくら支払うつもりですか？
- ユーザー/同時ユーザー/ワークステーション/会社ごとにライセンスを付与しますか？
- ソフトウェアを使用するには、トレーニング/カスタマイズが必要ですか？
質問5の答えが「はい」であれば、違法コピーについて心配する必要はありません。とにかくそれらは役に立ちません。
質問1の答えが「はい」の場合、まず価格設定について考えます（質問3を参照）。
質問2に「はい」と答えた場合、「使用ごとに支払う」モデルが適切かもしれません。
私の経験から言うと、従量課金制+カスタマイズとトレーニングは、ソフトウェアにとって最高の保護です。
- 新規ユーザーは価格設定モデルに惹かれます（少しの使用->少しの支払い）
- トレーニングとカスタマイズが必要なため、「匿名ユーザー」はほとんどいません。
- 潜在的な顧客を脅かすソフトウェアの制限はありません。
- 既存の顧客からは継続的にお金が流れています。
- 長期的なビジネス関係により、顧客から開発に関する貴重なフィードバックを得ることができます。
DRMまたは難読化の導入を検討する前に、これらの点を考慮し、それらがソフトウェアに適用可能かどうかを検討することができます。
サイコロはありません。逆アセンブルからコードを保護することはできません。できることは、ビジネスロジック用にサーバーをセットアップし、Webサービスを使用してアプリに提供することです。もちろん、このシナリオは常に可能とは限りません。
どのコードもハッキングできないとは思いませんが、誰かがそれを試してみたいと思うためには、報酬が大きい必要があります。
次のようなあなたがすべきことがあると言った：
- 可能な限り最高の最適化レベルを使用します（リバースエンジニアリングは、アセンブリシーケンスを取得するだけでなく、コードを理解し、Cなどの高レベル言語に移植することでもあります）。高度に最適化されたコードは、b --- hに従うことができます。
- 必要以上のデータ型を持たないようにして、構造を密にします。公式コードリリース間で構造体メンバーを再配置します。構造内の再配置されたビットフィールドも使用できます。
- 変更すべきではない特定の値の存在を確認できます（著作権メッセージは一例です）。バイトベクトルに「vwxyz」が含まれている場合は、「abcde」を含む別のバイトベクトルを作成して、違いを比較できます。それを行う関数には、ベクトルへのポインターを渡してはいけませんが、他のモジュールで（擬似Cコード） "char * p1 =＆string1 [539];"として定義されている外部ポインターを使用してください。そして、「char p2 =＆string2 [-11731];」。この方法では、2つの文字列を正確に指すポインターはありません。比較コードでは、「（p1-539 + i）-*（p2 + 11731 + i）==値」。クラッカーはstring1を変更しても安全だと思うでしょう。予期しない場所でテストを埋めます。
アセンブリコードを自分でハックして、何が簡単で何が難しいかを確認してください。コードをリバースエンジニアリングするのをより困難にし、デバッグをより困難にするために、実験できるアイデアが浮かび上がるはずです。
多くの人がすでに言っているように、通常のCPUでは、実行を止めることはできず、単に遅らせることができます。私の古い暗号の先生が私に言ったように：あなたは完璧な暗号化を必要としない、コードを壊すことは単に利益よりも高価でなければならない。難読化についても同様です。
ただし、3つの追加の注意事項：
BUT（これは非常に大きいですが）リバースエンジニアリングを不可能にすることは可能ですが、従来のCPUではできません。また、多くのハードウェア開発を行い、多くの場合FPGAが使用されます。例えば。 Virtex 5 FXにはPowerPC CPUが搭載されており、APUを使用してハードウェアに独自のCPUオペコードを実装できます。この機能を使用して、外部または他のソフトウェアからアクセスできないPowerPCの機能を実際に復号化するか、ハードウェアでコマンドを実行することもできます。 FPGAにはコンフィギュレーションビットストリームにAES暗号化が組み込まれているため、リバースエンジニアリングできません（誰かがAESを破ることができた場合を除き、他の問題があると思います...）。これにより、ハードウェアIPのベンダーも作業を保護できます。
プロトコルから話します。どんな種類のプロトコルかは言うまでもありませんが、ネットワークプロトコルの場合は、少なくともネットワークスニッフィングから保護する必要があります。これは確かに暗号化によってできます。しかし、ソフトウェアの所有者から暗号化/復号化を保護したい場合は、難読化に戻ります。
プログラムをデバッグ不能/実行不能にしないでください。デバッグのある種の検出を使用して、それを適用してみてください。いくつかの式では、デバッグレジスタの内容をマジック定数に追加します。あなたのプログラムがデバッグモードで見ている場合、それが正常に動作している場合ははるかに難しいですが、完全に間違った計算、操作、または他の何かを行います。例えば。私はいくつかのエコゲームを知っており、それは本当に厄介なコピー保護を持っています（コピー保護が必要ないことは知っていますが、似ています）：盗まれたバージョンはゲームプレイの30分後に採掘されたリソースを変更し、突然あなたはただ1つのリソースを得ました。海賊はちょうどそれをクラックしました（すなわち、リバースエンジニアリングしました）-実行されたかどうかを確認し、voliaがそれをリリースしました。このようなわずかな動作の変化は、特に検出が非常に困難です。それらが検出に即座に現れず、遅延するだけである場合。
だから最後に私は提案します：あなたのソフトウェアをリバースエンジニアリングする人々の利益を推定し、これをある程度の時間に変換し（例えば、最も安いインドの給与を使用することによって）、リバースエンジニアリングを大きくして時間をかけます。
おそらくあなたの最良の代替手段はまだ仮想化を使用することであり、これはバイパスに必要な別のレベルの間接化/難読化をもたらしますが、SSpokeが answer で述べたように、この手法も100％安全ではありません。
重要なのは、そのようなものは存在しないため、究極の保護は得られないということです。もしあれば、それは長続きしないので、そもそも究極の保護ではなかったということです。
どんな人が組み立てても、分解することができます。
通常、（適切な）分解はしばしば（少しまたはそれ以上）難しい作業であるため、opponentはより熟練しているが、そのような質の人が常にいると仮定することができ、それは安全な賭けだ。
REに対して何かを保護したい場合は、少なくともREで使用される一般的な手法を知っている必要があります。
したがって、言葉
インターネットはリバースエンジニアリングの防止に実際には役立ちませんが、リバースエンジニアリングの方法に関する大量の情報を示しています
あなたの悪い態度を示します。保護を使用または埋め込むには、それを破る方法を知っている必要があると言っているわけではありませんが、賢明に使用するには、その弱点と落とし穴を知っている必要があります。あなたはそれを理解する必要があります。
（保護を誤った方法で使用するソフトウェアの例があり、そのような保護は事実上存在しません。漠然と話すことを避けるために、インターネットで簡単に説明する例を挙げます：CD-ROM v4のOxford English Dictionary Second Edition。次のページでのSecuROMの使用の失敗： Oxford English Dictionary（OED）on CD-ROM on 16-、32-、or 64-bit Windows environment：Hard-disk installation、bugs、Word processing macros、networking 、フォントなど ）
すべてに時間がかかります。
あなたが主題に不慣れであり、REのものにきちんと入る月またはむしろ年を持っていないならば、そして、他によって作られた利用可能なソリューションで行ってください。ここでの問題は明らかであり、すでに存在しているため、100％安全ではないことは既にわかっていますが、独自の新しい保護を作成しても、保護されているという誤った感覚しか得られません。リバースエンジニアリングと保護（ただし、少なくとも現時点ではサポートしていません）。
ソフトウェア保護のポイントは、初心者を怖がらせ、一般的なREを失速させ、アプリケーションの中心への（できれば興味深い）旅の後、ベテランREの顔に笑顔を置くことです
ビジネストークでは、可能な限り競争を遅らせることについてすべて言うことができます。
（ニースのプレゼンテーションをご覧ください Skyverのシルバーニードル Black Hat 2006で紹介されたPhilippe BiondiとFabrice Desclauxによる）。
あなたはREについて多くのものがあることを知っているので、それを読み始めてください。 :)
仮想化について述べたので、 EXETOOLS FORUM ： 最高のソフトウェアプロテクター：ThemidaまたはEnigma Protector？ から1つのスレッド例へのリンクを提供します。さらに検索する際に少し役立つかもしれません。
仮想マシンの保護されたコードは、最初はリバースエンジニアリングが不可能と思われました。 Themida Packer
しかし、もはや安全ではありません。そして、コードをどのようにパックしても、ロードされた実行可能ファイルのメモリダンプをいつでも実行し、IDA Proのような逆アセンブラで逆アセンブルできます。
IDA Proには、Cソースコードトランスフォーマーへの気の利いたアセンブリコードも付属していますが、生成されたコードはポインター/アドレスの数学的な混乱のように見えます。オリジナルと比較すると、すべてのエラーを修正して何かをリッピングできます.
リバースエンジニアリングを回避するには、ユーザーにコードを提供しないでください。そうは言っても、オンラインアプリケーションを使用することをお勧めします。
従来のリバースエンジニアリング手法は、逆アセンブラを使用してスマートエージェントがコードに関する質問に答える能力に依存しています。強力な安全性が必要な場合は、エージェントがそのような回答を得ることを証明することを証明することを行う必要があります。
一般に解決できない停止プログラム（「プログラムXは停止しますか？」）に依存することで、これを行うことができます。推論するのが難しいプログラムをプログラムに追加すると、プログラムの推論が難しくなります。そのようなプログラムを作成する方が、それらをバラバラにするよりも簡単です。推論の難易度が異なるプログラムにコードを追加することもできます。優れた候補は、エイリアス（「ポインター」）を推論するプログラムです。
Collbergらは、これらのトピックについて議論し、コードについて推論するのを非常に難しくする可能性のあるさまざまな「不透明な」述語を定義する論文（「Manufacturing Cheap、Resilient and Stealthy Opaque Constructs」）を持っています。
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.1946&rep=rep1&type=pdf
私は、特にCやC++のソースコードではなく、Collbergの特定のメソッドが製品コードに適用されるのを見たことはありません。
DashO Java難読化ツールも同様のアイデアを使用しているようです。 http://www.cs.arizona.edu/~collberg/Teaching/620/2008/Assignments/tools/DashO/
あいまいさによるセキュリティは、私たちの両方よりも賢い人々によって実証されているように機能しません。顧客の通信プロトコルを保護する必要がある場合、道徳的に、オープンで専門家によって完全に精査された最高のコードを使用する必要があります。
これは、人々がコードを検査できる状況のためです。アプリケーションを組み込みマイクロプロセッサで実行する場合は、シーリング機能を備えたものを選択できます。これにより、実行中にコードを検査したり、現在の使用状況などの些細なパラメータを監視したりできなくなります。 （ハードウェア侵入技術を除き、チップを慎重に解体し、高度な機器を使用して個々のトランジスタの電流を検査します。）
私は、x86のリバースエンジニアリングアセンブラーの作成者です。冷静な驚きの準備ができているなら、あなたの最善の努力の結果を私に送ってください。 （私のウェブサイトを通して私に連絡してください。）私が答えで見た少数は私に実質的なハードルを提示するでしょう。高度なリバースエンジニアリングコードがどのように機能するかを確認するには、リバースエンジニアリングの課題があるWebサイトを実際に調査する必要があります。
あなたの質問には明確化が必要かもしれません。コンピューターコードがリバースエンジニアリングに適している場合、どのようにプロトコルを秘密にしておくと思いますか？私のプロトコルがRSA暗号化メッセージ（公開鍵も含む）を送信する場合、プロトコルを秘密にしておくと何が得られますか？すべての実用的な目的のために、検査官は一連のランダムビットに直面するでしょう。
グロチェス・アルバート
ほとんどの人が言うことに反して、彼らの直感と個人的な経験に基づいて、暗号的に安全なプログラムの難読化は一般的に不可能であると証明されているとは思いません。
これは、私のポイントを示すための完全に難読化されたプログラムステートメントの1つの例です。
printf("1677741794\n");
それが実際に何をするのかは決して推測できない
printf("%d\n", 0xBAADF00D ^ 0xDEADBEEF);
このテーマに関する興味深い論文があり、それはいくつかの不可能な結果を証明しています。これは 「プログラムの難読化の可能性について」 と呼ばれます。
この論文は、プログラムを実装する機能と区別できないようにする難読化が不可能であることを証明していますが、もっと弱い方法で定義された難読化はまだ可能かもしれません！
CodeMorthを試してみましたか： http://www.sourceformat.com/code-obfuscator.htm ？またはThemida： http://www.oreans.com/themida_features.php ？
後のものはより有望に見えます。
最初にコードを隠すことを忘れないでください：すべてのコードを非表示にする必要はありません。
最終目標：ほとんどのソフトウェアプログラムの最終目標は、プログラム内の特定の機能を有効または無効にするさまざまなライセンスを販売する能力です。
BEST TECHNIQUE：WordPressオファーのようなフックとフィルターのシステムを構築することは、相手を混乱させようとする場合の絶対的な最良の方法であることがわかります。これにより、実際にコードを暗号化せずに特定のトリガーの関連付けを暗号化できます。
これを行う理由は、可能な限り最小限のコードを暗号化する必要があるためです。
クラッカーを知る：これを知っている：コードをクラックする主な理由は、ライセンスの悪意のある配布のためではなく、実際にはコードを変更する必要があり、実際には無料コピーを配布する必要がないためです。
GETTING STARTED：暗号化する少量のコードは別として、残りのコードは1つのファイルに詰め込み、複雑さと理解を高めます。
暗号化への準備：システムでレイヤーを暗号化することになります。また、非常に複雑な手順になるため、暗号化プロセスを担当する別のプログラムを作成します。
STEP ONE：すべてにbase64名を使用して難読化します。完了したら、難読化されたコードをbase64で一時ファイルに保存し、後でこのコードを復号化して実行するために使用します。理にかなっていますか？
あなたがこれを何度も繰り返しているので、繰り返します。 base64文字列を作成し、それを変数として別のファイルに保存して、復号化およびレンダリングします。
STEP TWO：この一時ファイルを文字列として読み取り、難読化してから、base64で2番目の一時ファイルに保存します。ユーザー。
STEP THREE：ステップ2を必要な回数繰り返します。復号化エラーなしでこれが正常に機能するようになったら、対戦相手のために地雷の構築を開始したいと思うでしょう。
LAND MINE ONE：絶対的な秘密が通知されているという事実を保持したいと思うでしょう。したがって、レイヤー2のクラッカー試行セキュリティ警告メールシステムを構築します。これは、何か問題が発生した場合に相手の詳細を知らせるために起動されます。
LAND MINE TWO：依存関係。レイヤー3、4、5、または実際に設計されたプログラムがなくても、対戦相手がレイヤー1を実行できないようにする必要があります。そのため、レイヤー1には、プログラムが存在しない場合にアクティブになるキルスクリプトまたは他のレイヤーを含めるようにしてください。
私はあなたがあなた自身の地雷だと思いつくことができると確信しています、それを楽しんでください。
覚えておくべきこと：base64する代わりに、実際にコードを暗号化できます。そうすれば、単純なbase64はプログラムを解読しません。
報酬：これは実際にあなたとあなたの相手の間の共生関係になり得ることに留意してください。私はいつもレイヤー1の中にコメントを入れます。コメントはクラッカーを祝福し、あなたから現金報酬を受け取るために使用するプロモーションコードを提供します。
偏見を伴うことなく、現金の報酬を大きくします。私は通常500ドルのようなものを言います。あなたの男がコードを解読する最初の人なら、彼にお金を支払い、彼の友達になります。彼があなたの友人なら、あなたのソフトウェアを配布するつもりはありません。彼にそれをどうやってやったのか、どうやって改善できるのかを彼に聞いてください！
幸運を！