リフレクションに使用されるコードの例を次に示します。
var i = typeof(Program).Assembly.CreateInstance("test.Program");
ソフトウェアが難読化されると、コードは明らかに機能しなくなります。
難読化が行われた後も変更されないクラスのプロパティを検索することで、それを回避する方法を見つけようとしています。type.GUIDで試してみましたが、デバッグバージョンを実行すると1つのGUIDが取得され、難読化が完了した後のリリースでは、GUIDが変更されます。
難読化にEazfuscator.NETを使用しています。
可能であれば、クラス/メソッドをマークするために属性を使用することは避けたいと思います。
何がうまくいくかについてのアイデアはありますか？
すべてのタイプを繰り返し処理して探しているものを見つける方法はあると思いますが、頭に浮かぶことはすべて、これまでで最も保守しにくいコードを生成することになるでしょう。
一部の難読化ツール（DeepSeaを使用していますが、Eazfuscatorはわかりません）では、特定のクラスの難読化を防ぎ、それらを反映することができます。DeepSeaの場合、これは属性によって示されますが、それらは最終的なアセンブリに到達しません/すべきではありません（私は：oをチェックしたことはありません）。
リフレクションを「アセンブリを見る外部プロセス」と見なし、「外部プロセスがアセンブリを見るのを防ぐ」ことを難読化すると、自分がやりたいことをやめていることになります。
難読化ツールが攻撃者を打ち負かしてほしくない。コードを理解する仕事をもっと難しくしてください。そして、私はこれを高度な著作権侵害保護の一部として望んでいます
難読化後; アセンブリを圧縮して暗号化し、必要な処理を実行します。次に、別のラッパープロジェクトを作成し、アセンブリをリソースとしてそのプロジェクトに追加します。（新しいプロジェクトの）イベントにアタッチしAppDomain.CurrentDomain.AssemblyResolve、未解決のアセンブリイベントが発生するたびに、リソース（復号化、解凍など）を読み取り、実際のアセンブリを返します。
最終的なラッパーアプリケーションを難読化することもできます。
どのくらい安全ですか？少なくとも、攻撃者の生活をより困難にすることができます。
正確な答えはありませんが、ILSpyのソースが役立つかもしれません。