Un regard sur les complications de la racine de guimauve et de Verity

Alors que la poussière retombe sur Version Android 6.0, de nombreux utilisateurs de Nexus se lancent dans les OTA et Images d'usine, et préparez-vous pour la dernière itération du système d'exploitation Android.

Bien que, de l'extérieur, Android 6.0 semble (au moins visuellement) remarquablement similaire à Android 5.0 et 5.1 (les versions Lollipop), il y a un certain nombre de changements importants sur le marché. à l'intérieur. L’un d’eux a potentiellement ramifications pour la ROM personnalisée et les communautés racine. Tout d’abord, un peu de contexte. Si cela ne vous intéresse pas, passez simplement à « Pourquoi est-ce important ».

Une fonctionnalité appelée Verity

Le problème (c'est un problème si vous aimez rooter et modifier des périphériques) vient de quelque chose que j'ai souligné il y a longtemps, lors de son premier lancement sur AOSP - l'introduction de dm-verity vers Android

. Verity est une fonctionnalité de sécurité, trouvée à l'origine dans ChromeOS, conçue pour fournir des appareils informatiques garantis et fiables, empêchant les logiciels malveillants de modifier un appareil. De retour dans Android 4.4, Google a annoncé Verity pour Android, puis tout est resté silencieux. Bien qu'il y ait eu quelques recherche sur l'utilisation de la vérité, pour la plupart, les choses ont été calmes. Jusqu'à présent, c'est le cas.

Avec Android 6.0, Google a commencé à améliorer la sécurité des appareils. L'une des exigences fondamentales à cet égard est d'empêcher que le logiciel d'un appareil soit modifié à l'insu de l'utilisateur - alors que beaucoup ici chez XDA, prenez racine pour acquis, imaginez que l'appareil d'un utilisateur soit rooté à son insu ou sans son consentement, et que l'accès root soit utilisé pour voler son données. Pour cette raison, Google a commencé à mettre en œuvre la vérification de la partition système sur certains appareils. Ils ont également récemment mis à jour leur pages d'assistance pour couvrir cela.

Qu'est-ce que cela signifie pour les utilisateurs rootés ?

Avec la vérité en place, toute modification apportée à la partition système sera détectée au démarrage ou à l'accès. Vous serez alors confronté à l’une des erreurs vues ci-dessus. Certains vous permettent de continuer et d'autres veulent vous protéger en arrêtant le démarrage de l'appareil. Trois états sont disponibles. L'un d'entre eux s'affiche lorsque le chargeur de démarrage est déverrouillé, indiquant que vous pourriez courir un risque jusqu'à ce que vous reverrouilliez le chargeur de démarrage. C'est le cas puisqu'une image du noyau modifiée peut contourner la vérité, puisque le disque virtuel du noyau contient les clés utilisées pour vérifier l'état d'un système.

Les choses semblent plutôt peu amusantes pour les utilisateurs en herbe sur des appareils verrouillés.

L'état suivant est affiché (vraisemblablement) lorsque Verity est désactivé ou désactivé, ou ne peut pas être vérifié en raison de modifications apportées au disque virtuel. Je ne peux pas en être sûr, en raison de mon manque de Nexus 5X ou 6P sur lequel enquêter, mais mes soupçons (basés sur les messages) sont que si vous chargez une autre ROM, qui place ensuite son propre noyau sur l'appareil, la page "système d'exploitation différent" s'affichera apparaître.

L'état final est l'avertissement rouge indiquant que l'appareil est corrompu. Je soupçonne que cela signifie que l'image contient la vérité, mais la vérification a échoué en raison de la modification de l'image système. Encore une fois, nous ne pouvons pas en être sûrs sans matériel en main, mais cette erreur semble être celle que vous verrez si un périphérique d'origine a été modifié par un logiciel malveillant.

Pourquoi est-ce important?

Sur Android M (6.0), root nécessite actuellement que des modifications soient apportées à l'image du noyau, en plus du système de fichiers. Cela signifie que, même si nous ignorons la vérité (comme sur un ancien appareil Nexus comme un Nexus 7 2013), une nouvelle image du noyau est nécessaire pour contourner les protections SELinux qui empêchent l'accès root de fonctionner.

Si vous souhaitez rooter aujourd'hui, sur Android Marshmallow, vous devrez utiliser une image de démarrage modifiée.

Jusqu'à présent, il y a eu noyaux modifiés pour définir SELinux en mode permissif, mais ce n'est pas une solution idéale, car cela signifie que vous ne bénéficiez pas des avantages de sécurité de la protection SELinux. Et, après le Tracsaga, je suppose que vous pouvez voir les avantages de SELinux et d'autres protections contre les exploits de sécurité.

Développeur senior reconnu XDA, Tir à la chaîne, le maître de tout, Root a publié un version mise à jour de SuperSU qui conserve SELinux en mode d'application, mais nécessite encore une fois des modifications à la configuration SELinux de l'image de démarrage. Cela signifie que vous devez installer SuperSU, ainsi qu'une image de démarrage modifiée.

Et c'est très bien, jusqu'à ce que les transporteurs américains entrent dans le mix. Bastions du choix anti-consommateur, les piliers tels qu'AT&T et Verizon sont connus pour apprécier le verrouillage des appareils, empêchant les utilisateurs d'installer un micrologiciel personnalisé via les verrous de leur chargeur de démarrage. En effet, Verizon est particulièrement mauvais pour ne même pas transmettre les mises à jour du firmware aux utilisateurs, avec le Sony Xperia Z3v. non configuré pour recevoir de la guimauve tandis que le reste de la gamme Z3 (et bien sûr la gamme Z2) le fera. Bon sang, ils n'ont même pas encore déployé Lollipop sur l'appareil, bien qu'il soit disponible pour un certain temps (novembre 2014) sur le Z3 standard.

Au lieu d'un déverrouillage non officiel du chargeur de démarrage (ceux-ci sont assez rares de nos jours, à part les fuites de chargeurs de démarrage techniques pour quelques appareils Samsung), cela semble hautement improbable. que vous obtiendrez root sur Android 6.0 sans intervention divine - la combinaison de dm-verity (pour empêcher votre téléphone de démarrer avec toute modification apportée au partition système), et l'exigence de modifications SELinux dans le disque virtuel (pour permettre à root de fonctionner), semblent prêtes à rendre les choses plutôt peu amusantes pour les utilisateurs aspirants root de ces appareils verrouillés.

Android Pay ?

Enfin, Android Pay. Cela semble probablement sans rapport avec le reste de cet article, mais c’est en fait assez pertinent. Android Pay s'appuie sur le nouveau API SafetyNet dans le cadre de services exclusifs de Google, conçu pour fournir des attestations de l'état de l'appareil indiquant si un appareil est rooté, s'il est modifié d'une autre manière ou s'il fonctionne dans un état non approuvé.

Alors qu'il existe un projet en regardant les réponses d'usurpation d'identité à SafetyNet, cela nécessite actuellement un plugin Xposed, et cela ne semble pas susceptible de changer, compte tenu de son fonctionnement. Xposed nécessite root et apporte des modifications à la partition système. Cela rend cette opération difficile à réaliser sur un appareil verrouillé par le chargeur de démarrage. Même dans ce cas, des choses comme celle-ci entrent simplement dans un jeu du chat et de la souris avec Google. Avec SafetyNet, les appareils rootés (ou même les appareils modifiés) sont considérés comme « non conformes au CTS », ce qui est un euphémisme pour les appareils modifiés.

Il y a beaucoup plus d'écrits sur SafetyNet dans ce billet de blog de démontage, mais il semble certainement que nous puissions identifier certains domaines dans lesquels Google souhaite réprimer. Premièrement, ils n'aiment pas root, Xposed et tout ce qui modifie la partition système. Deuxièmement, il semble que Google envisage de détecter les utilisateurs pour lesquels le blocage des publicités est activé - la négociation SSL vérifie pubads.g.doubleclick.net me suggère certainement que Google veuille savoir si vous bloquez les publicités sur votre appareil. Considérant que root est généralement un pré-requis là-bas, mais que l'API VPN pourrait potentiellement être utilisée pour faire ceci sans racine, il semble que Google veuille au moins avoir une idée de qui (ou combien de personnes) bloque les publicités. Le blocage des publicités est un sujet d'actualité étant donné la volonté d'Apple de le prendre en charge dans le navigateur Web (sans doute pour encourager les gens utilisent davantage les applications, où ils contrôlent l'expérience et peuvent proposer des publicités non bloquables), et ces mouvements sont intéressant.

Conclusion

Si vous souhaitez rooter aujourd'hui, sur Android Marshmallow (6.0), vous devrez utiliser une image de démarrage modifiée. Bien qu'il reste à voir si cela reste vrai indéfiniment, cela devrait être le cas pendant un certain temps - les modifications de SELinux rendent beaucoup plus difficile l'obtention d'un accès root sans modifier l'image de démarrage. Et comme la modification de l'image de démarrage nécessite un bootloader déverrouillé, cela pourrait mettre fin au root (et à Xposed et autres fonctionnalités racine) sur les appareils livrés avec des chargeurs de démarrage qui ne peuvent pas être déverrouillés par les utilisateurs finaux. Dm-verity fait également son apparition et semble être activé en mode d'application sur les nouveaux appareils. Cela rendra difficile la modification de /system, même si vous obteniez un accès root, sans avoir à nouveau un chargeur de démarrage déverrouillé.

Cela change-t-il votre vision des appareils verrouillés par le chargeur de démarrage? Android a-t-il atteint le stade où vous achèteriez toujours un appareil verrouillé par le chargeur de démarrage si votre opérateur vous faisait une bonne affaire, ou êtes-vous uniquement intéressé par les appareils déverrouillés? Quelles applications ou fonctionnalités racine vous manqueraient sur un chargeur de démarrage verrouillé ?

N'hésitez pas à partager vos réflexions dans les commentaires ci-dessous.