Détection de falsification
La détection de falsification est essentielle pour garantir l’intégrité et la sécurité des applications logicielles. Dans l’environnement .NET, Babel Obfuscator est un outil efficace pour détecter la falsification. Grâce à la fonctionnalité de détection de falsification de Babel, les développeurs ajoutent une couche de protection à leurs applications et peuvent exécuter une logique personnalisée en réponse aux tentatives de falsification.
Lorsqu’un assembly est signé, le .NET Framework peut déjà détecter qu’une application a été falsifiée. Babel Obfuscator va toutefois plus loin en apportant une protection supplémentaire. Lorsque la détection de falsification est activée dans Babel, l’assembly obfusqué est capable de vérifier s’il a été falsifié ou non. En cas de falsification, l’application peut être arrêtée, ou des méthodes personnalisées de l’assembly peuvent être appelées pour traiter la falsification de manière plus contrôlée.
Sur les cibles mobiles .NET MAUI, la détection de falsification est assurée, à partir de la version 12, par un contrôle de l’intégrité du paquet qui remplace le hachage de l’image utilisé sur les cibles de bureau : un contrôle de la signature de l’APK sous Android (voir Intégrité du paquet Android (MAUI)) et un contrôle de l’identifiant de bundle et du profil de provisionnement sous iOS (voir Intégrité du paquet iOS (MAUI)). Sur les cibles de bureau, le contrôle calcule le hachage de l’image chargée en mémoire ; il est donc sans effet pour les applications publiées en fichier unique, découpées (trimming) ou compilées en AOT, et Babel émet un avertissement lorsque la détection de falsification est demandée pour une telle publication.
Configurer la détection de falsification
Activer la détection de falsification dans Babel est simple. Vous pouvez le faire en ligne de commande, en ajoutant l’option appropriée, ou avec la tâche Babel, en ajoutant l’attribut TamperingDetection au fichier de projet.
Ligne de commande
babel myapp.exe --tamperingdetectionTâche MSBuild Babel
<PropertyGroup>
<TamperingDetection>true</TamperingDetection>
</PropertyGroup>
<Babel TamperingDetection="$(TamperingDetection)" />Une fois la détection de falsification activée, l’assembly obfusqué vérifie automatiquement à l’exécution s’il a été falsifié. Si c’est le cas, l’application est arrêtée.
Sur les cibles de bureau (.NET Framework et .NET exécuté sur le CoreCLR), le contrôle calcule le hachage de l’image chargée en mémoire et le compare à un hachage inscrit dans l’assembly au moment de l’obfuscation. Cette technique exige que l’assembly soit présent sous forme d’image mappée en mémoire ; elle ne s’applique donc pas aux applications publiées en fichier unique, découpées ou compilées en AOT. Lorsque vous demandez la détection de falsification pour une telle publication, Babel vous avertit que le contrôle serait sans effet.
Intégrité du paquet Android (MAUI) Ultimate
Le hachage de l’image en mémoire décrit ci-dessus ne peut pas être utilisé sous Android : l’application s’exécute sur MonoVM et les assemblies managés sont empaquetés dans l’APK au lieu d’être chargés comme une image PE Windows. À partir de la version 12, Babel fournit une protection équivalente pour les cibles .NET pour Android (MAUI), fondée sur l’intégrité de la signature de l’APK.
Lorsque vous activez la détection de falsification pour un assembly net*-android, Babel injecte un contrôle à l’exécution qui lit le certificat avec lequel l’APK en cours d’exécution a été signé et le compare à une ou plusieurs empreintes de signataires approuvés que vous épinglez au moment de l’obfuscation. Si l’application est signée de nouveau ou reconditionnée avec une autre clé, ce qui est la façon classique de redistribuer une application modifiée, les empreintes ne correspondent plus et la réaction à la falsification se déclenche : l’application est arrêtée, ou votre gestionnaire personnalisé est appelé (voir Action personnalisée à la détection d’une falsification). Comme le contrôle examine la signature du paquet au niveau du système d’exploitation et non l’image managée, il continue de fonctionner avec le découpage et la compilation AOT (ahead-of-time).
Épingler le certificat de signature
Babel ne peut pas connaître le certificat de signature à partir du seul assembly : il est appliqué plus tard, lors de la signature de l’APK. Vous épinglez donc l’empreinte SHA-256 du certificat attendu avec l’option --trustedsigner. L’option peut être répétée, ce qui permet d’épingler plusieurs certificats (par exemple une clé d’importation et une clé de signature d’application Google Play) :
babel MyApp.dll --tamperingdetection --trustedsigner 2924C53EE9C511E9F26E0720FD8151064F7621681667D7AB1899E551CDB25104Avec la tâche MSBuild :
<PropertyGroup>
<TamperingDetection>true</TamperingDetection>
<TrustedSigner>2924C53EE9C511E9F26E0720FD8151064F7621681667D7AB1899E551CDB25104</TrustedSigner>
</PropertyGroup>
<Babel TamperingDetection="$(TamperingDetection)" TrustedSigner="$(TrustedSigner)" />Vous pouvez obtenir l’empreinte SHA-256 de votre certificat de signature avec keytool (à partir du magasin de clés) ou apksigner (à partir d’un APK généré et signé) :
keytool -list -v -keystore my-release.keystore -alias my-alias | grep -i SHA256
# or, from a signed APK:
apksigner verify --print-certs MyApp.apk | grep -i 'SHA-256'Retirez les deux-points de séparation ; la valeur passée à --trustedsigner est une chaîne hexadécimale de 64 caractères.
Si vous activez la détection de falsification sur une cible Android sans épingler de signataire approuvé, Babel émet un avertissement et se rabat sur un contrôle plus faible, qui vérifie seulement que le paquet est signé. Pour une protection réelle, passez toujours --trustedsigner (TrustedSigner) avec l’empreinte de votre certificat de publication.
Intégrité du paquet iOS (MAUI) Ultimate
Sous .NET pour iOS (MAUI), le code managé est entièrement compilé en AOT et il n’existe aucune image PE mappée en mémoire dont calculer le hachage ; la technique des cibles de bureau ne peut donc pas être utilisée. À partir de la version 12, Babel fournit un contrôle de l’identité du paquet pour les cibles net*-ios : à l’exécution, l’application obfusquée vérifie son propre identifiant de bundle et, lorsqu’elle s’exécute à partir d’un build provisionné, l’identifiant d’équipe Apple, par rapport aux valeurs que vous épinglez au moment de l’obfuscation. Si l’un des deux ne correspond plus, par exemple après que l’application a été reconditionnée ou signée de nouveau avec une autre identité de développeur, la réaction à la falsification se déclenche (l’application est arrêtée, ou votre gestionnaire personnalisé est appelé). Le contrôle s’exécute depuis un initialiseur de module au démarrage du processus et fonctionne en AOT complet.
Épingler les identifiants de bundle et d’équipe
Épinglez les valeurs attendues avec les options --trustedbundle et --trustedteam :
babel MyApp.dll --tamperingdetection --trustedbundle com.mycompany.myapp --trustedteam ABCDE12345Avec la tâche MSBuild :
<PropertyGroup>
<TamperingDetection>true</TamperingDetection>
<TrustedBundle>com.mycompany.myapp</TrustedBundle>
<TrustedTeam>ABCDE12345</TrustedTeam>
</PropertyGroup>
<Babel TamperingDetection="$(TamperingDetection)"
TrustedBundle="$(TrustedBundle)"
TrustedTeam="$(TrustedTeam)" />--trustedbundleest leCFBundleIdentifierde votre application (dansInfo.plist).--trustedteamest votre Apple Team ID de 10 caractères (visible dans le portail Apple Developer sous Membership, et dans le nom d’identité de votre certificat de signature, par exempleApple Development: You (ABCDE12345)).
Chaque épinglage est facultatif et vérifié indépendamment : épinglez l’identifiant de bundle, l’identifiant d’équipe ou les deux.
Le contrôle de l’identifiant d’équipe lit le profil de provisionnement incorporé de l’application (embedded.mobileprovision), présent dans les builds de développement, ad hoc et d’entreprise. Il n’est pas disponible dans le simulateur iOS (où le contrôle est ignoré) et il est retiré des builds App Store (qu’Apple signe de nouveau) ; pour une distribution sur l’App Store, appuyez-vous donc sur l’épinglage de l’identifiant de bundle. Si vous activez la détection de falsification sur une cible iOS sans épingler aucune des deux valeurs, Babel émet un avertissement et n’effectue aucun contrôle d’intégrité.
Action personnalisée à la détection d’une falsification
Pour personnaliser la réaction aux tentatives de falsification, les développeurs peuvent définir une méthode spécifique dans leur assembly. En appliquant la fonctionnalité « on tampering detected method » au moyen de l’attribut [Obfuscation], ils désignent une méthode personnalisée chargée de traiter l’événement de falsification. Ils peuvent ainsi implémenter leur propre logique et prendre les mesures appropriées lorsqu’une falsification est détectée. Ils peuvent par exemple définir un indicateur caché, produire des résultats incorrects ou déclencher des contre-mesures précises pour limiter les effets de la falsification. Le même gestionnaire sert au contrôle de l’image sur les cibles de bureau et aux contrôles de l’intégrité du paquet Android et iOS, de sorte qu’une seule méthode couvre toutes les cibles.
class CustomTampering
{
public static bool HasBeenTampered { get; internal set; }
[Obfuscation(Feature = "on tampering detected method")]
static void OnTamperingDetected()
{
HasBeenTampered = true;
}
}Ce code fournit une implémentation de base de la gestion de la détection de falsification.
Si HasBeenTampered vaut true, une falsification a été détectée. L’utilisation suggérée consiste à effectuer certaines actions ou à exécuter un code précis lorsqu’une falsification est détectée :
if (CustomTampering.HasBeenTampered)
{
// Tampering detected: Implement appropriate security measures or handle the
// situation accordingly.
// Examples include logging the incident, notifying system administrators,
// disabling critical functionality or terminating the application.
}En résumé, la fonctionnalité de détection de falsification de Babel Obfuscator permet aux développeurs de renforcer nettement la sécurité de leurs applications .NET. En détectant les tentatives de falsification et en y réagissant, ils préservent leur logiciel des modifications non autorisées, maintiennent l’intégrité des données et protègent les informations sensibles.