[解決済み] .NET難読化ツール/戦略 [終了しました]。

質問

私の製品にはいくつかのコンポーネントがあります。ASP.NET、Windows Forms App、Windows Serviceです。コードの95%ほどはVB.NETで書かれています。

知的財産権上の理由から、私はコードを難読化する必要があり、今までは5年以上前のバージョンのdotfuscatorを使用していました。そろそろ新世代のツールに移行する時期だと考えています。私が探しているのは、新しい難読化ツールを探すときに考慮すべき要件のリストです。

今までのところ、何を探せばいいかわかっていること。

• シリアライズ／デシリアライズ . 私の現在のソリューションでは、単純にツールに ではなく というのも、以前にシリアライズされたデータを読み込むことができないという痛みは、単純に大きすぎるからです。
• ビルドプロセスとの統合
• ASP.NETで作業する . 過去には、.dll 名の変更（1 ページに 1 つあることが多い）が原因で問題が発生したことがあり、すべてのツールがうまく処理できるわけではありません。

解決方法は？

.Net 1.1では難読化は必須でした。コードの逆コンパイルは簡単で、アセンブリからIL、C#のコードに移行し、わずかな労力で再コンパイルすることができました。

.Net 3.5では、まったく自信がありません。 3.5のアセンブリをデコンパイルしてみると、コンパイルとは程遠いものが出てきます。

3.5からの最適化（1.1よりはるかに良い）と、匿名型、デリゲートなどがリフレクションで処理される方法（これらは再コンパイルの悪夢です）を追加します。ラムダ式、Linqシンタックスのようなコンパイラの「マジック」、そして var のようなC#2関数があります。 yield (その結果、読めない名前の新しいクラスができる)。デコンパイルされたコードは、コンパイル可能な状態からは程遠い状態になります。

しかし、難読化されたコードにも同じことが言えます。しかし、難読化されたコードも同様です。そこから得られるコードはメンテナンス不能で、非常にバグの多いものになる可能性が高いのです。

私はアセンブリにキー署名をすることをお勧めします（ハッカーが1つを再コンパイルすることができれば、すべてを再コンパイルしなければならないことを意味します）。