Utilisez Custom Fingerprint/Build.Prop pour réussir le test d’intégrité de jeu

2023/12/06

Dans ce guide, nous allons vous montrer deux méthodes différentes pour créer des empreintes digitales/build.prop personnalisées afin de réussir le test d’intégrité de lecture sur votre appareil rooté ou si vous exécutez une ROM personnalisée. Eh bien, il semble que nous puissions enfin atteindre le bout du chemin en ce qui concerne l’obtention de privilèges administratifs. Pour ceux qui ne le savent pas, si vous rootez votre appareil, il déclenchera le test SafetyNet, rendant ainsi difficile l’utilisation des applications bancaires et de paiement.

Intégrité de la lecture des empreintes digitales Build.Prop

Cependant, nous avons réussi à trouver une solution de contournement qui nous a permis de réussir facilement ce test. Cette année, Google a introduit le test d’intégrité Play et a demandé à chaque application d’intégrer son API d’ici janvier 2025. Au moment de la rédaction de cet article, de nombreuses applications bancaires et de paiement ont déjà migré vers ce test.

Comme auparavant, si votre appareil est rooté, vous échouerez à ce test, ce qui entraînera votre incapacité à utiliser les applications bancaires. Heureusement, nous avons encore une fois réussi à mettre la main sur une méthode pour contourner ce test. Google est ensuite allé plus loin et a corrigé notre réglage uniquement pour que nous puissions le contourner une fois de plus ! Jusqu’à maintenant. Le géant de la Silicon Valley a finalement pris la mesure la plus extrême à ce jour, ce qui pourrait bien sonner le glas des passionnés de technologie.

Google « interdit » les empreintes digitales pour l’intégrité du jeu : est-il impossible de cacher la racine ?

Jusqu’à présent, nous pouvions utiliser le module XDA Senior Member Chiteroman pour réussir facilement les MEETS_DEVICE_INTEGRITY et MEETS_BASIC_INTEGRITY, qui sont deux prérequis. du test d’intégrité de jeu. Avec le recul, le module utilise une empreinte digitale de l’un des appareils non corrigés et le développeur télécharge ensuite son mod sur GitHub. Puisque ce mod est open source, tout le monde peut facilement le décoder, y compris Google ! Et c’est exactement ce qui se passe.

Même s’il peut sembler difficile de comprendre pourquoi Google finirait par utiliser une partie de ses ressources pour ce projet qui ne concerne qu’environ 3 % des utilisateurs d’Android, mais croyez-nous, c’est exactement ce qui se passe actuellement. Le développeur a essayé de nombreuses combinaisons d’empreintes digitales dans ses modules, y compris différents OEM, différentes versions d’Android et même différentes ROM personnalisées [telles que Evolution X].

Cependant, chaque fois qu’un nouveau module est publié, Google a tendance à le corriger immédiatement, laissant ainsi au développeur trois options : soit continuer à utiliser cette méthode d’essais et d’erreurs, rendre le module fermé ou lister les instructions sur la façon dont un utilisateur peut créer un fichier d’empreintes digitales personnalisé et l’utiliser pour réussir ce test.

La première approche n’était ni la plus réalisable ni la plus viable pour lui [car il ne gagnait rien avec cela et, plus important encore, il vivait aussi dans cette communauté de moddeurs !]. De même, en faire une source fermée aurait pu faire sourciller certains utilisateurs [bien qu’à en juger par sa réputation, cela ne devrait pas arriver en premier lieu]. Désormais, la troisième option est notre meilleure option.

Comment créer et utiliser une empreinte digitale/Build.Prop personnalisée pour transmettre l’intégrité du jeu

Il existe plusieurs méthodes pour effectuer ce travail : la méthode automatique et la méthode manuelle. Dans la méthode automatique, vous devrez toujours effectuer la première étape de la méthode manuelle, mais elle se chargera ensuite du reste des étapes. De plus, veuillez effectuer une sauvegarde au préalable, juste pour être plus sûr. Droidwin et ses membres ne sauraient être tenus responsables en cas de guerre thermonucléaire, si votre alarme ne vous réveille pas ou si quelque chose arrive à votre appareil et à vos données en suivant les étapes ci-dessous.

Méthode en un clic [la plus simple]

Eh bien, nous ne remercierons jamais assez Chiteroman pour cela ! Il vient de sortir une version plug-and-play de ce module qui serait la méthode la plus simple et la meilleure pour opter pour les utilisateurs génériques. Tout ce que vous avez à faire est de vous procurer ce module v14.2 de GitHub, d’activer Zygisk, de le flasher via Magisk et de supprimer les données des services Google. Framework, Play Store, Play Service et Play Protect Service [le cas échéant]. Voici un guide détaillé sur le même sujet, il est fortement recommandé de le consulter.

Méthode automatique [recommandée]

Pour commencer, récupérez le fichier build.prop à partir de la version ROM + firmware souhaitée comme expliqué dans la première étape de la méthode manuelle ci-dessous.
Ensuite, téléchargez et extrayez les outils de la plate-forme Android SDK sur votre PC.
Téléchargez maintenant Pixel Flasher depuis GitHub et lancez-le [crédits : XDA Recognized Developer badabing2003].
Cliquez ensuite sur Parcourir > accédez au dossier platform-tools et sélectionnez-le.
Cliquez maintenant sur Scan et sélectionnez votre appareil dans la liste. Cliquez ensuite sur Magisk.
Cliquez sur Process build.prop pour naviguer et sélectionner le fichier build.prop du donateur.
Il générera un fichier JSON, copiera le contenu et remplira les données manquantes [le cas échéant].
Cliquez sur le bouton Modifier pif.json pour modifier le fichier sur votre téléphone et collez ce que vous avez obtenu à l’étape ci-dessus.
Téléchargez et installez maintenant Play Integrity API Checker depuis le Play Store.
Sélectionnez ensuite la même application dans l’outil et cliquez sur le bouton Play Integrity Check.
Cela fera apparaître les résultats. Vérifiez si votre appareil réussit ce test [il vous suffit de réussir les deux premiers tests].
Si ce n’est pas le cas, utilisez un autre build.prop et réessayez les étapes jusqu’à ce que vous réussissiez ce test [il n’y a pas d’autre issue].

Méthode manuelle [Difficile]

Osmosis, développeur senior reconnu par XDA, a pris cette responsabilité sur ses épaules et a fait un excellent travail en énumérant les étapes à suivre pour créer et utiliser un custom.pif.json. Voici les étapes d’instructions pour cela :

Tout d’abord, téléchargez la ROM d’origine pour un périphérique aléatoire [voir ci-dessous], extrayez-la et récupérez les fichiers build.prop du système *et/ou* le build.prop du produit *et* les fichiers build.prop du fournisseur. Nous ou XDA ne pouvons pas partager ces fichiers publiquement car Google les récupérera et les interdira tous en masse en même temps [cela vient de se produire avec un appareil Asus. Nous avons réussi à obtenir une empreinte digitale non corrigée de l’un des appareils Asus et à l’utiliser pour réussir le test d’intégrité de jeu. Cela a fonctionné pendant quelques jours avant d’être finalement corrigé par Google !].

Concernant « un appareil aléatoire » que nous avons mentionné ci-dessus, assurez-vous de garder les points suivants à l’esprit avant de télécharger sa ROM :
Tous les anciens appareils Nexus (Nexus 6/shamu et versions antérieures) semblent être interdits.
Les versions finales de ROM de tous les appareils Nexus et Pixel restants qui ne sont plus pris en charge sont interdites.
L’appareil doit avoir au moins été mis à niveau vers Oreo (Android 8) et doit être livré avec au moins une version Android 6 ou supérieure prête à l’emploi.
Les appareils lancés avec Pie (Android 9) ou version ultérieure peuvent ne pas fonctionner.
En un mot, essayez de choisissez une combinaison d’un appareil et de sa ROM que vous pensez que peu de gens choisiront. Ceci C’est parce que « moins les données statistiques évidentes que Google reçoit indiquant qu’une empreinte digitale particulière est utilisée abusivement, moins les empreintes digitales seront interdites » .

Parlons maintenant de l’emplacement de build.prop, product et supplier.prop. Dans le cas de build.prop, il peut être trouvé dans /system/system/build.prop ou /system/build.prop. Le produit peut être /product/build.prop et/ou /product/etc/build.prop. Le fournisseur se trouve dans /vendor/build.prop ou/system/vendor/build.prop.

En général, ce seront ro.build.fingerprint + ro.product.* (ancien système build.prop), ou ro.system.build.fingerprint + ro.product.system.* (système plus récent build.prop) [ou, ro.product.build.fingerprint + ro.product.product.* (product build.prop, nécessaire uniquement sur les appareils sur lesquels le système build.prop contient des valeurs « génériques »).

À partir de là, vous devrez copier les six valeurs suivantes : PRODUIT (ro.*.name), DEVICE (ro.*.device), MANUFACTURER (ro.*.manufacturer), BRAND (ro.*.brand), MODÈLE (ro.*.model) et EMPREINTE DIGITALE (ro.*.fingerprint). Facultativement, copiez également SECURITY_PATCH (ro.build.version.security_patch à partir du système build.prop)

Collez maintenant les valeurs copiées entre les guillemets des champs correspondants dans l’exemple de modèle custom.pif.json présenté ci-dessous [c’est juste un exemple qui a déjà été interdit par Google. Assurez-vous donc de remplacer les valeurs en conséquence].

{ "PRODUCT": "taimen", "DEVICE": "taimen", "MANUFACTURER": "Google", "BRAND": "google", "MODEL": "Pixel 2 XL", "FINGERPRINT": "google/taimen/taimen:8.1.0/OPM4.171019.021.R1/4833808:user/release-keys", "SECURITY_PATCH": "2018-07-05", "FIRST_API_LEVEL": "26" }

Enfin, copiez votre. json dans /data/adb/modules/playintegrityfix/custom.pif.json puis flashez ce module via Magisk [qui est un fork pour l’original Jouer au module Integrity Fix]. Ou transférez-le vers le fichier /data/adb/pif.json, flashez le module Play Integrity Fix d’originee et redémarrez votre appareil. Votre appareil devrait maintenant « espérons-le » réussir le test d’intégrité de jeu à l’aide de ce fichier d’empreinte digitale/build.prop personnalisé ! Si ce n’est pas le cas, vous devrez choisir une autre empreinte digitale et réessayer ce processus.

Rooting et ROM personnalisées : un voyage difficile mais réalisable !

Même si nous avons toujours cru à la devise « partager, c’est prendre soin », pour une fois, ne l’adoptons pas dans ce scénario. Si vous obtenez une empreinte digitale fonctionnelle et que vous finissez par la partager avec le reste des utilisateurs, elle sera finalement corrigée par Google. Alors gardez ce build.prop unique avec vous et évitez qu’il ne soit capturé par Google !