Comment faire pour rooter manuellement un téléphone ?

J'ai regardé les résultats de recherche sur le web de "comment faire pour rootter manuellement des appareils Android" et j'ai remarqué que la plupart d'entre eux ne sont que de la publicité ou utilisent des solutions de rootage dédiées (en particulier des sources fermées). Celles qui fonctionnaient il y a quelque temps sont désormais obsolètes car elles dépendaient de certaines vulnérabilité de la sécurité dans Android, qui a été corrigée au fil du temps.

En fait, il n'est pas impossible de déverrouiller le téléphone manuellement, mais cela n'en vaut pas la peine. Cependant, à titre de référence, permettez-moi de décrire une option. Mais avant de plonger dans les détails techniques, nous devons comprendre ce qui suit ce qu'est la racine y Comment Android empêche l'accès à la racine . Les détails peuvent être trouvés aquí mais quelques points en bref :

• La plupart des fournisseurs livrent leurs appareils avec un chargeur de démarrage verrouillé, et une chaîne de confiance est établie pendant le processus de démarrage, ce qui ne permet pas de modifier le noyau ( boot.img ), la récupération ou le système d'exploitation principal. La première étape vers l'enracinement est donc la suivante bootloader déverrouillé . Méfiez-vous de la risques !

• Une partie de la chaîne de confiance est dm-verity ( VB / AVB ) ; un phénomène basé sur le noyau qui garantit que les partitions contenant le cœur du système d'exploitation ( /system , /vendor , /odm ) sont toujours montés en lecture seule et toute tentative malveillante de les modifier doit échouer. La modification des boot.img o recovery.img s'accompagne généralement de désactivation dm-verity afin d'éviter des surprises telles que des boucles de démarrage à des stades ultérieurs. L'avertissement standard de TWRP :

  Ce dispositif utilise dm-verity !
  Cela signifie que si vous autorisez les modifications du système, vous ne pourrez pas démarrer si vous utilisez le noyau d'origine.

• De même, certains fournisseurs, en particulier Samsung, vont au-delà de la normale et intègrent des fonctions de sécurité supplémentaires dans leurs appareils, telles que Knox, RKP, Defex, proca, TIMA, FIPS, bla bla bla. Il se peut donc que vous deviez contourner ces dispositifs, par exemple en construisant un noyau avec la fonction SECURITY_SELINUX_DEVELOP=y , Parcheando binaire du noyau, etc.

• Les applications Android n'ont pas la possibilité d'élever leurs privilèges en exécutant des binaires qui ont setuid ou le jeu de capacités de fichiers (ce qui est la façon standard d'obtenir l'accès à la racine). La seule option est donc de lancer un processus persistant en arrière-plan (démon) avec des privilèges de racine en dehors des applications (par exemple pendant le processus de démarrage) et de lui demander d'effectuer des tâches privilégiées pour le compte des applications non privilégiées lorsque cela s'avère nécessaire.

• Root (c'est-à-dire l'UID 0) est l'ancien contrôle d'accès discrétionnaire (DAC), mais Android utilise également le contrôle d'accès obligatoire (MAC), c'est-à-dire SELinux. Un processus racine s'exécutant dans un contexte SELinux restreint est assez impuissant, nous devons donc également briser cette barrière. Pour cela, il faut modifier la politique SELinux.

J'aborderai ici les deux derniers points, mais les deux premières considérations :

• Les solutions de rootage d'Android déploient une su qui, lorsqu'il est exécuté par une application, établit une connexion avec un démon privilégié et lui fournit un shell Root. Ainsi, ce su Le binaire et le démon sont spécialement développés à cet effet. Une approche moins sophistiquée consisterait à utiliser des démons déjà disponibles comme adbd , sshd ou l'un des anciens inetutils saveurs ( telnetd , rlogind , rshd , rexecd ) avec les privilèges de root. Lorsqu'ils fonctionnent en arrière-plan, ces serveurs peuvent fournir un shell Root ou exécuter des commandes avec les privilèges Root lorsqu'ils sont connectés par un client. Par souci de simplicité, je n'utilise qu'un utilitaire réseau minimal appelé netcat ( nc ) qui est un boîte à outils applet. Mais il convient de noter que Cette approche ne permet pas d'obtenir l'accès à la racine. il ne peut être utilisé qu'à partir de la ligne de commande.
• Nous allons patcher le monolithe /sepolicy et /init.rc qui font partie de ramdisk en boot.img . Mais en commençant par Treble Android utilise politique de fractionnement qui est chargé/compilé à partir de /system/etc/selinux/ y /vendor/etc/selinux/ . En commençant par SAR il n'y a pas de ramdisk du tout en boot.img y /init.rc fait partie de system.img . Dans les deux cas, il faut donc nécessairement modifier system partition. Je ne donnerai pas de détails à ce sujet ici.

ÉTAPES :

• Extrait boot.img par exemple en utilisant AIK o magiskboot sur Android ou PC.

• Créer un nouveau contexte SELinux, par exemple pseudo_su . Définissez-le comme permissif afin d'autoriser toutes les interactions possibles avec d'autres processus/fichiers, etc. Utilisez la fonction supolicy ou sepolicy-inject ( 1 , 2 ) sur Android ou PC :

  ~# supolicy --load sepolicy --save sepolicy 'create pseudo_su' 'permissive pseudo_su' 'dontaudit pseudo_su * * *' 'allow pseudo_su * * *' 'allow * pseudo_su * *'

  Ou de construire split-policy mit Le compilateur d'Android :

  ~# /system/bin/secilc -m -M true -G -N -c $(cat /sys/fs/selinux/policyvers) -o sepolicy /system/etc/selinux/plat_sepolicy.cil /system/etc/selinux/mapping/$(cat /vendor/etc/selinux/plat_sepolicy_vers.txt).cil $([ -f /vendor/etc/selinux/vendor_sepolicy.cil ] && echo /vendor/etc/selinux/vendor_sepolicy.cil /vendor/etc/selinux/plat_pub_versioned.cil || echo /vendor/etc/selinux/nonplat_sepolicy.cil)

  * Obtenir la valeur de POLICYDB_VERSION_MAX de votre source du noyau .

  Pour utiliser les precompiled_sepolicy ou construire à partir de split-policy et de la rustine :

  ~# supolicy --load-split --save sepolicy 'create pseudo_su' 'permissive pseudo_su' 'dontaudit pseudo_su * * *' 'allow pseudo_su * * *' 'allow * pseudo_su * *'

• Définir un init service qui démarre un simple serveur TCP au démarrage, n'écoutant que les connexions sur l'appareil :

  # /init.rc
  ...
  service pseudo_su /sbin/busybox nc -lk -s 127.0.0.1 -p 23 -e /sbin/busybox sh
      seclabel u:r:pseudo_su:s0
      disabled
  
  on property:sys.boot_completed=1
      start pseudo_su

  * Assurez-vous d'obtenir la bonne busybox binaire, il existe de multiples mises en œuvre de netcat .
  * Utiliser le port 23 ou tout autre port non utilisé.

• Copie mise à jour sepolicy y init.rc à la racine du disque dur extrait, busybox binaire à [ramdisk/]sbin/ et définir les autorisations.

• Repack boot.img et flasher ou tester avec fastboot boot boot.img .

COMMENT EXÉCUTER LES COMMANDES ROOT ?

Une fois démarré, nous pouvons passer des commandes à partir d'un fichier netcat sur un émulateur de terminal (comme Termux) ou adb shell :

~$ echo id | /sbin/busybox nc localhost 23
uid=0(root) gid=0(root) groups=0(root) context=u:r:pseudo_su:s0

* La politique SELinux par défaut ne permet pas aux applications de traverser les frontières. /sbin . Il s'agit donc soit d'injecter des règles d'autorisation, soit de mettre en place des busybox en /system/*bin/ . Ou utiliser d'autres nc par exemple de Termux netcat l'emballage.

Pour faciliter l'utilisation, créez des fonctions (placez-les dans le répertoire .bashrc afin de ne pas avoir à le définir à chaque fois) :

# ~/.bashrc
...
function psu() { echo "$@ 2>&1" | /sbin/busybox nc localhost 23; }
function psush() { /sbin/busybox nc localhost 23; }

~$ ls -ld /data/adb
ls: cannot access '/data/adb': Permission denied
~$ psu ls -ld /data/adb
drwx------ 7 root root 3488 2019-07-19 00:44 /data/adb

Pour obtenir le shell Root :

~$ psush
whoami
root
^C

Mais ce n'est qu'un coquille muette n'est pas connectée à la borne. Pour une expérience plus riche en fonctionnalités, d'autres outils tels que socat peuvent être utilisés pour prendre en charge l'édition de lignes, les pseudo-terminaux, etc.
De plus, les variables d'environnement ne sont pas évaluées à moins d'être explicitement transmises, car les commandes sont exécutées à distance :

~$ /data/data/com.termux/files/usr/bin/ps -p $$,1 -o pid=,comm=
23599 bash
~$ psu /data/data/com.termux/files/usr/bin/ps -p $$,1 -o pid=,comm=
CANNOT LINK EXECUTABLE "/data/data/com.termux/files/usr/bin/ps": library "libprocps.so" not found
~$ psu LD_LIBRARY_PATH=/data/data/com.termux/files/usr/lib /data/data/com.termux/files/usr/bin/ps -p $$,1 -o pid=,comm=
    1 init
23599 bash

C'est ainsi que nous pouvons obtenir une fonctionnalité minimale de racine sans utiliser d'outils de racine spécialisés.

RELATED :

• Comment SuperSU assure-t-il le privilège de la racine ?