Résistance à la désobfuscation

Comme les sites d’appel réécrits ne référencent plus directement leurs cibles et que le codage varie d’un build à l’autre, les outils de désobfuscation automatisés ne peuvent pas retrouver le graphe d’appels d’origine par analyse statique. Le proxy dynamique de Babel est régulièrement vérifié face aux principaux outils open source de désobfuscation .NET : leurs résolveurs d’appels par proxy ne retrouvent aucun des appels passés par proxy, et la sortie nettoyée ne reconstruit pas les appels directs d’origine.

Associer le proxy dynamique au renommage des symboles, à l’obfuscation du flux de contrôle et à la protection contre la falsification accroît encore l’effort nécessaire pour soumettre un assembly protégé à la rétro-ingénierie.

Bonnes pratiques

• Protégez ce qui compte. Utilisez les filtres pour cibler le flux d’appels sensible (gestion des licences, contrôles de sécurité, algorithmes propriétaires) au lieu de faire passer chaque appel par un proxy : la protection est maximale, pour un effet minimal sur la taille et le démarrage.
• Choisissez le bon mode. external est une option légère qui met surtout en échec la récupération des noms de variables et l’inférence de types dans les décompilateurs ; all offre l’obfuscation du flux d’appels la plus forte pour la logique interne (voir Appels internes et externes).
• Combinez les fonctionnalités. Le proxy dynamique est le plus efficace lorsqu’il est associé au renommage, à l’obfuscation du flux de contrôle et à la protection contre la falsification.
• Désactivez-le sur les cibles AOT. Définissez DynamicProxy=false pour les assemblies .NET MAUI et Blazor (voir Limites de compatibilité AOT et plateforme).
• Vérifiez après la génération. Exécutez votre suite de tests sur l’assembly obfusqué, comme pour tout paramètre de protection.

La protection par proxy dynamique de Babel Obfuscator renforce nettement la sécurité de votre application en masquant les appels de méthodes et en compliquant la rétro-ingénierie.