Proxy dinámico
La protección con proxy dinámico es una potente función de Babel Obfuscator que refuerza la ofuscación y la protección del código de su aplicación. Permite ocultar las llamadas a métodos, tanto de código externo como interno, mediante la generación de clases de proxy dinámico.
Cuando la protección con proxy dinámico está activada, Babel Obfuscator crea tipos de delegado o clases proxy que actúan como intermediarios de las llamadas a métodos. Estas clases proxy se construyen dinámicamente durante el proceso de ofuscación y se usan para sustituir las llamadas a métodos originales de su código.
La principal ventaja de los proxies dinámicos es que ocultan eficazmente las llamadas reales a los métodos, lo que hace mucho más difícil que los atacantes o quienes practican la ingeniería inversa comprendan y analicen el flujo del código. Con los proxies dinámicos puede impedir el acceso directo a los métodos sensibles y ocultar la lógica de la aplicación.
En esta sección se tratan:
- Cómo funciona el proxy dinámico y las limitaciones de plataforma
- Llamadas internas y externas: los modos de proxy y lo que protegen
- Cobertura: qué llamadas pasan por un proxy y cuáles siguen siendo directas
- Filtros: proxy solo para las llamadas que elija
- Configuración: CLI, MSBuild y Babel Desktop
- Rendimiento y Resistencia a la desofuscación
Cómo funciona el proxy dinámico
En tiempo de compilación, por cada llamada protegida Babel Obfuscator genera un pequeño tipo de delegado proxy y reescribe la instrucción call, callvirt o newobj original para que pase por ese proxy. El código reescrito ya no hace referencia directa al destino real (su tipo declarante, el método y el campo que contendrá la llamada resuelta). En su lugar, un pequeño resolvedor inyectado lo recupera la primera vez que se ejecuta cada llamada mediante proxy y lo guarda en caché, de modo que las llamadas posteriores pasan directamente.
De este diseño se derivan dos propiedades:
- El análisis estático se ve obstaculizado. Los sitios de llamada reescritos ya no llevan una referencia directa de metadatos al destino, de modo que los descompiladores y los desofuscadores automáticos no pueden reconstruir el grafo de llamadas original solo a partir de los metadatos. Además, la forma en que se codifican los destinos varía de una compilación a otra, por lo que las herramientas no pueden basarse en patrones fijos (consulte Resistencia a la desofuscación).
- La resolución es diferida y se guarda en caché. La primera llamada a un miembro determinado al que se accede mediante proxy paga un pequeño coste único para resolver el destino y conectar el delegado; todas las llamadas posteriores pasan por el delegado en caché con un coste adicional insignificante (consulte Rendimiento).
El uso de proxies es una transformación puramente administrada que se realiza en tiempo de compilación: no requiere .NET Framework, funciona en .NET y en .NET Framework y no cambia el comportamiento observable de su programa (salvo el pequeño conjunto de llamadas enumeradas en Cobertura, que se dejan directas de forma intencionada).
Limitaciones de AOT y de compatibilidad de plataforma
Actualmente, el proxy dinámico no se admite en ensamblados de .NET MAUI y Blazor debido a una combinación de limitaciones de plataforma y restricciones del entorno de ejecución que impiden generar y ejecutar los proxies de forma segura o coherente en estos entornos.
Restricciones de plataforma
- Compilación Ahead-of-Time (AOT): plataformas como iOS (usada por .NET MAUI) y WebAssembly (usada por Blazor WebAssembly) imponen la compilación AOT. Esto excluye el uso de funciones del entorno de ejecución como la emisión de código basada en reflexión o la generación de tipos en tiempo de ejecución. Aunque el proxy dinámico de Babel no genera código en tiempo de ejecución, la lógica de proxy generada puede depender de metadatos y construcciones de IL que se eliminan o no se admiten en los entornos compilados con AOT.
Limitaciones de compatibilidad de IL
- Tokens de metadatos no admitidos: el mecanismo de proxy dinámico inyecta capas intermedias de llamada mediante tipos proxy generados y stubs de delegado. Estos se basan en tokens de metadatos y mecanismos de indirección que pueden no ser verificables o que directamente no se admiten en determinados destinos AOT, lo que provoca fallos de validación en tiempo de ejecución o cierres inesperados de la aplicación.
Limitaciones de Blazor/WebAssembly
- Capacidades de reflexión restringidas: en Blazor WebAssembly, la reflexión está muy limitada. Como el proxy dinámico a menudo envuelve o intercepta las llamadas a métodos, puede dar lugar a rutas de invocación indirectas que son incompatibles con el proceso de enlazado y de tree shaking que se emplea en los flujos de trabajo de publicación de WebAssembly.
Recomendación
Para una compatibilidad total con entornos AOT como .NET MAUI y Blazor, se recomienda establecer DynamicProxy=false. Así se garantiza que los ensamblados generados sigan siendo totalmente verificables, conformes con la plataforma y libres de funciones que puedan fallar durante el enlazado nativo o el inicio del entorno de ejecución.