アプリケーションのライセンス キーの最適な暗号化を調べていたところ、アプリケーションを簡単に逆コンパイルして、ライセンス キーのテストをスキップできると誰かが言っていました。
実際に言えば、誰かがそれをどのように行うのでしょうか? つまり、彼らは私の .dll を持っているので、何らかの形で逆コンパイルし、関数呼び出しをコメントアウトしてライセンスを確認し、再コンパイルする必要がありますか? 逆コンパイラは、コードがまだコンパイルできるように、本当に優れている必要があります!
アプリケーションのライセンス キーの最適な暗号化を調べていたところ、アプリケーションを簡単に逆コンパイルして、ライセンス キーのテストをスキップできると誰かが言っていました。
実際に言えば、誰かがそれをどのように行うのでしょうか? つまり、彼らは私の .dll を持っているので、何らかの形で逆コンパイルし、関数呼び出しをコメントアウトしてライセンスを確認し、再コンパイルする必要がありますか? 逆コンパイラは、コードがまだコンパイルできるように、本当に優れている必要があります!
ソース コードが正常にコンパイルされている場合、.NET アセンブリを逆コンパイルするのは非常に簡単です。
当初は Lutz Roeder によって開発され、現在は Redgate Software によってサポートされている.NET Reflectorを使用できます。この回答の最後にスクリーンショットがあり、Reflector が何をするかの印象を与えます。
名前空間とクラスをブラウズして、お気に入りの .NET 言語でソース コードとメソッドを確認できます。Denis Bauer のFileDisassemblyrを使用すると、あなた (またはあなたの場合は邪悪なハッカー) がそれを VS ソリューションに変換し、プログラムに変更を加えることができます。
コード難読化ツールを使用してコードを実質的に判読不能にするなど、いくつかの対策があります。
このトピックに関する StackOverflow に関するその他の興味深い質問がいくつかあります。
リフレクターのスクリーンショット:
Josh Smith も最近リリースしたCrack.NETを使用して、実行中の .NET プロセスにアタッチし、それをReflectorで開くことができます。ディスク上のアセンブリが何らかの方法で暗号化されている場合でも (Reflector を使用してアクセスすることを避けるため)。 、引き続きメモリ内バージョンを使用できます
これがあなたが防御しようとしているものである場合は、それを攻撃する方法を読みたいと思うかもしれません.
It is best not to go overboard on licence key technology. Whatever you do can be hacked by a determined user and you run the bigger risk of adding issues that stop legitimate users using your application. I have even seen code that was protected with Hasp Dongles get cracked. Encrypting your licence key and obfuscating your code should be enough to hinder opportunist attacks, there is little point going beyond that.
Eric Sink wrote a good article covering this point see section "4. Don't Annoy Honest People" of "Tenets of Transparency"
.NET は非常に簡単に逆コンパイルできます。難読化すると、何が起こっているのかを理解するのが少し難しくなりますが、コードが永続的であれば、コードを逆コンパイルする誰かがそれを理解することができます.
オンラインで見つけた .NET コードの保護に関するアドバイスを次に示します。
http://blogs.msdn.com/ericgu/archive/2004/02/24/79236.aspx
ここで説明する手法はどれも 100% 効果的ではないことに注意してください。クラッカーをどれだけ多くのフープを通過させるかが問題です。
一般に、.NET のコンパイルは非常に簡単です。これを自分で感じるには、.NET Reflectorのコピーを入手して試してみてください。
ほとんどの場合、単純なライセンス チェックを削除するためにコードを再コンパイルする必要はありません。MSILにパッチを適用するだけで問題は解決します。
このシナリオから身を守ると、利益が急速に減少します。コードに追加する追加チェックをバイパスするのに十分なほど賢い人が常に存在します。たとえば、コードにデジタル署名を追加し、一致しない署名の実行を拒否することができます (ライセンス チェックを削除するなど、コードが改ざんされたことを示します)。
その後、ゲームは署名チェックを削除するようになります (ライセンス キー チェックに加えて)。したがって、別のチェックを追加すると、バイパスすることができます。
このような問題からソフトウェアを守るのに役立つ、コードの難読化ツールとコピー防止ツールの業界全体があります。あなたの側の追加の努力と、あなたの正当な顧客に与える迷惑が、これらのソリューションを購入する価値があるかどうかを判断するのはあなた次第です...
"それも"
あらゆる種類の「標準」/通常のライセンス チェック メカニズムは、自動削除ツールのターゲットです。そして、私が熟考したいくつかの商用 .NET アプリでは、これらの「あまりにも些細な」チェックが一般的であるように見えます。
最善の策は、プログラムの一部を Web サービスに依存させることによって保護することです。アプリが頻繁に変更されることに依存しない限り、これらのチャンクはダウンロードされて「クラックされたバージョン」でローカルにキャッシュされる可能性があるため、これは実行速度の低下を避けるためにあまりにもおしゃべりなインターフェイスであってはなりません。
ネットワーク接続を回避したい場合 (一部の用途またはユーザーは、アプリによっては、説明して価値を提供するものでない限り、問題がある/疑わしいと感じる可能性があります)、プログラムの一部をネイティブ dll または 2 つに分割し、ライセンスをチェックインします。アプリのすべての部分であり、ネイティブ dll の場合はそれほど明白ではありませんが、ほとんどの場合、十分に抑止できます。
Reflector がなくても、人々は何年も前からこれを行ってきました。基本的には、デバッガーを使用してアプリを監視し (WinDBG のようなもの)、ライセンス チェックがいつ行われるかを確認します。戻り値を監視し、アプリケーションにパッチを適用して、「すべて正常」チェックに直接ジャンプするだけです。
人々が上に投稿したものすべてをお勧めします。これはいたちごっこゲームであり、投資収益率に見合うだけの価値があることを認識する必要があります。システムを操作しようとしないユーザーがいる場合は、単純な方法で十分です。クラッキングが蔓延している何かがある場合は、別の戦略を検討してそこから進む必要があります。
パッチを適用するためにアプリケーションを再コンパイルする必要はありません。多くのバイナリ パッチ ツールが存在します。そして、稼ぐのに十分なお金がある場合、それはあなたの最も決定的なクラッカーを止めることはありません.