A certain engineer "COMPLEX"

.NETで難読化を試してみる 第5回

前回の続き。

今回はアゼンブリマージを使った場合、参照アセンブリ一覧にマージしたはずのアセンブリが残っていた問題の打開について検証します。

Explanation

前回は、マージではなく埋め込みという方法でアセンブリの結合行いました。マージと結合は違います。ここ重要。
打開策の説明をする前にお知らせ。
今回の説明に Eazfuscator.NET は使いません。

それは、Eazfuscator.NET は有償化されたため、無償版はこれ以上サポートされないため、無償版は

  • .NET Framework 4.5 はサポートされない
  • XAML 難読化の未サポート
  • 高度な難読化の未サポート

というのが理由です。
公式サイトの購入ページには

Eazfuscator.NET established wide user base while being a freely available product. If you are an existing customer of Eazfuscator.NET, the following fair upgrade rules apply:

All existing customers will get 30% off
People who made donations to Eazfuscator.NET will get 80% off
People who made donations larger than $49 will get Single Developer License for free

訳)
Eazfuscator.NET は、無償利用のプロダクトであった間に、広くユーザーベースに確立しました。もしあなたが Eazfuscator.NET の既存顧客なら、以下の公正なアップグレードルールを適用します
・全ての既存顧客は30%オフ
・Eazfuscator.NET に寄付した人々は80%オフ
・49ドル以上寄付した人々はシングルユーザライセンスの無償で入手

とあります。
30%オフの権利はあるので、399ドルの30%オフで有償版を入手できますが....

これを機に難読化のソフトを見直しました。

今回選んだのは、Babel Obfuscator です。
以前紹介しましたが、GUIが秀逸です。DevExpressのコンポーネントを使っているのか、かっこいいインターフェイスです。

ちなみに、私は気に入りましたので、有償版を購入しました。
執筆時点での最新版は 8.3.0.0 です。

Assembly Merge

実際に使ってみます。
今回のサンプルソースは、GitHub にあります。

前回は、埋め込んだアセンブリに対してまでリフレクションを実行した、つまり既にわかっているアセンブリに対するアセンブリの埋め込みが問題を引き起こしたようです。
なので、今回のサンプルはアセンブリのLoadは実行しません。あくまで、メソッドのリフレクションのみです。

Babel Obfuscator起動後、左側のInputをクリックし、右側にObfuscation5.exeをドラッグアンドドロップします。
次に追加されたObfuscation5.exeの左側にある +マークをクリックし、ノードを展開します。
InputsタブのFileにObfuscation5Lib.dllを追加し、ActionをEmbedに変更します。
そして、左端のチェックボックスにチェックがついていることを確認します。

難読化準備

これで準備は完了です。
一応他のSettingsやOptimzationsから難読化レベルや最適化が選択できますが今回は無視します。
(ちなみに、今回は使いませんが、これらの設定によって、アセンブリマージ後、使っていないPublicクラス等を削除して結合後のアセンブリを小さくできます。)

画面上部の再生マークみたいなボタンを押下します。すると、難読化が始まります。
既定では、最初に追加したアセンブリと同一フォルダに BabelOut というフォルダが作られ、そこに難読化されたアセンブリが追加されるようです。

(1) 実行結果の検証

Before

難読化前

After

難読化後

(2) 逆コンパイラによるソースコード解析

逆コンパイラによるソースコード

どうでしょう?
きちんと参照からdllが消えて、アセンブリが埋め込まれているのがわかります。
デフォルトの設定でも、外部アセンブリでも一部はきちんと難読化されています。

ちなみにマージ後は、exe、dll ともに 5kbだったのが、37kbに増えています。

では、全ての設定を有効にして難読化した場合はどうなるでしょうか?
たぶん、一番気になるところでしょう。

SettingでObfuscation Level という右端のスライダーを一番上に。
OptimizationsでOptimizations Level という右端のスライダーを一番上に。

これで難読化を実行します。

最高レベルで難読化

が、また参照にdllが復活しています。でも実行は上手くいきます。
ひょっとして、難読化の程度によって、こういう風になるのは仕様なのでしょうか?要調査です。
さらに、何故か難読化後、AnyCPU設定が外れてx86になっていました。これバグ?
さらにさらに、最適化はしたけど、ファイルサイズが74kbまでふくれあがっていました。
おそらく、削除したクラスの数よりも、難読化による弊害のが強く影響してしまったためでしょう。

ちなみに、Babel Obfuscatorは難読化後、どの程度難読化が適用されたのかをグラフで見せてくれます。

シンボルのリネーム率

シンボルのリネーム率

シンボルのリネーム率 2

シンボルのリネーム率2

最適化率

最適化率

難読化に要した時間

難読化に要した時間

今回は以上です。次回は...あるのか?

コメントを残す

メールアドレスが公開されることはありません。

%d人のブロガーが「いいね」をつけました。