Récemment, Google a fait des changements de sécurité qui assurent que réseau de sécurité contrôle des défauts lorsque Magisk est installé.
Ceci a été tweeté par John Wu (développeur Magisk) , ici y ici . Quelques extraits :
Après des années d'utilisation de Magisk, il semble que Google ait ENFIN décidé de "réparer" SafetyNet pour en faire quelque chose d'utile, à savoir utiliser l'attestation de clé pour vérifier le statut de l'appareil (après 3 ans d'introduction sur la plateforme Android !).
Regardons les choses en face. L'amusement est terminé les gars.
(C'est nous qui soulignons)
Editar: De Github
Désactiver MagiskHide par défaut
Puisque SafetyNet CTS est impossible à réaliser, laisser MagiskHide sur par défaut ne sert plus à rien.
Pour plus de détails concernant les derniers changements de SafetyNet, veuillez consulter : https://twitter.com/topjohnwu/status/1237656703929180160 https://twitter.com/topjohnwu/status/1237830555523149824
La fonctionnalité de MagiskHide continuera à exister au sein du projet Magisk car elle est toujours extrêmement efficace pour cacher les modifications dans l'espace utilisateur (y compris l'interface de base de SafetyNet). l'espace utilisateur (y compris le contrôle basicIntegrity de SafetyNet).
Améliorations futures de MagiskHide mai venir, mais depuis que le saint graal a été pris, toute forme d'amélioration est maintenant une priorité très basse.
Il me semble que Google aurait pu/devait mettre en place ce système plus tôt, mais qu'il ne l'a pas fait et que la vérification du CTS effectuée depuis Magisk n'était pas complète.
Veuillez démystifier cela en termes simples (dans la mesure du possible) pour les personnes qui ne comprennent pas les rouages d'Android (comme moi).
2 votes
Si je comprends bien les tweets, l'état de déverrouillage du chargeur de démarrage est maintenant déterminé par le code qui s'exécute dans le TEE, une partie de sécurité disponible dans la plupart des CPU ARM qui est renforcée contre la manipulation. Le code qui y est exécuté ne peut pas non plus être modifié. Ce code vérifie en quelque sorte l'état du bootloader et prépare les données signées envoyées à Google. Le serveur de Google décide alors si votre appareil passe ou non le contrôle.
0 votes
@Robert Oui, mais j'essaye de comprendre plus en termes de pourquoi maintenant Vs plus tôt quand apparemment le mécanisme était en place. De plus, la vérification du CTS était également effectuée par un serveur, mais il semble que ce soit Google. Comme dit, simplifier pour les nuls !
1 votes
D'après ce que j'ai compris, le principal problème est que la vérification du chargeur de démarrage a été déplacée dans le TEE et qu'elle ne peut être exécutée qu'à cet endroit (avant, elle était exécutée en dehors du TEE ?). TEE est comme un système d'exploitation séparé, nous n'avons pas de racine pour et il exécute uniquement du code signé. Par conséquent, vous ne pouvez pas modifier ou manipuler la vérification. Vous pouvez seulement décider de ne pas l'exécuter.
0 votes
D'une certaine manière, ce n'est pas encore vrai. Je suis sous Android 10, 5 March Security Update, Magisk et EdXposed installés. Et le SafetyNet passe toujours.
0 votes
@OtnielYoreiza oui, il a été signalé que les anciennes versions d'Android ne sont pas encore affectées dans certains cas. Je suis un peu surpris dans votre cas. Avez-vous essayé d'installer une application qui ne fonctionne pas si Safety Net est cassé - pour faire une double vérification (la vérification de Magisk est parfois défectueuse).