Mobile App Shielding : définition et fonctionnement

Qu'est-ce que le shielding des applications mobiles

Le shielding des applications mobiles consiste à intégrer des protections de sécurité directement dans les applications mobiles afin de les protéger lorsqu'elles s'exécutent sur des appareils qui échappent au contrôle des équipes de sécurité. Contrairement aux protections traditionnelles côté serveur, qui visent à sécuriser les données en transit ou sur des serveurs gérés, le shielding se concentre sur le côté client, l'appareil de l'utilisateur, qui peut être compromis ou utilisé volontairement comme environnement d'instrumentation pour manipuler l'application à l'exécution.

À la base, le shielding des applications mobiles permet à l'application de se défendre elle-même en temps réel, ce qui complique la rétro-ingénierie, la modification ou l'extraction de données sensibles par les attaquants. Il traite l'application comme un système sécurisé fonctionnant dans un environnement non fiable, au lieu de supposer que l'appareil lui-même est sûr.

En pratique, cela signifie que l'application surveille en permanence l'environnement dans lequel elle s'exécute pour y repérer des signes de tentatives d'attaque, ce qui lui permet de réagir aux menaces même sur des appareils auxquels on ne peut pas se fier.

Cela s'inscrit dans les principes de résilience décrits dans l'OWASP Mobile Application Security Verification Standard (MASVS) et l'OWASP Mobile Security Testing Guide (MSTG), qui mettent l'accent sur la protection à l'exécution, la résistance à la falsification et la défense contre les environnements instrumentés ou compromis.

Comment fonctionne le shielding des applications mobiles en pratique

Le shielding des applications mobiles intègre plusieurs couches de défense directement dans l'application, ce qui lui permet de détecter les attaques et d'y réagir sur des appareils qui échappent au contrôle des équipes de sécurité. Ces couches comprennent le durcissement de l'application, la surveillance de son environnement, la réaction aux menaces en temps réel et la sécurisation des données sensibles. Voici comment chacune fonctionne en pratique.

1. Durcissement de l'application

Le durcissement de l'application vise à rendre l'application elle-même difficile à comprendre, à modifier ou à compromettre. Ce processus transforme le code et les fonctions critiques de manière à augmenter considérablement les compétences et les efforts nécessaires pour qu'un attaquant réussisse.

Le durcissement de l'application fait appel à plusieurs techniques spécialisées pour protéger différentes parties de l'application.

a. Obfuscation du code
L'obfuscation du code renomme les classes, les méthodes et les variables avec des identifiants dénués de sens et restructure les flux de contrôle. Le code décompilé devient ainsi difficile à lire ou à analyser. Les techniques d'obfuscation avancées peuvent aussi encoder les appels de méthodes et insérer des chemins de code trompeurs, ce qui augmente l'effort nécessaire pour comprendre la logique du programme. L'obfuscation relève directement la barrière à la rétro-ingénierie et à la falsification.

b. Cryptographie en boîte blanche
La cryptographie en boîte blanche intègre les clés et les opérations cryptographiques dans du code obfusqué, de sorte qu'elles ne puissent pas être extraites de la mémoire ni de l'exécution. Elle protège des opérations sensibles comme l'authentification, le chiffrement et la génération de jetons, même si l'attaquant a un accès complet à l'environnement de l'application. Contrairement à la cryptographie standard, les techniques en boîte blanche supposent que l'environnement d'exécution est hostile.

c. Protection du code natif
La logique critique, la cryptographie et les algorithmes sensibles peuvent être déplacés vers du code natif, compilé en langage machine. Le code natif est plus difficile à analyser ou à modifier que le bytecode et exige des outils de rétro-ingénierie spécialisés. Cela rend la falsification à l'exécution et l'injection de code nettement plus difficiles pour les attaquants.

En appliquant ces techniques de durcissement ensemble, l'application augmente les compétences, les efforts et le temps nécessaires à l'exploitation, ce qui renforce la sécurité au niveau du code et complète les mesures de détection et de réponse.

2. Runtime Application Self-Protection (RASP)

Runtime Application Self-Protection permet à l'application de se défendre pendant son exécution en surveillant en continu son environnement et en réagissant automatiquement aux menaces. Contrairement aux contrôles de sécurité traditionnels qui opèrent en dehors de l'application, le RASP est intégré directement dans l'application, ce qui lui permet de détecter et de contrer les attaques en temps réel sans intervention externe.

a. Détection et surveillance des menaces
L'application surveille en continu son environnement à la recherche de tout signe de falsification, de débogage ou d'activité inhabituelle pouvant indiquer une attaque en cours.

Au cœur de cette protection se trouve la vérification de l'intégrité, qui garantit que le binaire de l'application n'a pas été altéré depuis sa signature. Cette détection de la falsification et du repackaging garantit que les utilisateurs exécutent la version légitime de l'application, et non une copie modifiée susceptible d'inclure du code malveillant ou de contourner des contrôles de sécurité critiques.

En plus des vérifications statiques, l'application effectue également une détection par analyse à l'exécution. Cela lui permet d'identifier des outils d'attaque sophistiqués, comme Frida ou les inspecteurs de mémoire, que les attaquants utilisent pour s'accrocher aux applications en cours d'exécution. En reconnaissant les tentatives d'analyse ou de modification de l'application à l'exécution, celle-ci peut bloquer le débogage non autorisé avant que les attaquants ne manipulent son comportement.

Enfin, l'application procède à une évaluation de la sécurité de l'appareil pour déterminer si elle s'exécute sur un appareil rooté ou jailbreaké, où les protections du système d'exploitation ont été contournées. Au-delà de la détection du root, elle surveille les séquences inhabituelles, les modifications de la mémoire et les schémas d'accès aux API, ce qui ajoute une couche de défense contre l'activité suspecte à l'exécution.

b. Actions de réponse automatisées

La détection seule ne suffit pas. Le RASP permet à l'application de réagir immédiatement lorsqu'une menace est identifiée, en stoppant les attaques avant que des données sensibles ou une logique critique ne soient compromises.

Un mécanisme clé est la restriction des fonctionnalités, qui bloque l'accès aux fonctions ou aux données sensibles lorsque l'application détecte un environnement risqué. Ainsi, même si un attaquant prend un contrôle partiel de l'appareil, il ne peut pas atteindre les parties les plus critiques de l'application.

Dans les cas plus graves, l'auto-terminaison permet à l'application d'arrêter des processus risqués ou de se terminer entièrement. Même si cela peut sembler radical, cela empêche efficacement les attaquants d'extraire des informations sensibles ou de manipuler des transactions critiques.

L'application fournit aussi des rapports et des alertes, en envoyant des événements aux serveurs backend pour la surveillance et l'analyse. Cette télémétrie donne aux équipes de sécurité une visibilité précieuse sur les tentatives d'attaque et aide les organisations à affiner leurs défenses au fil du temps.

En combinant ces capacités, le RASP garantit que l'application reste résiliente même sur des appareils compromis, en adaptant son niveau de sécurité en temps réel selon les menaces qu'elle rencontre.

3. Sécurisation des données sensibles

Même si les attaquants ont accès à l'appareil, le shielding protège les informations que l'application traite ou stocke. Le chiffrement et le stockage sécurisé protègent les identifiants, les jetons et les autres données sensibles. Voici comment le shielding d'application protège les données en pratique :

a. Shielding en mémoire

Les outils de shielding surveillent activement les données sensibles et les « brouillent » pendant leur traitement en RAM. Cela empêche le memory scraping ou les attaques par vidage de tampon, dans lesquels un pirate tente de lire des mots de passe ou des jetons dans leur état fugace et non chiffré pendant l'exécution.

b. Intégrité de l'environnement pour l'accès aux données

Le shielding n'autorise l'application à utiliser le stockage sécurisé (comme Keychain/Keystore) que lorsque l'appareil est sûr. Si l'appareil n'est pas sûr (par exemple rooté, falsifié ou attaqué), il bloque l'accès pour éviter que les données sensibles ne soient volées ou détournées. S'il détecte un débogueur ou une méthode hookée, il peut même arrêter l'application immédiatement avant qu'elle ne demande au système d'exploitation des données sensibles comme des jetons.

Menaces mobiles courantes contre lesquelles le shielding protège

Les applications mobiles qui s'exécutent sur des appareils hors de votre contrôle sont exposées à des risques variés. Les attaquants ciblent les applications pour extraire des données sensibles, manipuler la logique ou contourner les protections. Comprendre ces menaces aide les équipes de sécurité à identifier où le shielding des applications mobiles apporte une réelle valeur.

Menaces courantes contre les applications mobiles

Rétro-ingénierie

La rétro-ingénierie est souvent la première étape qu'entreprennent les attaquants pour comprendre le fonctionnement interne d'une application. En analysant le code compilé, ils peuvent découvrir une logique sensible et identifier des faiblesses avant de lancer des attaques plus avancées.

Les attaquants utilisent souvent des décompilateurs, des désassembleurs ou des frameworks de rétro-ingénierie comme JADX ou Ghidra pour inspecter le binaire de l'application. Cela leur permet de :

• Découvrir des algorithmes propriétaires, une logique d'authentification ou des routines de chiffrement.
• Extraire des secrets codés en dur comme des clés d'API, des jetons ou des clés cryptographiques.
• Identifier des endpoints, des protocoles ou des workflows internes qui peuvent être abusés pour contourner les contrôles de sécurité.
• Préparer des attaques plus sophistiquées, comme la fabrication de fausses requêtes ou d'exploits automatisés ciblant les faiblesses de l'application.

Falsification et repackaging

Une fois que les attaquants ont compris l'application, ils peuvent en modifier ou en redistribuer une version malveillante. Cela inclut les attaques de re-skinning, où l'application est clonée et modifiée visuellement pour se faire passer pour l'application d'origine ou contourner les contrôles de confiance.

Des outils comme Apktool pour Android facilitent la décompilation, la modification et la reconstruction des applications.

Lorsqu'un attaquant modifie l'APK/IPA de l'application :

• Les contrôles d'authentification, la validation des licences ou les flux de paiement intégrés à l'application peuvent être contournés.
• Du code malveillant peut être injecté pour espionner les utilisateurs, voler des données ou propager des logiciels malveillants.
• Les contrôles d'intégrité peuvent être supprimés, ce qui permet un accès non autorisé persistant.
• Les applications repackagées peuvent être distribuées sur des stores non officiels, ce qui nuit à la confiance des utilisateurs et à la réputation de la marque.

Débogage ou hooking non autorisé

Au lieu de modifier l'application de façon permanente, les attaquants peuvent interagir avec elle en temps réel à l'aide d'outils d'analyse dynamique. Les attaques deviennent ainsi plus flexibles et plus difficiles à détecter.

Les attaquants utilisent des outils d'analyse à l'exécution comme Frida pour intercepter et manipuler le comportement de l'application en temps réel :

• Les appels de fonctions peuvent être hookés pour altérer les sorties ou contourner la validation.
• Les données sensibles en mémoire (mots de passe, jetons, clés de chiffrement) peuvent être capturées.
• Les attaquants peuvent tester et exploiter la logique de l'application dynamiquement sans modifier le binaire de façon permanente.
• Permet la manipulation en temps réel des achats intégrés, des feature flags ou des contrôles de sécurité.

Appareils rootés ou jailbreakés

Sur les appareils compromis, les protections intégrées du système d'exploitation sont affaiblies, ce qui donne aux attaquants un accès beaucoup plus profond à l'application et à ses données.

Sur Android, cela passe généralement par le rootage de l'appareil, tandis que sur iOS il s'agit du jailbreak ; l'un et l'autre suppriment des restrictions système essentielles conçues pour protéger les applications et les données des utilisateurs. Détecter si un appareil a été rooté est donc une première étape essentielle pour sécuriser les applications mobiles

• Le sandboxing des applications et les protections du système d'exploitation sont affaiblis ou contournés.
• Les attaquants obtiennent des privilèges élevés pour lire/écrire le stockage de l'application, les journaux système ou les données d'autres applications.
• Les mécanismes de sécurité qui reposent sur l'intégrité du système d'exploitation (par ex. Keychain, chiffrement de SharedPreferences, SafetyNet/DeviceCheck) peuvent être contournés.
• Facilite l'installation de hooks, de débogueurs et de scanners de mémoire pour des attaques dynamiques.

Manipulation à l'exécution

La manipulation à l'exécution consiste, pour les attaquants, à interférer avec une application pendant son exécution afin de changer son comportement, de contourner des contrôles ou d'extraire des données sensibles sans modifier le binaire.

Des outils comme Frida sont là encore couramment utilisés, avec des outils de débogage et d'inspection de la mémoire, pour hooker des fonctions et altérer le flux d'exécution en temps réel.

Les attaquants peuvent :

• Modifier des valeurs en mémoire pour ignorer des validations
• Intercepter ou rejouer des appels d'API en modifiant l'état d'exécution
• Hooker des fonctions de l'application pour altérer la logique pendant l'exécution
• Extraire des données sensibles directement de la mémoire

Attaques malveillantes par interaction au niveau du système d'exploitation

Les attaquants peuvent abuser des fonctionnalités du système d'exploitation ou d'autres applications pour interagir avec l'application ciblée de manière non prévue. Ces attaques ne modifient pas l'application elle-même, mais exploitent la façon dont elle se comporte dans l'environnement du système d'exploitation.

Parmi les techniques courantes :

• L'abus de l'accessibilité, utilisé pour lire le contenu de l'écran ou automatiser des actions de l'utilisateur
• Les attaques par superposition (style cloak & dagger) pour capturer des saisies comme des identifiants
• Le détournement de tâches (task hijacking), où la navigation de l'application ou le flux de session est manipulé
• L'abus des droits d'administrateur de l'appareil, qui accorde un contrôle élevé sur l'appareil ou le comportement de l'application

Curieux de connaître les outils utilisés pour tester les applications mobiles avec les mêmes techniques que celles sur lesquelles s'appuient les attaquants ? Découvrez notre top 10 des outils de pentest mobile en 2026.

Comment le shielding des applications mobiles protège contre ces menaces

Le shielding ne rend pas les applications invulnérables, mais il augmente considérablement le coût, l'effort et les compétences techniques nécessaires pour qu'un attaquant réussisse. Cette barrière relevée dissuade la plupart des menaces réelles et oblige les attaquants soit à abandonner leurs efforts, soit à investir des ressources bien supérieures à ce qui est réaliste pour des attaques opportunistes.

Menace	Comment le shielding protège
Rétro-ingénierie	Utilise l'obfuscation du code, la transformation du flux de contrôle et la protection du code natif pour rendre le code décompilé difficile à comprendre et à analyser.
Falsification et repackaging	Applique des contrôles d'intégrité, la validation des signatures et des mécanismes d'anti-falsification pour détecter les applications modifiées ou clonées et bloquer les builds non autorisés.
Débogage ou hooking non autorisé	Détecte les outils d'instrumentation à l'exécution, bloque les tentatives de hooking de fonctions et surveille les comportements de débogage ou d'injection de code.
Appareils rootés ou jailbreakés	Effectue des contrôles d'intégrité de l'appareil pour détecter les environnements compromis, et restreint ou bloque les fonctionnalités sensibles lorsque les protections du système d'exploitation sont contournées.
Manipulation à l'exécution	Utilise une surveillance basée sur le RASP pour détecter en temps réel un comportement d'exécution anormal, la manipulation de la mémoire et les interférences au niveau des API.
Attaques malveillantes par interaction au niveau du système d'exploitation	Détecte les interactions anormales avec l'application, comme les tentatives de superposition, l'abus de l'accessibilité, le détournement de tâches et le contrôle non autorisé de l'interface ou des saisies, puis protège les parcours utilisateur sensibles ou bloque l'exécution.

Cas d'usage du shielding des applications mobiles

Le shielding des applications mobiles est essentiel pour les applications qui traitent des données sensibles, gèrent des transactions financières ou contiennent une logique métier propriétaire sur des appareils hors de votre contrôle. Si les applications du shielding sont vastes, les exemples suivants illustrent des scénarios courants dans lesquels il apporte une protection significative.

1. Applications bancaires et fintech

Dans les applications bancaires, les attaquants ne s'en prennent pas toujours à l'application elle-même. Une astuce courante consiste à abuser des services d'accessibilité ou des permissions de superposition d'écran pour afficher de faux écrans de connexion identiques à ceux de la vraie application. Du point de vue de l'utilisateur, tout semble normal, mais ses identifiants sont capturés, ou des transactions sont manipulées en silence.

C'est là qu'intervient le shielding des applications mobiles. Même si l'attaque commence au niveau de l'appareil, le shielding aide à sécuriser ce qui compte à l'intérieur de l'application : il protège les flux d'authentification, détecte la falsification et ajoute des garde-fous autour d'opérations sensibles comme les paiements et les virements.

Une analyse de plus de 500 applications bancaires mobiles par Ostorlab a révélé des identifiants cloud codés en dur dans plus de 50 % des applications et du HTTP en clair dans 20 % d'entre elles, ce qui montre pourquoi la protection à l'exécution et le shielding des applications mobiles sont désormais essentiels pour toute institution financière

2. Applications de jeux

Les tricheurs et les pirates peuvent manipuler les achats intégrés, sauter des niveaux ou obtenir des avantages déloyaux.

Selon le rapport 2025 Gaming's Cheating Crisis de PlaySafe ID, 80 % des joueurs rencontrent de la triche dans les jeux en ligne, et plus de la moitié des joueurs (55 %) ont réduit ou cessé leurs dépenses en achats intégrés à cause de la triche. Il est donc d'autant plus essentiel de protéger les achats intégrés et la logique de progression.

Le shielding des applications mobiles aide ici en durcissant le code du jeu pour résister à la falsification, en bloquant les outils de hooking que les tricheurs utilisent pour contourner les paiements ou débloquer des fonctionnalités, et en verrouillant le contenu premium et les flux de paiement afin qu'ils ne puissent pas être facilement manipulés sur l'appareil.

3. Applications de santé

Les données des patients sont hautement sensibles et souvent traitées sur des appareils personnels susceptibles d'être compromis. Le shielding sécurise les dossiers de santé, les jetons d'authentification et les communications des dispositifs médicaux, même sur des appareils rootés, jailbreakés ou avec le débogage activé.

Une étude universitaire sur les applications mHealth Android a constaté que 45 % reposent sur une communication non chiffrée, et que environ 23 % des données personnelles (localisation, identifiants ou identifiants d'utilisateur) sont envoyées sur des canaux non sécurisés.

Ces exemples montrent comment le shielding renforce la sécurité des applications à haut risque, mais ses bénéfices s'étendent à toute application qui gère une logique, des données ou des transactions sensibles sur des appareils non fiables.

Bonnes pratiques pour déployer le shielding des applications mobiles

Déployer efficacement le shielding des applications mobiles exige plus que d'intégrer des protections dans l'application. Il faut des processus structurés, de l'automatisation et une validation continue pour garantir que les défenses restent efficaces sans dégrader l'expérience utilisateur. Voici les principales bonnes pratiques pour les équipes de sécurité :

1. Commencer le shielding tôt
Commencez à intégrer les protections de shielding dès la phase de développement. Cela garantit que la logique critique, les données sensibles et les mesures de sécurité sont protégées dès le premier jour. Une intégration précoce facilite le traitement des problèmes de sécurité avant qu'ils ne deviennent coûteux ou difficiles à corriger.

2. Intégrer le shielding dans les pipelines CI/CD
Le shielding doit faire partie de votre processus automatisé de build et de release. En intégrant les protections directement dans les pipelines CI/CD, chaque build de l'application inclut systématiquement les dernières mesures de sécurité. Cela réduit les erreurs humaines, garantit une couverture uniforme d'une version à l'autre et fait du shielding une partie intégrante de votre cycle de développement.

3. Valider en continu le shielding avec des outils de test
Vérifiez régulièrement que les mécanismes de shielding sont correctement appliqués et restent efficaces. Utilisez des outils de test de sécurité automatisés, comme les tests de sécurité des applications (AST) statiques et dynamiques, pour valider que des protections critiques, telles que l'obfuscation du code, les défenses à l'exécution et le stockage sécurisé, fonctionnent comme prévu dans chaque build.

4. Surveiller la télémétrie et alerter sur les tentatives de falsification
Collectez la télémétrie d'exécution des applications protégées par le shielding pour détecter les tentatives non autorisées de rétro-ingénierie, de falsification ou de débogage de l'application. Les équipes de sécurité peuvent utiliser ces informations pour identifier des schémas d'attaque, réagir de façon proactive et améliorer en continu les défenses de l'application.

5. Mettre à jour la logique de shielding selon le renseignement sur les menaces
Le paysage des menaces mobiles évolue rapidement. Mettez régulièrement à jour les règles de détection, les protections à l'exécution et les méthodes cryptographiques en fonction du dernier renseignement sur les menaces. Cela garantit que votre shielding reste efficace contre les nouvelles techniques d'attaque et les exploits émergents.

6. Préserver l'expérience utilisateur et les performances
Une sécurité forte ne doit pas compromettre la facilité d'utilisation. Les mécanismes de shielding doivent être optimisés pour ne pas ralentir l'application, vider la batterie ou provoquer des plantages. Des tests continus sur de vrais appareils garantissent que les mesures de sécurité restent efficaces tout en préservant une expérience utilisateur fluide.

Comment le Shielding Scan d'Ostorlab détecte et contourne les protections de shielding

Détecter qu'une application contient du shielding ne suffit pas. La question importante est de savoir si ces protections fonctionnent encore lorsque quelqu'un tente activement de les contourner.

Le Mobile Shielding Scan d'Ostorlab identifie des protections telles que la détection du root et du jailbreak, l'anti-falsification et les contrôles d'intégrité, l'anti-débogage, l'anti-instrumentation, le SSL pinning et l'obfuscation du code ou des chaînes.

Détection du shielding : le scan attaque ce qu'il trouve

Mobile Shielding Scan commence par analyser une application Android ou iOS pour identifier la détection du root et du jailbreak, les contrôles d'anti-falsification et d'intégrité, l'anti-débogage, l'anti-instrumentation, le certificate pinning et l'obfuscation du code ou des chaînes.

L'application est ensuite exécutée sur de vrais appareils pendant que le scan parcourt ses workflows pour atteindre les points où ces protections s'activent. C'est important, car certains contrôles ne se déclenchent qu'après l'authentification, pendant un paiement ou à l'ouverture d'une fonctionnalité sensible. Trouver le code sous-jacent ne suffit pas si la protection ne s'active jamais lors d'une utilisation réelle.

Le scan enregistre les protections qu'il identifie, l'endroit où elles sont implémentées et les conditions qui les déclenchent.

Contournement du shielding : tester si les contrôles tiennent

Une fois une protection atteinte, le scan tente de la mettre en échec. Cela peut inclure le repackaging ou la re-signature de l'application, l'attachement d'une instrumentation à l'exécution, la dissimulation d'indicateurs d'un appareil rooté, l'interception du trafic réseau, le patching du code de l'application et la manipulation des contrôles d'intégrité.

Des agents IA guident l'investigation en observant l'interface, en lisant les journaux et en interprétant la réponse de l'application. Un plantage, un avertissement, une requête bloquée, une sortie silencieuse ou une fonctionnalité qui cesse de fonctionner peut indiquer qu'une défense a réagi. Les agents utilisent ces indices pour choisir une autre technique et poursuivre le test.

L'application a continué de s'exécuter avec l'instrumentation Frida active, ce qui prouve que la protection détectée pouvait être contournée.

Chaque protection est marquée Secure lorsqu'elle réagit et tient, ou Hardening lorsqu'elle est absente, inactive ou contournée. Les défenses défaillantes s'accompagnent de preuves et d'étapes de contournement reproductibles, tandis que les protections efficaces sont confirmées par des tests actifs.

Comme chaque build peut modifier le résultat, les équipes peuvent répéter le scan d'une version à l'autre pour vérifier ce qui reste efficace dans l'application livrée.

Essayer le Shielding Scan d'Ostorlab

Conclusion

Le shielding des applications mobiles aide les équipes de sécurité à protéger les applications dans la partie de l'environnement qu'elles contrôlent le moins : l'appareil client. En rendant nettement plus difficiles la rétro-ingénierie, la falsification, la manipulation à l'exécution et le vol de données sensibles, il protège la logique, les transactions et les informations qui comptent le plus.

Alors que les applications mobiles continuent de gérer des paiements, l'identité, des dossiers de santé, du contenu premium et des workflows propriétaires, les attaques côté client restent un risque réel. Le shielding offre aux équipes un moyen de réduire ce risque en intégrant des protections directement dans l'application et en gardant ces défenses actives pendant son exécution.

Les meilleurs résultats viennent du fait de traiter le shielding comme une couche d'une stratégie de sécurité mobile plus large. Associé à une intégration précoce du shielding, à l'automatisation CI/CD, à la validation continue, à la surveillance et à des mises à jour régulières fondées sur le renseignement sur les menaces, il aide les équipes à créer des applications qui restent résilientes même dans des environnements hostiles.