Correction : j'ai modifié cet article car le système pour rendre le rootage permanent ne fonctionnait pas !
Niveau :
Résumé : adb shell
Il y a peu je me suis offert un téléphone android. Devinez quoi ... c'est un linux (pas GNU pour une fois, plutôt un dalvik/linux).
Seule ombre au programme, je ne suis pas root dessus. C'est pas très fair play de la part du vendeur sachant que le téléphone m'appartient. Comment faire pour supprimer les applications installées par le fabriquant et qui me cassent les *** à se lancer sans me demander mon avis ?
Ma première mission est donc de devenir root.
Les habitués des OS de bureau auront l'idée de toucher au bootloader pendant qu'il boote. Bonne idée, mais sur une telle machine le bootloader est assez sobre, et plutôt protégé, ne parlons pas du bios. J'ai donc ignoré cette technique pour passer à une méthode plus courantes pour les bidouilleurs de tout poil : exploiter une faille de sécurité.
C'est donc grâce aux failles de sécurité que je vais avoir le droit d'accéder au système de ma propre machine ! Autrement dit, c'est parce que le fabriquant protège mal le système qu'il m'a vendu que mes droits de consommateur sont respectés ...
Les bases
Passons aux bases du téléphone, c'est un linux, mais il ne faut pas s'attendre à avoir tous les outils en ligne de commande auxquels vous êtes habitués. Pour obtenir un shell utilisateur simple (ça vous avez le droit) :
- installer le sdk android (une simple extraction)
- aller dans les paramètres / application / développement et activer le débogage USB
- branchez le câble
- sur le pc dans sdk/platform-tools lancez ./adb devices, votre téléphone doit être listé sinon il y a un problème
- tapez ./adb shell et hop vous êtes sur votre téléphone
Là on est sur un terrain presque connu : un shell, qui tourne avec l'utilisateur shell. Il est limité, mais on s'y fait. Par contre l'arborescence est inhabituelle. Je vous laisse explorer ... Pour mémoire, voici les répertoires à la racine :
/acct # accounting /bin # comme unix /cache # contenu temporaire /config # vide chez moi /d # debug /data # /var d'unix /dev # comme unix /etc # comme unix /init # comme unix /init.rc # comme unix /misc # vide chez moi /mnt # comme unix /proc # comme unix /root # comme unix /sbin # comme unix /sdcard # partition fat visible aux utilisateurs /sys # comme unix /system # partition readonly contenant le système android /usbdisk # vide chez moi
Les android étant personnalisés par le constructeur, votre version variera nécessairement.
Les failles (pour passer root)
Maintenant on veut passer de shell à root. Il est temps de passer du côté hacking de la force. Ceux qui se sentent l'âme d'un hacker expérimenté peuvent chercher eux-même les failles dans le système. Les autres vont tenter les 2 ou 3 failles connues avec les exploits associés :
- dépôt d'un fichier suid root exécutable, nommé su (il parait que ça marche sur certaines machines, je ne vois pas comment ...)
- exploid
- rageagainstthecage
- psneuter
Le binaire et les source de ces exploits sont disponibles ici.
En général il s'agit de le mettre dans un répertoire inscriptible et permettant les exécutables puis de le lancer. Il semblerait que /data/local/tmp soit disponible un peu partout pour ça.
Dans mon cas (optimus 2X) c'est psneuter qui fonctionne. Pour les autres, dites moi ce qui marche chez vous, je n'ai pas assez d'argent pour tester tous les android :)
$ ./adb push psneuter /data/local/tmp $ ./adb shell $ chmod 555 /data/local/tmp/psneuter $ /data/local/tmp/psneuter
On attend, on relance un adb shell et miracle on est root !
Busybox
Maintenant installons un environnement un peu plus user-friendly :
- télécharger busybox
- installer busybox :
$ ./adb push busybox /data/local/tmp $ ./adb shell $ chmod 555 /data/local/tmp/busybox $ mkdir /data/busybox $ /data/local/tmp/busybox --install $ export PATH=/data/busybox:$PATH
Et voila ! Une vraie ligne de commande sur notre petite machine. On peut maintenant découvrir l'os et faire joujou comme on veut.
Rendons tout ça permanent
N'ayant pas trouvé de su compilé qui marche sur mon android et ayant la flemme de compiler moi-même, j'ai fait avec les moyens du bord. Ma méthode d'origine était de mettre en place un shell setuid. Malheureusement, le shell vérifie que sont uid correspond à son euid et si ce n'est pas le cas il revient en arrière. J'ai été abusé par le fait qu'il affiche tout de même un #. Ce comportement, naturel pour un script ne l'est pas nécessairement pour un shell interactif mais c'est un fait.
J'ai donc fait avec les moyens fournis par busybox :
$ mount -o remount,rw /system $ mkdir /system/bb # /system/bin/su existe déjà $ cp /data/busybox/su /system/bb $ chmod 4550 /system/bb/su $ echo 'root::0:' > /etc/group # /etc est dans /system $ echo 'root::0:0:root:/root:/system/bin/sh' > /etc/passwd $ passwd # si vous voulez un vrai mot de passe $ mount -o remount,ro //system # retour à la normale
Après le prochain reboot, pour devenir root (avec un mot de passe) :
$ ./adb shell $ /system/bin/su
Note : Revenir en arrière est l'affaire de quelques suppression (/data/busybox, /system/bin/su, /etc/passwd et /etc/group). Vous n'avez donc rien fait de violent à votre téléphone, vous avez maitrisé ce que vous avez fait et c'est presque invisible.
Sécurité : A tous ceux qui rootent leur android en passant par une application toute faite, savez-vous ce que fait cette application dans votre dos ? Ne fait-elle pas autre chose que vous faire passer root ? Savez-vous qu'elle installe un binaire su permettant à n'importe quelle application (et pas seulement SuperUser.apk) de passer root si elle connait l'existence de ce binaire ...
On me dit que lors de son premier lancement SuperUser.apk se met lui-même en setuid et enlève le setuid du binaire su. Ce qui du coup vous retire le root avec adb.
PS : Message personnel à Bob Morane, j'ai rien compris à ta suggestion, dans quelle situation y a-t-il des liens qui se chevauchent ?
Loading ...
Comments