12 votes

beeshyams avatar

Magisk échouera à Safety-Net par la suite. Pourquoi ?

Demandé el 12 de Mars, 2020
Quand la question a-t-elle été
6634 affichage
Nombre de visites la question a
2 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

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).

Demandé el 12 de Mars, 2020 par beeshyams

2 votes

Avatar de pr0nin

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.

Commenté el 12 de Mars, 2020 par pr0nin

0 votes

Avatar de beeshyams

@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 !

Commenté el 12 de Mars, 2020 par beeshyams

1 votes

Avatar de pr0nin

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.

Commenté el 12 de Mars, 2020 par pr0nin
Afficher 2 autres commentaires

Réponses

Trop de publicités?

6voto

beeshyams avatar
beeshyams Points 37355

Voici les dernières informations (au 30 août 21) sur le filet de sécurité. Quels sont les changements dans Magisk ?

John Wu (Développeur Magisk) a posté mises à jour aujourd'hui qui clarifie les raisons.

Auparavant, l'API de SafetyNet n'était pas entièrement / correctement mise en œuvre, comme elle était censée l'être :

D'après ce que nous avons vu jusqu'à présent, l'attestation de clé ne semble pas être pleinement appliquée Pourtant, les appareils dotés d'implémentations de keymaster incompatibles et potentiellement boguées ( ?) (par exemple, certains appareils OnePlus) qui entraînent des échecs de commande de clé d'attestation passent quand même SafetyNet.

Le bootloader rapporte l'état du périphérique via les lignes de commande du noyau, et init les reflète dans les propriétés, et apparemment SafetyNet utilisait ces valeurs. Tous ces éléments sont dans l'espace utilisateur, donc Magisk peut simplement le manipuler

Maintenant, avec le Aperçu des fonctionnalités : Évaluation de l'API d'attestation SafetyNetType il y aura deux types d'évaluation, BASIC y HARDWARE_BACKED pour une évaluation complète avec validation à distance (par rapport au local) :

HARDWARE_BACKED - Lorsque nous utilisons les fonctions de sécurité matérielles disponibles de l'ordinateur. dispositif à distance (par exemple, l'attestation de clé soutenue par du matériel) pour influencer notre évaluation.

Nous sommes actuellement en train d'évaluer et d'ajuster les critères d'éligibilité pour les dispositifs où nous nous appuierons sur des dispositifs de sécurité adossés à du matériel.

Ce nouveau système peut-il être piraté ?

Cela semble très improbable

Il est théoriquement possible de modifier le flux de contrôle dans le code de SafetyNet pour le forcer à toujours utiliser l'évaluation BASIC en utilisant un cadre d'accrochage comme Xposed. fondamentalement impossible à cacher (analyse de l'espace mémoire).

Pour pirater ce truc, vous devez soit trouver un vulnérabilité dans le firmware du TEE (qui sera corrigé dès que possible une fois trouvé) ou le matériel (moins susceptible de se produire) pour casser la cryptographie.

Il ne sera pas facile de casser le TEE, c'est pourquoi de nombreux chercheurs en sécurité y travaillent activement.

(Soulignement ajouté dans toutes les citations)

Comment vérifier si Google a mis en place l'attestation matérielle pour mon appareil ?

Modifier Le canari Magisk a été mis à jour pour montrer le statut d'évaluation et une fois que l'API sera implémentée, vous verrez plus de détails (à défaut de SafetyNet). Ou, suivez les instructions sur ce post XDA pour vérifier la méthode d'attestation en utilisant logcat

enter image description here

Pour plus d'informations, voir Avec l'attestation matérielle de SafetyNet, il sera très difficile de cacher Root dans Magisk.

Édité le 16 décembre 20

Et le dernier clou du cercueil pour la détection des filets de sécurité.

Johnwu en

L'évaluation basée sur le HW n'est pas pratique à "hacker" (sauf des astuces pour le faire revenir à la base), et j'ai perdu tout intérêt à améliorer la façon actuelle de cacher.

  • Un autre tweet du 13 décembre 2020

Si passer SafetyNet est la seule utilisation de Magisk pour vous, alors oui, bye Face avec les yeux qui roulent ( en réponse à Donc... magisk est complètement inutile en ce moment ?... )

Répondu el 29 de Juin, 2020 par beeshyams (37355 Points )

0 votes

Avatar de Gokul NC

Si j'ai un appareil avec un bootloader déverrouillé, mais pas encore enraciné (c'est-à-dire boot est stockée), mon appareil échouera-t-il quand même à l'épreuve de la HARDWARE_BACKED contrôle d'attestation ? Ce serait formidable si vous pouviez modifier votre réponse pour inclure cela.

Commenté el 1 de Juillet, 2020 par Gokul NC

0 votes

Avatar de beeshyams

@Gokul NC Bien sûr que non ! Sauf si votre appareil n'est pas autorisé par le CTS, ce qui ne sera pas le cas, sauf si vous avez un appareil très bon marché.

Commenté el 1 de Juillet, 2020 par beeshyams

0 votes

Avatar de Gokul NC

Bon, j'ai un autre doute ; excusez mon ignorance. Disons que mon appareil a échoué au test SafetyNet HARDWARE_BACKED contrôle. Maintenant, mon application bancaire essaye d'invoquer le SafetyNet Attestation en utilisant une méthode qu'elle possède. Que se passe-t-il si j'écris un hook Xposed pour intercepter la méthode de mon application bancaire qui est responsable de l'appel de l'API de vérification de l'attestation, et que je modifie le codepath de la méthode pour que l'application évite d'appeler l'API d'attestation SafetyNet elle-même ?

Commenté el 1 de Juillet, 2020 par Gokul NC
Afficher 5 autres commentaires

2voto

auspicious99 avatar
auspicious99 Points 495

Il semble que Google ait choisi de ne pas appliquer cette vérification, même si elle a été mise en œuvre pendant une courte période (quelques jours ?). Au début, le développeur de Magisk, John Wu, semblait assez pessimiste à ce sujet, allant même jusqu'à dire que le plaisir était terminé.

Quelques jours après les tweets de John Wu mentionnés dans la question, cependant, le 14 mars, John Wu a tweeté à nouveau et cette fois, il a dit

Donc, apparemment, la CTS passe de nouveau de nulle part ? Peut-être que Google teste encore des choses ?

J'en ai fini de toute façon. Google est apparemment prêt à utiliser l'attestation de clé pour la détection. Puisque MagiskHide est toujours là, les gens peuvent toujours l'utiliser comme d'habitude.

Dans mon propre test fin mai 2020, avec MagiskHide non activé, SafetyNet a échoué, mais avec MagiskHide activé et en ciblant mon application de test, SafetyNet a réussi, ce qui signifie que MagishHide pouvait encore vaincre SafetyNet. Le test a été effectué sur un Pixel 3 avec Android 10.

Ainsi, Google peut avoir la capacité de détecter Magisk, puisque la vérification du chargeur de démarrage a été déplacée dans le TEE, mais ils ont en quelque sorte arrêté de le faire, pour des raisons connues seulement de Google.

Répondu el 31 de Mai, 2020 par auspicious99 (495 Points )

1 votes

Avatar de beeshyams

Veuillez consulter répondre ici pour les mises à jour

Commenté el 29 de Juin, 2020 par beeshyams

0 votes

Avatar de auspicious99

Merci, j'ai aussi vu le tweet de John Wu aujourd'hui qui pointait vers groups.google.com/forum/#!topic/safetynet-api-clients/

Commenté el 29 de Juin, 2020 par auspicious99

Questions connexes

Questions en vedette

Top Tags

Dans notre réseau

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X