La majeure partie de votre question est couverte dans Documentation sur Magisk . Je vais citer un de mes réponses précédentes à une autre question, avec quelques inutile détails :)
PREREQUIS :
Pour bien comprendre le fonctionnement de Magisk, il faut avoir des notions de base :
- Contrôle d'accès discrétionnaire ( DAC )
- Les identifiants des utilisateurs (
[ESR]UID ), set-user-ID
-
Capacités de Linux (processus et fichier) qui fournissent un contrôle fin sur les permissions du super utilisateur
- Contrôle d'accès obligatoire ( MAC )
- SELinux sur Android
- L'utilisation des espaces de noms par Android pour les Permissions de stockage
- Fixer le support
- Processus de démarrage d'Android, partitions et systèmes de fichiers
- Android
init services (le tout premier processus lancé par le noyau)
- Fichiers *.rc
- Structure de
boot partition (noyau + DTB + ramdisk), Device Tree Blobs DM-Verity ( Démarrage vérifié d'Android ), chiffrement complet du disque / chiffrement par fichier ( FDE/FBE ) etc.
Qu'est-ce que la racine ?
Obtenir les privilèges Root signifie exécuter un processus (généralement un shell) avec l'UID zéro (0) et toutes les capacités de Linux, de sorte que le processus privilégié puisse contourner tous les contrôles de permission du noyau.
Les privilèges du super-utilisateur sont obtenus généralement en exécutant un binaire qui a soit :
C'est ainsi que su y sudo travailler sur Linux dans un DAC UNIX traditionnel. Les utilisateurs non privilégiés exécutent ces binaires pour obtenir les droits Root.
Il s'agit de la méthode la moins utilisée.
Dans les deux cas, le processus appelant doit avoir toutes les capacités de son ensemble limitatif (l'une des 5 catégories de capacités qu'un processus peut avoir) pour avoir de véritables privilèges Root.
COMMENT Android RESTRICTE L'ACCÈS au Root ?
Jusqu'à Android 4.3, on pouvait simplement exécuter un set-user-ID-root su pour élever ses permissions à l'utilisateur Root. Cependant, il y avait un certain nombre de Améliorations de la sécurité dans Android 4.3 qui a cassé ce comportement :
- Android est passé à des capacités de fichiers au lieu de s'appuyer sur
set-user-ID type de failles de sécurité. Un mécanisme plus sûr : Capacités ambiantes a également été introduit dans Android Oreo.
- Les démons et les services du système peuvent utiliser les capacités des fichiers pour obtenir des capacités de processus (voir la rubrique Transformation des capacités pendant l'exécution ) mais les applications ne peuvent pas non plus le faire car le code de l'application est exécuté par
zygote avec attribut de contrôle de processus NO_NEW_PRIVS en ignorant set-user-ID ainsi que des capacités de classement. SUID est également ignoré par le montage /system y /data con nosuid pour toutes les applications.
- L'UID ne peut être commuté que si le processus appelant a SETUID/SETGID dans son ensemble limitrophe. Mais les applications Android sont conçues pour fonctionner avec toutes les capacités déjà déposées dans tous les ensembles en utilisant l'attribut de contrôle du processus.
CAPBSET_DROP .
- À partir d'Oreo, la possibilité pour les applications de modifier l'UID/GID a été encore supprimée par bloquer certains appels système en utilisant filtres seccomp .
Étant donné que le système autonome su a cessé de fonctionner avec la sortie de Jelly Bean, une transition a été faite vers le mode su daemon . Ce démon est lancé au cours du démarrage et traite toutes les demandes de superutilisateur faites par les applications lorsqu'elles exécutent l'option spéciale su binaire ( 1 ) . install-recovery.sh (situé sous /system/bin/ o /system/etc/ ) qui est exécuté par un service init pré-installé flash_recovery (inutile pour les aventuriers ; récupération des mises à jour après une installation OTA) a été utilisé pour lancer ce démon SU au démarrage.
El prochain défi majeur a été confronté lorsque SELinux était réglé strictement enforcing avec la sortie d'Android 5.0. récupération flash a été ajouté à un contexte SELinux restreint : u:r:install_recovery:s0 qui a arrêté le pure l'accès au système. Même l'UID 0 ne pouvait effectuer qu'un ensemble très limité de tâches sur le dispositif. La seule option viable était donc de démarrer un nouveau service avec un accès illimité au système. SUPER CONTEXTE par Parcheando la politique SELinux. C'est ce qui a été fait (temporairement pour Lollipop ). ( 2 , 3 ) et ensuite de façon permanente pour Marshmallow) et c'est ce que fait Magisk.
COMMENT FONCTIONNE MAGISK ?
Flashing Magisk nécessite généralement un appareil avec bootloader déverrouillé afin que boot.img pourrait être modifié dynamiquement à partir d'une récupération personnalisée ( 4 ) ou une version pré-modifiée boot.img ( 5 ) pourrait être flashé/démarré, par exemple à partir de fastboot .
En outre, il est possible de lancer Magisk sur une ROM en cours d'exécution si vous obtenez les privilèges Root en utilisant un exploit dans le système d'exploitation. ( 6 ) . Cependant, la plupart de ces failles de sécurité ont été corrigées au fil du temps. ( 7 ) .
En outre, en raison de certaines vulnérabilités au niveau du SoC (telles que celle de Qualcomm Mode EDL ), le chargeur de démarrage verrouillé peut être piraté pour charger une image de démarrage/récupération modifiée, ce qui brise l'intégrité du système. La chaîne de confiance . Il ne s'agit toutefois que d'exceptions.
Une fois que le dispositif démarre à partir d'une version corrigée boot.img Dans le cas de Magisk, un démon Magisk entièrement privilégié (avec UID : 0, capacités complètes et contexte SELinux non restreint) fonctionne dès le début du processus de démarrage. Quand une application a besoin de l'accès Root, elle exécute le démon Magisk (/sbin/)su binaire (mondain accessible par DAC et MAC ) qui ne change pas l'UID/GID de lui-même, mais se connecte simplement au démon via un socket UNIX. ( 8 ) et demande de fournir à l'application requérante un shell Root avec toutes les capacités. Afin d'interagir avec l'utilisateur pour accorder/refuser su de la part des applications, le démon est connecté à l'application Magisk Manager qui peut afficher les invites de l'interface utilisateur. Une base de données ( /data/adb/magisk.db ) des permissions accordées/refusées est construit par le démon pour une utilisation future.
Processus de démarrage :
Le noyau d'Android démarre init avec SELinux dans permissive au démarrage (avec quelques exceptions ). init charges /sepolicy (ou politique de fractionnement ) avant de démarrer tout service/daemon/processus, le définit enforcing et passe ensuite à son propre contexte. A partir de là, même init n'est pas autorisé par la politique à revenir en mode permissif ( 9 , 10 ) . La politique ne peut pas non plus être modifiée, même par l'utilisateur root. ( 11 ) . Par conséquent, Magisk remplace /init avec un fichier personnalisé init qui corrige les règles de politique SELinux avec SUPER CONTEXTE ( u:r:magisk:s0 ) et définit le service pour lancer le démon Magisk avec ce contexte. Ensuite, l'original init est exécuté pour continuer le processus de démarrage ( 12 ) .
Travail sans système :
Depuis le init est construit dans boot.img il est inévitable de le modifier et /system la modification devient inutile. C'est là que le systemless Le terme a été inventé ( 13 , 14 ) . La principale préoccupation était de faciliter les OTAs - re-flasher les boot (et la récupération) est moins compliquée que le re-flash. system . OTA par blocs sur une version modifiée /system La partition échouera parce qu'elle permet l'utilisation de dm-verity pour signer cryptographiquement le system partition .
System-as-Root :
Sur les appareils plus récents utilisant système-as-Root le noyau ne se charge pas ramdisk から boot mais de system . Donc [system.img]/init doit être remplacé par celui de Magisk init . Magisk modifie également /init.rc et place ses propres fichiers dans /root y /sbin . Cela signifie system.img doit être modifié, mais l'approche de Magisk est de ne pas toucher à system partition.
Sur A/B les périphériques pendant le démarrage normal skip_initramfs est passée par le chargeur de démarrage dans la ligne de commande du noyau en tant que boot.img contient ramdisk pour la récupération. Donc Magisk patche le binaire du noyau pour toujours ignorer skip_initramfs c'est-à-dire démarrer en récupération, et place Magisk init binaire dans la récupération ramdisk à l'intérieur de boot.img . Au démarrage, lorsque le noyau démarre en mode de récupération, s'il n'y a pas d'erreur d'affichage, le système ne peut pas être utilisé. skip_initramfs c.-à-d. l'utilisateur a intentionnellement démarré à la récupération, puis Magisk init exécute simplement la récupération init . Sinon, system.img est monté à /system_root par Magisk init , contenu de ramdisk sont ensuite copiés dans / nettoyage de tout ce qui existait auparavant, les fichiers sont ajoutés/modifiés dans rootfs / , /system_root/system est monté en liaison avec /system et enfin [/system]/init est exécuté ( 15 , 16 ) .
Cependant, les choses ont encore changé avec Q, maintenant /system est monté à / mais les fichiers à ajouter/modifier comme /init , /init.rc y /sbin sont recouverts de supports de fixation ( 17 ) .
Sur non-A/B system-as-root les appareils, Magisk doit être installé pour la récupération ramdisk afin de conserver une approche sans système, car boot.img ne contient pas ramdisk ( 18 ) .
Modules :
Un avantage supplémentaire de systemless est l'utilisation de Magisk Modules . Si vous voulez placer certains binaires sous /system/*bin/ ou modifier certains fichiers de configuration (comme hosts o dnsmasq.conf ) ou certaines bibliothèques/fichiers d'infrastructure (comme ceux requis par des mods tels que XPOSED ) en /system o /vendor vous pouvez le faire sans toucher à la partition en utilisant la fonction Monture magique (sur la base des montages de reliure). Magisk permet d'ajouter et de supprimer des fichiers en les superposant.
MagiskHide : ( 19 )
Un autre défi consistait à masquer la présence de Magisk afin que les applications ne puissent pas savoir si l'appareil est enraciné. De nombreuses applications n'aiment pas les appareils enracinés et peuvent cesser de fonctionner. Google a été l'un des principaux concernés, et a donc introduit SafetyNet dans le cadre de Play Protect qui s'exécute en tant que processus GMS (Play Services) et qui indique aux applications (y compris à leurs propres Google Pay ) et donc leurs développeurs que l'appareil est actuellement dans un état non altéré ( 20 ) .
Le Rooting est l'un des nombreux états tempérés possibles, les autres étant le Boot non vérifié, le bootloader déverrouillé, la non-certification CTS, la ROM personnalisée, la construction débuggable, permissive SELinux, ADB activé, quelques mauvais la présence de Lucky Patcher, Xposed, etc. Magisk utilise quelques astuces pour s'assurer que la plupart de ces propriétés ne sont pas modifiées. tests passe toujours, bien que les applications puissent utiliser d'autres API Android ou lire directement certains fichiers. Certains modules fournissent une obfuscation supplémentaire.
En plus de dissimuler sa présence dans le réseau SafeyNet de Google, Magisk permet également aux utilisateurs de dissimuler le système Root ( su et tout autre fichier lié à Magisk) à partir de n'importe quelle application, en utilisant à nouveau les montages liés et les espaces de noms de montage. Pour cela, zygote doit être surveillé en permanence pour les VM des applications nouvellement bifurquées.
Toutefois, il n'est pas facile de dissimuler réellement un appareil enraciné aux applications, car de nouvelles techniques évoluent pour détecter la présence de Magisk, principalement à partir des éléments suivants /proc ou d'autres systèmes de fichiers. Ainsi, un certain nombre de les bizarreries sont faites pour prendre en charge correctement la dissimulation des modifications à la détection . Magisk essaie de supprimer toutes les traces de sa présence pendant le processus de démarrage. ( 21 ) .
Magisk prend également en charge :
-
Désactivation de
dm-verity y /data cryptage en modifiant fstab (en ramdisk , /vendor o DTB ). Voir Comment désactiver dm-verity sur Android ?
-
Modification des propriétés en lecture seule en utilisant resetprop outil, Modifier
boot.img en utilisant magiskboot y Modifier la politique SELinux en utilisant magiskpolitique .
-
Exécution de scripts de démarrage en utilisant
init.d -mécanisme similaire ( 22 ) .
C'est une brève description des fonctionnalités actuellement offertes par Magisk (AFAIK).
POUR EN SAVOIR PLUS :
