MSBuild タスク
Babel の MSBuild タスクは Babel Obfuscator のどのライセンスエディションでも利用できます。MSBuild プロジェクトで使用するには、「Babel.Build.dll」ファイルを指定した UsingTask 要素で宣言します。
<UsingTask TaskName="Babel" AssemblyFile="C:\Program Files\Babel\MSBuild\Babel.Build.dll" />「Babel.Build.dll」は、インストール先の MSBuild フォルダーにあります。
| インストール方法 | フォルダー |
|---|---|
| Windows 用 MSI パッケージ | C:\Program Files\Babel\MSBuild |
| Windows 用 EXE インストーラー(すべてのユーザー) | C:\Program Files\BabelDesktop\MSBuild |
| Windows 用 EXE インストーラー(現在のユーザー) | %LOCALAPPDATA%\Programs\BabelDesktop\MSBuild |
| zip パッケージ(Windows、Linux、macOS) | パッケージを展開したフォルダー内の MSBuild フォルダー |
現在のユーザー向けにインストールした場合は、MSBuild が展開する変数 LOCALAPPDATA を使ってパスを記述します。こうするとプロジェクトにユーザー名が含まれず、同じ方法で Babel をインストールしたすべてのユーザーで動作します。
<UsingTask TaskName="Babel" AssemblyFile="$(LOCALAPPDATA)\Programs\BabelDesktop\MSBuild\Babel.Build.dll" />ファイルからタスクを読み込む方法は、すべてのオペレーティングシステムとすべてのインストーラーで使えます。Babel Desktop は、タスクがインストールされているコンピューターでプロジェクトを保存するときに、この要素を書き込みます。
アセンブリ「Babel.Build」を参照すると、Babel タスクを使用して、指定したターゲットアセンブリに対して Babel Obfuscator を起動できます。
<Target Name="AfterBuild">
<Babel InputFile="$(TargetPath)" OutputFile="$(TargetPath)" />
</Target>上で定義した Babel タスクはビルドの後に実行され、ターゲットアセンブリを難読化して、Babel が処理した難読化済みのアセンブリに置き換えます。
AfterBuild ターゲットは、ビルドパイプラインで定義されているよく知られた MSBuild ターゲット です。通常は、ビルドが完了し、すべてのバイナリが MSBuild 変数 $(TargetPath) で定義されたビルド出力フォルダーに格納された後に実行するタスクを追加するために使用します。
たとえば、前述の Babel タスクはビルドの後に実行され、$(TargetPath) 変数が示すターゲットアセンブリを難読化して、Babel が処理した難読化済みのバージョンに置き換えます。
グローバルアセンブリキャッシュ
Windows 用 MSI パッケージは、「Babel.Build.dll」をグローバルアセンブリキャッシュにも登録します。MSI でインストールしたコンピューターだけでビルドするプロジェクトでは、アセンブリ名とバージョンでタスクを指定できます。
<UsingTask TaskName="Babel" AssemblyName="Babel.Build, Version=12.1.0.0, Culture=neutral, PublicKeyToken=138d17b5bd621ab7" />Version には、インストールされている製品のバージョンを、リビジョン番号を 0 にして設定します。バージョン「x.y.z.w」の場合は Version=x.y.z.0 と記述します。この要素は、アップグレードのたびに修正する必要があります。EXE インストーラーはタスクをグローバルアセンブリキャッシュに登録しません。また、Linux と macOS にはグローバルアセンブリキャッシュがありません。
[!NOTE] ビルドがエラー MSB4062
The "Babel" task could not be loaded from the assembly Babel.Build, Version=…で停止する場合、プロジェクトはグローバルアセンブリキャッシュにないバージョンを指定しています。この要素を上記の AssemblyFile 形式に置き換えるか、プロジェクトを Babel Desktop で開いて保存してください。
AfterBuild ターゲットと Compile ターゲット
最近の .NET SDK では、最適化のタスクがいくつか追加されました。これらは AfterBuild タスクの前、かつ Compile タスクで行われるコンパイルステップの後に実行されます。Compile タスクは AfterBuild とは別のものです。AfterBuild はビルドパイプライン内のプレースホルダーにすぎず、外部のビルドプロセスによって上書きされることを想定しています。Compile タスクは実際にコンパイルが行われるステップであり、ユーザー定義のタスクで置き換えることはできません。
難読化は Compile タスクの後、かつビルドシステムによるその後の最適化の前に実行する必要があるため、Babel の難読化タスクは Compile ステップの直後に組み込みます。これには、次のように MSBuild ターゲットの属性 AfterTargets を使用します。
<Target Name="Obfuscate" AfterTargets="Compile">
<Babel InputFile="$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)"
OutputFile="$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)" />
</Target>この設定により、ビルドの最適化がさらに実行される前に、コンパイルされた出力に難読化が適用されます。
InputFile プロパティと OutputFile プロパティが TargetPath に設定されていない点に注意してください。ビルドプロセスのこの段階では、コンパイルされたアセンブリがまだ TargetPath の場所にコピーされていないためです。アセンブリは中間ビルドフォルダー $(IntermediateOutputPath) に格納されており、このフォルダーが以降のすべてのビルドステップの入力元になります。
この中間フォルダーには、コンパイルフェーズで生成されたアセンブリやその他の成果物が含まれています。そのため、最終的なビルドが完了する前に、難読化を含むさまざまなタスクをコンパイル済みの出力に対して実行できます。中間パスを指定することで、ビルド出力を変更する可能性のあるコピーや追加の処理ステップより前の、正しいバージョンのアセンブリに難読化が適用されます。
この方法はビルドプロセスを簡潔にするだけでなく、難読化された出力が正しく生成され、その後の最適化タスクやデプロイのステップに備えられることも保証します。
Babel タスクの設定
Babel タスクには、難読化プロセスを必要に応じてカスタマイズするためのさまざまなプロパティが用意されています。これらのプロパティの一覧は、ドキュメントの Babel タスクリファレンスのセクションにあります。既定では、Babel タスクはシンボルのリネームだけを有効にします。シンボルのリネームは、コード内のクラス、メソッド、その他のシンボルの名前を変更して、リバースエンジニアリングを困難にします。
制御フロー難読化、文字列暗号化、その他の高度な手法など、より高度な難読化機能を利用するには、有効なライセンスが必要です。有効なライセンスがない場合、Babel タスクは評価モードで動作し、シンボルのリネームに限定されます。また、評価モードで難読化されたアセンブリは、特定の日付を過ぎると動作しなくなります。これは、ビルドログの警告コード W00000 で示されます。たとえば、次のとおりです。
Warning [W00000]: This is an evaluation version, the obfuscated assembly will no longer work after 15/08/2024 17:16:27有効なライセンスを取得して適用すると、Babel の難読化機能をすべて利用できるようになり、制限がなくなるため、難読化されたアセンブリは期限なしで実行できます。
<Target Name="Obfuscate" AfterTargets="Compile">
<Babel InputFile="$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)"
OutputFile="$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)"
ControlFlowObfuscation="goto=on;if=on;switch=on;case=on;call=on;true"
ControlFlowIterations="3" StringEncryption="hash"
ResourceEncryption="true" />
</Target>これにより、アプリケーションは包括的な保護機能の恩恵を受け、知的財産とソースコードを不正なアクセスや改ざんから守ることができます。
コードアナライザー使用時の Visual Studio のビルドパフォーマンス
Visual Studio では、コードアナライザーが開発ワークフローに密接に統合されています。アナライザーはバックグラウンドで継続的に実行され、Visual Studio のエディターにリアルタイムでフィードバックを返します。入力中に潜在的な問題が強調表示されるため、コーディングがしやすくなります。ただし、この機能にはトレードオフがあります。反復のたびにビルドプロセスが起動されるため、特に Babel の難読化のようなタスクがビルドに含まれている場合は、パフォーマンスのボトルネックになることがあります。
不要なパフォーマンスのオーバーヘッドを避けるには、MSBuild の構成を変更して、Babel の難読化タスクが完全なビルドプロセスの間(つまり、実際にソリューションをビルドするとき)にだけ実行され、アナライザーが使用するバックグラウンドのデザイン時ビルドでは実行されないようにします。方法は次のとおりです。
<Target Name="Obfuscate" AfterTargets="Compile"
Condition="'$(DesignTimeBuild)' != 'true'">
<Babel … />
</Target>Condition=”’$(DesignTimeBuild)’ != ‘true’” を追加すると、Obfuscate ターゲットはデザイン時ビルド(コードアナライザーが使用するバックグラウンドプロセス)ではスキップされます。この変更により、最終的なビルドプロセスに影響を与えることなく、通常のコーディング中に消費される CPU 時間が大幅に減ります。難読化は、必要なとき、つまり実際のプロジェクトのビルド時には引き続き実行されます。
Babel タスクと Babel Obfuscator の NuGet パッケージ
Ultimate エディションで利用できる Babel Obfuscator の NuGet パッケージは、ビルドパイプラインへの Babel タスクの統合を簡単にします。.NET プロジェクトでパッケージを参照すると、手動で設定しなくても、ビルドプロセスの適切な位置に Babel タスクが自動的に組み込まれます。そのため、開発者は Babel タスクの Using ディレクティブを明示的に追加したり、Babel タスクをビルドスクリプトに手動で挿入したりする必要がありません。
パッケージは、プロジェクトの種類と使用している .NET SDK のバージョンに基づいて、Babel タスクの正しい配置を判断します。この自動化により、難読化プロセスはビルドパイプラインの最適な段階で実行され、プロジェクトの種類ごとに異なるさまざまなビルド構成や要件に対応できます。統合が簡潔になることでエラーの可能性が減り、開発者はビルドパイプラインの詳細を深く知らなくても難読化を適用できます。
Babel Obfuscator の NuGet パッケージを使用する主な利点
1. 自動処理:Babel Obfuscator の NuGet パッケージは、ビルドプロセス中の難読化を適切に管理するように設計されています。難読化は完全なビルドのときにだけ実行され、アナライザーが使用するデザイン時ビルドではスキップされます。
2. CPU 負荷の軽減:バックグラウンドビルドで難読化ステップを自動的にスキップすることで、システムのパフォーマンスを維持し、不要な CPU 負荷を減らして、開発中の Visual Studio の動作を軽快に保ちます。
3. 設定の簡素化:MSBuild スクリプトを手動で変更する必要はありません。パッケージはプロジェクトにそのまま統合され、すべてをバックグラウンドで処理するため、時間を節約でき、複雑さも減ります。
4. 一貫した結果:難読化プロセスは最終的なビルド段階でのみ一貫して適用されるため、日常の開発プロセスを妨げることなくコードが保護されます。
さらに、Babel Obfuscator の NuGet パッケージはプロジェクト間の一貫性を保ち、プロジェクトの複雑さやチームの習熟度にかかわらず、難読化に必要なすべての手順が正しく実施されるようにします。この機能は、ビルドプロセスを統一して維持することが難しい大規模なプロジェクトやチームで特に役立ちます。