SafetyNet vs API Play Integrity : réussir le test avec root (2026)

L’API SafetyNet, que la communauté du root Android connaît depuis dix ans, a été officiellement abandonnée par Google début 2024 et remplacée par l’API Play Integrity. Tous les guides écrits avant 2024 sont désormais périmés, et beaucoup de fausses informations circulent encore dans d’anciens fils de forum. Ce guide est la marche à suivre actuelle et pratique pour 2026 : ce qui a changé, ce que signifient réellement les trois verdicts de Play Integrity, quels outils de contournement fonctionnent en 2026, et les instructions de configuration pas à pas, avec les commandes Magisk précises. Il s’adresse aux utilisateurs avancés qui ont déjà un appareil rooté et doivent faire fonctionner leurs applications bancaires et de paiement.

Un bref historique : de SafetyNet à Play Integrity

SafetyNet (2014-2024) était l’API d’attestation d’appareil de Google. Elle renvoyait deux champs booléens : ctsProfileMatch (l’appareil correspond-il à un profil connu de la Compatibility Test Suite ?) et basicIntegrity (l’appareil passe-t-il les contrôles d’intégrité de base, comme l’état verrouillé du bootloader ?). Les applications bancaires l’appelaient via les services Google Play, récupéraient les deux booléens et refusaient de fonctionner si l’un des deux était faux. Les méthodes de contournement ont évolué pendant dix ans : d’abord MagiskHide, puis Zygisk + DenyList après l’abandon de MagiskHide dans Magisk 24, puis Shamiko par-dessus pour une dissimulation plus poussée.

L’API Play Integrity (depuis 2023) est le remplaçant officiel. Le calendrier de l’abandon :

• Juin 2023 : lancement de l’API Play Integrity comme remplaçant recommandé
• Mi-2023 à début 2024 : les applications commencent à migrer de SafetyNet vers Play Integrity
• Janvier 2024 : SafetyNet est officiellement abandonné ; les nouvelles réponses de l’API ne sont plus garanties
• À la mi-2026 : presque toutes les grandes applications bancaires et de paiement utilisent exclusivement Play Integrity

Play Integrity renvoie trois verdicts au lieu de deux booléens, et s’appuie sur l’attestation de clé matérielle pour son niveau le plus strict, ce qui le rend fondamentalement plus difficile à contourner avec des méthodes purement logicielles.

Les trois verdicts de Play Integrity expliqués

Chaque vérification Play Integrity renvoie trois valeurs booléennes :

MEETS_DEVICE_INTEGRITY

Le niveau de base. Il signifie que l’appareil exécute un Android non modifié, que les services Google Play sont installés et que les contrôles de compatibilité de base sont réussis. Contournable sur les appareils rootés avec les outils actuels (Magisk + Zygisk + DenyList + Shamiko + module Play Integrity Fix). Environ 60 % des applications exigent ce verdict pour fonctionner normalement.

MEETS_BASIC_INTEGRITY

Un contrôle plus strict qui ajoute des validations de l’environnement : intégrité des fichiers système, état attendu des services Google Play, certains contrôles de l’état de débogage. Le plus souvent contournable sur les appareils rootés, mais plus sensible à la configuration des modules. Environ 30 % des applications exigent ce verdict en plus de DEVICE_INTEGRITY. La plupart des applications bancaires exigent les deux.

MEETS_STRONG_INTEGRITY

Le niveau le plus difficile. Il utilise l’attestation de clé matérielle : le TEE (Trusted Execution Environment) de l’appareil signe une réponse qui peut être vérifiée jusqu’au certificat racine du constructeur. Cela fonctionne même quand le bootloader est verrouillé, car les clés sont protégées par l’élément sécurisé. Ne peut pas être contourné par les méthodes logicielles actuelles sur un appareil au bootloader déverrouillé, car le déverrouillage rompt la chaîne de démarrage vérifié sur laquelle reposent les clés du TEE.

Environ 10 à 20 % des applications exigent STRONG_INTEGRITY :

• Paiement sans contact Google Wallet dans certaines régions
• Plusieurs néobanques (Revolut, Wise, N26 dans certaines régions)
• Certaines applications d’identité officielle (passeports numériques, carte d’électeur)
• Applications de santé soumises à des exigences de conformité strictes
• Certaines applications professionnelles protégées par MDM fournies par l’employeur

Si vos applications essentielles exigent STRONG_INTEGRITY, le root est incompatible avec elles, et aucune solution actuelle n’y change rien.

Outils de contournement : Magisk Hide, Shamiko et TrickyStore

Trois outils principaux fonctionnent ensemble pour contourner Play Integrity en 2026 sur les appareils rootés :

Pas à pas : réussir Play Integrity pour les applications bancaires de base

Nous supposons que vous avez déjà :

• Un bootloader déverrouillé
• Magisk installé via un boot.img patché
• Un root fonctionnel vérifié dans Magisk Manager

Si ce n’est pas encore le cas, consultez d’abord notre guide de déverrouillage du bootloader et Magisk vs KernelSU vs APatch.

Étape 1 : activer Zygisk dans Magisk

Ouvrez l’application Magisk → Settings (icône d’engrenage) → activez l’option Zygisk. Redémarrez.

Après le redémarrage, retournez dans les Magisk Settings et activez Enforce DenyList.

Étape 2 : installer Shamiko

Téléchargez le dernier zip de Shamiko depuis les versions officielles de LSPosed/LSPosed sur GitHub. Dans l’application Magisk → onglet Modules → touchez l’icône + → sélectionnez le zip de Shamiko → installez. Redémarrez.

Après le redémarrage, vérifiez que Shamiko est chargé : application Magisk → onglet Modules → Shamiko doit apparaître dans la liste, activé.

Étape 3 : installer le module Play Integrity Fix

Téléchargez le dernier zip de PIF depuis les versions GitHub de chiteroman/PlayIntegrityFork (ou du fork actuellement maintenu : consultez les fils des Recognized Developers sur XDA pour les recommandations du moment).

Application Magisk → Modules → + → installez le zip de PIF → redémarrez.

Étape 4 : remplacer l’empreinte PIF par une empreinte qui passe actuellement

L’empreinte à l’intérieur de PIF doit correspondre à un appareil connu qui passe Play Integrity en ce moment. Le module PIF inclut un script de mise à jour automatique. Ouvrez une application de terminal (Termux convient) et lancez :

su -c sh /data/adb/modules/playintegrityfix/action.sh

Cette commande récupère la dernière empreinte valide maintenue par la communauté et l’applique. Redémarrez.

Étape 5 : configurer la DenyList pour vos applications

Application Magisk → Configure DenyList → cherchez chaque application bancaire, de paiement ou vérifiant Play Integrity que vous devez utiliser. Touchez le bouton à côté de chaque application pour activer le masquage. Les entrées de sous-processus s’activent généralement toutes seules.

Applications courantes à ajouter :

• Votre application bancaire principale (HDFC, SBI, Bank of America, Lloyds, etc.)
• Applications de mobile money (bKash, GCash, M-Pesa, JazzCash)
• Applications de paiement (Google Pay, PayPal, Venmo, Cash App)
• Applications de courtage (Robinhood, Zerodha, Groww)
• Applications gouvernementales (DigiLocker, Aadhaar, application NHS)
• Applications de streaming avec DRM (Netflix, Disney+, Amazon Prime : elles vérifient Play Integrity pour le HD/4K)

Étape 6 : vérifier avec Play Integrity API Checker

Installez Play Integrity API Checker depuis le Play Store (plusieurs versions existent ; essayez celle de gkkang ou celle maintenue par l’équipe LSPosed).

Ouvrez-la. Touchez Check. Repérez :

• MEETS_DEVICE_INTEGRITY : devrait être true
• MEETS_BASIC_INTEGRITY : devrait être true
• MEETS_STRONG_INTEGRITY : sera false sur un appareil au bootloader déverrouillé, c’est normal

Si DEVICE et BASIC renvoient tous deux true, le contournement fonctionne au niveau du verdict. La plupart des applications bancaires et de paiement fonctionneront maintenant normalement.

Étape 7 : tester chaque application bancaire séparément

Ouvrez chaque application l’une après l’autre. Vérifiez qu’elle dépasse l’écran de démarrage et vous laisse vous connecter. Si l’une d’elles échoue :

1. Vérifiez que l’application est activée dans la DenyList
2. Relancez la commande de mise à jour automatique de PIF pour actualiser l’empreinte
3. Redémarrer
4. Si elle échoue toujours, cette application utilise peut-être une détection supplémentaire en plus de Play Integrity : essayez TrickyStore comme couche additionnelle, ou acceptez que l’application soit incompatible avec votre configuration root actuelle

Quand des applications échouent malgré un verdict réussi

Certaines applications utilisent des vecteurs de détection supplémentaires, au-delà de l’API Play Integrity officielle :

• Analyse directe des fichiers : recherche de /system/bin/su, des chemins des binaires Magisk ou des chemins d’installation connus des modules. Solution : activer le masquage de fichiers de Magisk, l’équivalent de MagiskHide (intégré aux versions récentes).
• Inspection des espaces de noms de processus : vérification de /proc/self/status et d’éléments similaires pour repérer des signatures de hooks Zygisk. Solution : Shamiko règle la plupart des cas.
• Défis d’attestation TEE indépendants de Play Integrity. Solution : TrickyStore pour certaines applications ; impossible pour d’autres.
• Listes de blocage propres à l’application, maintenues par son développeur et incluant des noms de paquets connus liés au root. Solution : renommer l’application Magisk via Settings → Hide the Magisk app, avec un nom qui ne ressemble pas à Magisk.

État des applications bancaires par pays : ce qui marche aujourd’hui sur Android rooté

Le comportement des applications bancaires varie énormément d’une région à l’autre, car chaque banque choisit son propre niveau d’exigence pour le contrôle d’intégrité. D’après les retours de clients sur les marchés BD/IN/PK/UK jusqu’en 2026 :

Bangladesh

• bKash : fonctionne avec Magisk + Shamiko + PIF pour la plupart des utilisateurs ; une mise à jour de l’empreinte est parfois nécessaire après les mises à jour de Google
• Nagad : fonctionne avec la même pile ; un peu plus sensible à la fraîcheur de l’empreinte
• Rocket (DBBL) : fonctionne avec la pile standard
• Applications de City Bank, BRAC Bank, EBL, Dutch-Bangla Bank : la plupart fonctionnent avec la pile standard ; à revérifier après chaque mise à jour de Play Integrity
• Paiement sans contact propre à la banque : exige généralement STRONG_INTEGRITY ; non contournable sur les appareils rootés

Inde

• Google Pay (Tez) : l’UPI fonctionne avec la pile standard ; le paiement sans contact (dans les régions prises en charge) exige STRONG_INTEGRITY
• PhonePe, Paytm : l’UPI fonctionne avec la pile standard
• HDFC, ICICI, SBI YONO, Axis Mobile : la plupart fonctionnent ; HDFC et Axis sont un peu plus stricts et peuvent exiger TrickyStore pour certaines fonctions
• Applications de courtage (Zerodha Kite, Groww, Upstox) : fonctionnent avec la pile standard
• Application Aadhaar mAadhaar : fonctionne pour la plupart des fonctions ; les fonctions biométriques peuvent exiger une configuration de masquage supplémentaire

Pakistan

• JazzCash, Easypaisa : les deux fonctionnent avec la pile standard pour la plupart des utilisateurs
• HBL Mobile, UBL Digital, Meezan Bank Mobile : la plupart fonctionnent ; Meezan est la plus stricte des trois
• NayaPay, SadaPay (néobanques) : variable ; vérifiez avant de compter sur le root pour elles

Royaume-Uni et UE

• La plupart des applications des grandes banques de détail (Lloyds, Barclays, HSBC, Santander, NatWest) : fonctionnent avec la pile standard à la mi-2026
• Néobanques (Revolut, Wise, N26, Monzo) : Revolut et Wise sont réputées très strictes et exigent souvent STRONG_INTEGRITY dans certains parcours ; Monzo et Starling sont généralement plus souples
• Équivalents Apple/Google du paiement sans contact : exigent STRONG_INTEGRITY ; non contournables

Cette liste reflète la situation au moment de la rédaction et évolue régulièrement. Testez toujours vos applications avant de compter sur le root pour un usage financier urgent.

Ce que STRONG_INTEGRITY implique vraiment au niveau du TEE

Un peu de contexte technique, pour les utilisateurs avancés, sur la raison pour laquelle STRONG_INTEGRITY ne peut fondamentalement pas être contourné sur un appareil au bootloader déverrouillé.

Les appareils Android modernes intègrent un Trusted Execution Environment (TEE), un processeur sécurisé distinct, avec sa propre mémoire et son propre système d’exploitation, isolé de l’Android principal. Le TEE contient des clés cryptographiques propres à l’appareil, provisionnées en usine et signées par l’autorité de certification racine du constructeur.

Quand une application demande STRONG_INTEGRITY, la requête passe par le TEE, qui signe une réponse avec ces clés provisionnées en usine. La réponse inclut l’état actuel du démarrage vérifié : une chaîne de hachages qui prouve que le bootloader est verrouillé et que les partitions boot, system et vendor correspondent à ce que le constructeur a signé.

Quand vous déverrouillez le bootloader, le TEE fait passer l’état de démarrage vérifié à « jaune » (clés installées par l’utilisateur) ou « orange » (pas de démarrage vérifié). Le TEE signera toujours les réponses STRONG_INTEGRITY, mais la réponse indiquera explicitement l’état déverrouillé. Les applications qui exigent STRONG_INTEGRITY contrôlent ce champ et refusent de fonctionner dès que l’état n’est pas vert (bootloader verrouillé, chaîne de démarrage signée par le constructeur).

Un contournement logiciel ne peut pas falsifier cela, car le TEE signe avec des clés auxquelles l’Android principal n’a pas accès. TrickyStore peut intercepter l’appel au keystore avant qu’il n’atteigne le TEE et le remplacer par une réponse « valide » préenregistrée d’un appareil similaire, ce qui fonctionne pour certaines applications qui ne valident pas correctement l’origine matérielle de la réponse, mais les applications qui la valident (les plus strictes) détecteront la substitution.

Les seuls moyens fiables de réussir STRONG_INTEGRITY :

• Utiliser le boot.img du firmware d’origine avec le bootloader reverrouillé. Certains appareils (Pixel, certains OnePlus) permettent de reverrouiller le bootloader après le flash d’images signées par le constructeur. Cela rétablit STRONG_INTEGRITY, mais fait perdre le root.
• Utiliser un second appareil non rooté pour le petit nombre d’applications qui exigent STRONG_INTEGRITY.

Il n’existe pas de troisième option cachée. La conception du TEE vise précisément à l’empêcher.

Ce que nous ne recommandons jamais

• Faire tourner plusieurs modules de contournement de Play Integrity en même temps sans raison précise : ils entrent souvent en conflit et cassent plus d’applications qu’ils n’en réparent.
• Utiliser des forks PIF au hasard, de sources inconnues. Tenez-vous au fork principal maintenu et consultez les fils XDA pour la recommandation du moment.
• Compter sur le contournement pour des opérations financières à forte valeur. Utilisez un appareil de secours non rooté pour les montants que vous ne pouvez pas vous permettre de perdre, et lisez les conditions d’utilisation de votre banque sur la responsabilité en cas de fraude sur un appareil rooté.
• Activer le root pour le Play Store lui-même. Le Play Store n’a pas besoin d’être dans la DenyList ; l’y mettre peut casser des fonctions du Play Store sans aucun avantage.

Quand faire appel à un professionnel

Si une application bancaire précise refuse de fonctionner après l’installation du root et que vous avez essayé la pile standard, écrivez-nous sur WhatsApp ou Telegram. Nous disposons de configurations vérifiées et éprouvées pour la plupart des grandes banques des marchés BD, IN, PK, UK, US et UE, et nous pouvons généralement remettre une application en marche en une session à distance de 30 à 60 minutes. Consultez notre service de root Android pour le détail de ce qui est inclus.

Pour les détails au niveau des modules derrière DenyList et Shamiko, notre guide des modules Magisk couvre la pile actuelle de masquage de Play Integrity et les forks encore maintenus.