私の最後の質問から学ぶと、ほとんどのメンバー名はプロジェクトの出力に含まれているようです。
9rays、Salamander、Jungleなどの一部の逆コンパイラを見ると、多くの難読化技術はすでに打ち負かされているように見えますが、特に恐ろしい主張が 1 つあります。
難読化ツールによって挿入された文字列暗号化を自動的に削除します ~ Salamander
それで、手動のソースコードレベルの難読化は、よく知られている（簡単に打ち負かされる??）難読化プログラムによる、コンパイル後/コンパイル中の泡立つ「表面的な」難読化よりも効果的ですか?
ソースコードを難読化することは、メンテナンスの点で自滅的です。
プロジェクトが非常に「秘密」である場合、2 つの選択肢があると思います。
あなたが制御するサーバー上のサービスの背後にある「秘密の」所有権コードを配置します
C/C++ などの逆コンパイルが容易ではない言語でコーディングする
おそらく、議論の余地がありますが、そうすると保守性が損なわれます。
これは本当に価値がありますか？
実際、これはあいまいさによるセキュリティに帰着します。つまり、セキュリティではなく、単に不便です。十分に関心のある関係者がコードにアクセスできれば、コードを逆コンパイルするだろうという前提から作業する必要があります。邪悪な haxxor のために少しでも時間を費やすために、自分自身に課す苦痛に値するものではありません。アクセスの実際のセキュリティ問題に対処します。
人々が述べたように、難読化は水準を上げることです。アセンブリを難読化すると、好奇心旺盛なカジュアルな開発者を止めることができますが、やる気のある人がリバースエンジニアリングを行うのを止めることはできません。
バーをもう少し上げたい場合は、多くの難読化ツールを使用して、印刷できない文字をメンバー名として使用できます。それ自体にリフレクターを使用して見てください。これにより、より多くの人が停止します。難読化されたコードを見て理解できるかもしれませんが、読めない場合は、ILにダンプして、すべてのメンバーの名前を手動で変更するという苦痛を経験することはありません。そんなに時間を無駄にする動機はありません。
ただし、一部の人々には動機があるため、ビジネス要件がそれを必要とする場合は、別のステップに進む必要があります。しかし、コンピュータがそれを読むことができれば、あなたが何をしても、それを読むことができる誰かがそこにいるでしょう。目標は、それを読むことができる、またはそれを読むように動機付けられる人々の数を減らすことです。
リフレクターを壊すために使用できるトリックもいくつかあります（PreEmptiveのObfuscatorがリフレクターを壊す場合もありますが、もちろんILを読み取ることはできます）。難読化ツールの開発者と一度興味深い会話をしましたが、それを正しく行うことはできませんが、彼はコードを動的にジャンプさせることでリフレクターを完全に壊す方法を持っていました。たとえば、関数aのある瞬間、関数bの途中にジャンプします。これを実行すると、PEVerifyでエラーが発生するため、実際に実装されることはありませんが、一種の優れたアイデアです。
あんかたが正しい。実際にできることは、その人がソフトウェアをリバース エンジニアリングするのをより困難にする (そしてコストを高くする) ことだけです。
私の会社では、リバース エンジニアリングを可能な限り困難にしたいいくつかの領域を特定しました。たとえば、ファイルはバイナリ形式であり、階層内の各オブジェクトがそれ自体を保存し、正しいバージョンを読み戻す役割を果たします。これは、人が私たちのファイルを読むために作成したコードで階層全体を複製することを意味します。さらに、ジョブ ファイル内の情報の多くは、ショップ標準ファイル内の対応するビットがなくても役立ちます。そのため、ジョブ ファイルの内容を理解するために、作業を 2 回行う必要があります。
Win32DLL には、いくつかの重要な領域 (ドングル保護、金属切断機との通信) があります。つまり、ソフトウェアをリバース エンジニアリングするために、アセンブリと、他の DLL シグネチャを複製する DLL の作成方法を知っている必要があります。さらに、当社の CAM ソフトウェアを使用した設計は、切断機との対話性が高いことです (情報は常に交換されています)。
競合他社が私たちの機械だけで対処しようとしているという話を数回聞いたときから、彼らは仕事を終わらせるために電子機器を自社のものに交換することになりました. これを行うための大金。
私たちが取ったステップの一部は、競合他社のマシンとソフトウェアに対処しようとした私たち自身の経験に基づいていました. 私たちはその経験を生かし、セットアップを微調整する方法を学びました。もちろん、リバース エンジニアリングを打破するためだけに信頼性やメンテナンスを犠牲にするつもりはないという点で限界があります。
あなたの場合、あなたのソフトウェアのどの部分が競合他社の関心を引くかを自問し、そこから先に進む必要があります。あなたが垂直市場の開発者 (機械制御、専門会計など) である場合は、ソフトウェア制御に USB ドングルを使用することをお勧めします。
それ以外の場合は、シリアル番号システムを使用して、人々があなたのソフトウェアを海賊版にし、それをビジネス モデルに組み込むことを受け入れてください。シリアル番号スキームの目的は、比較的邪魔にならず、因果的なコピーを妨げ、コピーがどこから来たのかを追跡するリモートの機会を与えることです。
コード レベルの難読化を検討していることに驚いています。あなたもコードを難読化しませんか？またどのように取り組むつもりですか？保守性のために、これは行うべきではありません。
しかし、これを考慮してください： -
プロジェクトを開き、プロジェクト内のすべての文字列/変数名を巧妙に難読化する実行可能なスクリプト/アプリがあり、後でそれをコンパイルし、元のコードは別の場所で安全に変更されていないとします。
さて、それはいくつかのアイデアです。
問題は、読みやすさを犠牲にすることです。あなたのプロジェクトを保護することがそれほど神聖なものである場合、次の 2 つのことを想定しても安全だと思います。
実際、コード レベルの難読化は、難読化ツールよりも安全性が低くなります。これは主に、言語コンパイラでは許可されていない厳密な CLI 実装の詳細を難読化ツールが利用できるためです。たとえば、プライベート フィールドをすべて同じ名前にすることは完全に合法ですが、それを可能にするコンパイラはありません。
次のような手法を使用できます。