Tarea de MSBuild

La tarea Babel de MSBuild está disponible con cualquier edición de licencia de Babel Obfuscator y puede añadirse a cualquier proyecto de MSBuild insertando el elemento UsingTask correspondiente en el archivo XML del proyecto de MSBuild:

<UsingTask TaskName="Babel" AssemblyName="Babel.Build, Version=10.0.0.0, Culture=neutral, PublicKeyToken=138d17b5bd621ab7" />

El atributo AssemblyName hace referencia al nombre completo del componente .NET Babel.Build.dll instalado en la caché global de ensamblados.

La propiedad Version de AssemblyName debe establecerse en la versión del producto instalada actualmente. Por ejemplo, si ha instalado la versión x.y.z.w:

Version=x.y.z.0

El número de revisión w debe establecerse siempre en 0.

Si no desea usar el nombre completo del ensamblado, puede hacer referencia al componente Babel.Build.dll mediante su ruta completa, como se muestra a continuación:

<UsingTask TaskName="Babel" AssemblyFile="<Full path to Babel.Build.dll>" />

Una vez que se ha hecho referencia al ensamblado Babel.Build, ya puede usarse la tarea Babel para iniciar Babel Obfuscator sobre un ensamblado de destino determinado:

<Target Name="AfterBuild">
  <Babel InputFile="$(TargetPath)" OutputFile="$(TargetPath)" />
</Target>

La tarea Babel definida más arriba se ejecuta después de la compilación para ofuscar el ensamblado de destino, que se sustituye por el ensamblado ofuscado que genera Babel.

El destino «AfterBuild» es un destino de MSBuild  muy conocido, definido en el pipeline de compilación, que suele usarse para añadir tareas que se ejecutan una vez terminada la compilación, cuando todos los binarios están ya en la carpeta de salida de la compilación definida por la variable de MSBuild  $(TargetPath).

Por ejemplo, la tarea Babel mencionada antes se ejecuta después de la compilación para ofuscar el ensamblado de destino indicado en la variable $(TargetPath), y lo sustituye por la versión ofuscada que genera Babel.

Destinos AfterBuild y Compile

En los SDK de .NET más recientes se han introducido tareas de optimización adicionales que se ejecutan antes de la tarea «AfterBuild» y después del paso de compilación, que se lleva a cabo en la tarea «Compile». La tarea «Compile» es distinta de «AfterBuild», que no es más que un marcador de posición en el pipeline de compilación, pensado para que lo redefinan procesos de compilación externos. La tarea «Compile» es el paso en el que se produce realmente la compilación, y no puede sustituirse por tareas definidas por el usuario.

Como la ofuscación debe realizarse después de la tarea «Compile» y antes de cualquier optimización posterior del sistema de compilación, conviene integrar la tarea de ofuscación de Babel inmediatamente después del paso «Compile». Para ello se usa el atributo AfterTargets de los destinos de MSBuild, como se muestra a continuación:

<Target Name="Obfuscate" AfterTargets="Compile">
  <Babel InputFile="$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)" 
         OutputFile="$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)" />
</Target>

Esta configuración garantiza que el proceso de ofuscación se aplique a la salida compilada antes de que se ejecute ninguna otra optimización de la compilación.

Es importante observar que las propiedades InputFile y OutputFile no se establecen en TargetPath porque, en esta fase del proceso de compilación, el ensamblado compilado todavía no se ha copiado en la ubicación de TargetPath. Se encuentra, en cambio, en una carpeta de compilación intermedia, $(IntermediateOutputPath), que sirve de origen para todos los pasos posteriores de la compilación.

Esta carpeta intermedia contiene el ensamblado y otros artefactos producidos durante la fase de compilación, lo que permite realizar distintas tareas, entre ellas la ofuscación, sobre la salida compilada antes de que termine la compilación final. Al especificar la ruta intermedia, se garantiza que el proceso de ofuscación se aplique a la versión correcta del ensamblado, tal como existe antes de cualquier copia o paso de procesamiento adicional que pueda alterar la salida de la compilación.

Este enfoque no solo simplifica el proceso de compilación, sino que además garantiza que la salida ofuscada se genere correctamente y quede lista para las tareas de optimización o los pasos de despliegue posteriores.

Configuración de la tarea Babel

La tarea Babel ofrece numerosas propiedades que pueden configurarse para adaptar el proceso de ofuscación a sus necesidades concretas. La lista completa de estas propiedades está en la sección Referencia de la tarea Babel de la documentación. De forma predeterminada, la tarea Babel solo activa el renombrado de símbolos, que modifica los nombres de las clases, los métodos y otros símbolos del código para dificultar la ingeniería inversa.

Para acceder a funciones de ofuscación más avanzadas, como la ofuscación del flujo de control, el cifrado de cadenas y otras técnicas sofisticadas, se necesita una licencia válida. Sin una licencia válida, la tarea Babel funciona en modo de demostración, que se limita al renombrado de símbolos. Además, los ensamblados ofuscados en modo de demostración dejan de funcionar después de una fecha determinada, como indica en el registro de compilación el código de advertencia W00000. Por ejemplo:

Warning [W00000]: This is an evaluation version, the obfuscated assembly will no longer work after 15/08/2024 17:16:27

Al obtener y aplicar una licencia válida se desbloquean todas las capacidades de ofuscación de Babel y desaparecen las limitaciones, de modo que los ensamblados ofuscados se ejecutan sin fecha de caducidad.

<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>

De este modo, su aplicación cuenta con funciones de protección completas, que resguardan su propiedad intelectual y su código fuente frente al acceso no autorizado y la manipulación.

Rendimiento de la compilación en Visual Studio con analizadores de código

En Visual Studio, los analizadores de código están estrechamente integrados en el flujo de trabajo de desarrollo. Estos analizadores se ejecutan continuamente en segundo plano para ofrecer información en tiempo real en el editor de Visual Studio, lo que facilita la escritura de código al resaltar los posibles problemas mientras se escribe. Sin embargo, esta función tiene una contrapartida: desencadena el proceso de compilación en cada iteración, lo que puede provocar cuellos de botella de rendimiento, sobre todo si la compilación incluye tareas como la ofuscación con Babel.

Para evitar un coste adicional de rendimiento innecesario, puede modificar su configuración de MSBuild de modo que la tarea de ofuscación de Babel se ejecute solo durante el proceso de compilación completo (es decir, cuando realmente se compila la solución) y no durante las compilaciones en tiempo de diseño que los analizadores realizan en segundo plano. Se hace así:

<Target Name="Obfuscate" AfterTargets="Compile" 
        Condition="'$(DesignTimeBuild)' != 'true'">
    <Babel … />
</Target>

Al añadir Condition=”’$(DesignTimeBuild)’ != ‘true’”, el destino Obfuscate se omite durante las compilaciones en tiempo de diseño (los procesos en segundo plano que usan los analizadores de código). Este cambio reduce considerablemente el tiempo de CPU que se consume durante las sesiones normales de programación, sin afectar al proceso de compilación final. La ofuscación se sigue ejecutando cuando hace falta, es decir, durante la compilación real del proyecto.

Tarea Babel y paquete NuGet de Babel Obfuscator

El paquete NuGet de Babel Obfuscator, disponible con la edición Ultimate, simplifica la integración de la tarea Babel en el pipeline de compilación. Una vez que se hace referencia al paquete en un proyecto .NET, este integra automáticamente la tarea Babel en el punto adecuado del proceso de compilación, sin necesidad de configuración manual. Así, los desarrolladores no tienen que añadir explícitamente la directiva Using de la tarea Babel ni insertar a mano la tarea Babel en el script de compilación.

El paquete determina de forma inteligente la ubicación correcta de la tarea Babel en función del tipo de proyecto y de la versión del SDK de .NET que se usa. Esta automatización garantiza que el proceso de ofuscación tenga lugar en la fase óptima del pipeline de compilación y se adapte a las distintas configuraciones de compilación y a los requisitos propios de cada tipo de proyecto. Esta integración simplificada reduce al mínimo la posibilidad de errores y permite a los desarrolladores aplicar la ofuscación sin conocer a fondo los entresijos del pipeline de compilación.

Ventajas principales de usar el paquete NuGet de Babel Obfuscator

1. Gestión automática: el paquete Babel Obfuscator NuGet está diseñado para gestionar de forma inteligente la ofuscación durante el proceso de compilación, de modo que se ejecute solo en las compilaciones completas y se omita en las compilaciones en tiempo de diseño que usan los analizadores.

2. Menor carga de CPU: al omitir automáticamente el paso de ofuscación en las compilaciones en segundo plano, el paquete ayuda a mantener el rendimiento del sistema, reduce la carga innecesaria de CPU y permite que Visual Studio funcione con más fluidez durante el desarrollo.

3. Configuración simplificada: no es necesario modificar a mano los scripts de MSBuild. El paquete se integra sin fricciones en su proyecto y se ocupa de todo en segundo plano, lo que ahorra tiempo y reduce la complejidad.

4. Resultados coherentes: el proceso de ofuscación se aplica siempre y únicamente en las fases finales de la compilación, de modo que su código queda protegido sin interferir en el trabajo diario de desarrollo.

Además, el paquete Babel Obfuscator NuGet mantiene la coherencia entre proyectos y garantiza que todos los pasos necesarios para la ofuscación se apliquen correctamente, con independencia de la complejidad del proyecto o de la familiaridad del equipo con el proceso. Esta función resulta especialmente útil en proyectos o equipos grandes, en los que mantener procesos de compilación uniformes puede ser difícil.