そのため、Dotfuscator (プロ版 - クライアントがライセンスを持っているもの) を介して出力アセンブリを難読化する必要がある、中程度から非常に複雑な WPF アプリケーションがあります。
3 つの問題:
OutOfMemoryException難読化プロセスは、約 85% の確率でクラッシュします。- 長い時間がかかります - 平均的な難読化パスが完了するまでに約56分かかります
- リフレクションベースのルックアップからリソースまで、難読化されたアセンブリでアプリがクラッシュする原因となるさまざまな問題が山ほどあります。
最初の問題は、GUI ではなくコマンド ラインから実行することで軽減できました (少なくともクラッシュしません)。3 つ目は、すばやく反復できればそれほど大きな問題にはなりません。 1 営業日あたり 5 回の試行ではなく、オプションの組み合わせ。
私を殺しているのは本当に合計時間です。難読化にかかる時間を劇的に改善するための「クイックフィックス」のアイデアを知っている人はいますか? 私が行った間抜けなことが、プロセス中にある種の「蒸気ロック」を引き起こし、処理時間を増やしている可能性はありますか? 別の難読化ツールを使用するようにクライアントに圧力をかける必要がありますか?
いくつかの詳細:
- 約。アプリケーション内の 38 個のアセンブリ/exe (そのうち 5 ～ 10 個は「アーティファクト」としてマークされたサード パーティの dll であり、難読化されません)
- ボックスは、VM ではなく、やや強力な物理サーバーです。
- 各アセンブリを個別に処理するのではなく、構成ファイルを使用して難読化ツールを駆動しています。
- 生成されたリソースなどのために、上記の構成ファイルですでにいくつかの除外をマークしました
- すべてのアセンブリは「ライブラリ」としてマークされています
どんな考えや SWAG も大歓迎です。