重複の可能性: .NET の世界での難読化に代わる
.Net 難読化
ほんの数分前に、C# の .exe を VB ソリューションに変換できる無料のツールがいくつかあることを知りました。これは、私の独自のコードを表示、編集、および再コンパイル/再配布できることを意味します。これを防ぐ方法はありますか?
重複の可能性: .NET の世界での難読化に代わる
.Net 難読化
ほんの数分前に、C# の .exe を VB ソリューションに変換できる無料のツールがいくつかあることを知りました。これは、私の独自のコードを表示、編集、および再コンパイル/再配布できることを意味します。これを防ぐ方法はありますか?
つまり、 Obfuscationを使用する必要があります。いくつか挙げると。
コードを難読化する方法に関するアドバイスが記載されているこの MSDNの記事を読むことができます。
mono を使用してネイティブ バイナリにコンパイルできます。Google で検索してください。
機密性の高い関数/コンポーネントをネイティブ C++ にコーディングし、C++/CLI でラップして、.NET アセンブリを難読化するだけでなく、.NET で使用することもできます。
難読化を行っても、JIT コンパイラは最終的に IL コードを確認する必要がありますが、逆コンパイルをより難しくしているだけです。
難読化ツールは、コードを表示、編集、再配布などの労力を増やすため、良い賭けです。
これらはコードを物理的に保護するわけではありませんが、コードを逆コンパイルする動作 (特許、著作権、ライセンスなどの法的メカニズム) を防ぐことができます。
逆コンパイルまたはリバース エンジニアリングは、経済的努力の戦いです。コードを難読化する (潜在的にリフレクションの「落とし穴」に違反する) ことは価値がありますか? 誰かがエミュレートまたは書き換える代わりに (コンテキストがほとんどない) リバース エンジニアリングする価値はありますか?
この回答に対するコメントhttps://stackoverflow.com/a/1988467/64348は、難読化によって元のコード (または元のバージョンに十分近いバージョン) に戻ることを妨げないことを示しています。難読化は、いくつかの有用なコンテキストを除いて、実際のキーを必要としない可逆変換の単なる代用です。