Root basique android

EDITION: Méthode plus synthétique et générique et introduction de busybox (optionnel).

J’ai decidé d’activer l’accés root sur mon Xperia Active (que j’ai depuis hier).
La motivation: ce téléphone ne gère pas l’EAP-SIM hardware et je dois modifier un fichier de conf pour l’activer. Je pourrais ainsi me connecter au reseau freewifi de manière transparente.

ATTENTION: La plupart des tutos proposent de configurer un accés root type windows ou ubuntu avec gksudo
J’ai preferé me contenter d’un accés “possible” via su en commande puisqu’ occasionnel: modification d’un fichier de conf.
Mon support: pocketables.com/2011/06/how- … evice.html
La différence c’est que je n’installe pas superuser (couche graphique à su. equivalent à gk|ksudo) et busybox.

J’essaie de détailler un maximum pour que chacun puisse adapter à sa manière.
En resumé, pour les systèmes android, ça fait:
-obtenir l’accés root via une faille
-passer le système en lecture/ecriture, ecrire ce qui nous interesse, le repasser en lecture seule.

C’est parti!

Preparation:
Le telephone doit être en mode debogage usb (proprièté/applications/developpement) et la carte SD ne doit pas être montée sur le PC.

Sur le PC, on a besoin de:

  • android-tools-adb (exclusivité sid pour l’instant -> pinning).
    Permet, entre autres, d’ouvrir un shell qui communique avec le système du telephone.
  • DooMLoRD_v4_ROOT-zergRush-busybox-su.zip (google): Contient les fichiers qui permettront l’accés root + un .bat qu’il suffit de transposer à linux (ce qui est fait et détailler ici). Le nom de l’archive et peu engagant mais le forum xda-developpers me semble serieux.

Etape 1 (adb et 1er accés root):
Les chemins d’accés sont à adapter. Dans mon exemple, je me place à l’endroit où j’ai decompressé l’archive. En root!

  • adb devices lance le deamon et permet de verfifier que le telephone est bien présent
  • adb push copie les binaires sur le telephone (mémoire interne par défaut) dans un des seuls endroits accessibles en écriture.
  • chown et chmod change le propriétaire.groupe et les permissions.
    Je me sers dans l’exemple de Busybox (voir bas de page) que l’on peut éventuellement intégrer au système par la suite.

[code]# adb devices
sans root, le telephone n’est pas vu chez moi -> voir N.B
je pense que l’on peut se passer de l’invite root à partir d’ici

adb push files/zergRush /data/local/tmp

adb push files/busybox /data/local/tmp

adb shell

On se retrouve sur android en utilisateur.
$ cd /data/local/tmp
$ chmod 777 zergRush
$ chmod 755 busybox
$ ./zergRush
[/code]
Si vous êtes ejecté du shell, c’est normal. Relancez adb shell.
Si tout va bien on se retrouve avec une invite root sous android. C’est temporaire mais on en profite -> étape 2.

Etape 2 (installation de su et autres):
Gràce à l’accés root, on remonte le système de fichier du telephone en lecture/ecriture.
On place su et on lui donne les droit d’execution.
Le système de fichier est ensuite repassé en lecture seule.

[code]# cd /data/local/tmp
On appelle mount implémenté par busybox (plus souple que celui fourni par android)

busybox mount -o remount,rw /system

Pour installer busybox (optionnel):

dd if=/data/local/tmp/busybox of=/system/xbin/busybox

chown root.shell /system/xbin/busybox

chmod 04755 /system/xbin/busybox

/system/xbin/busybox --install -s /system/xbin

Cette dernière ligne crée les liens vers les implémentations plus complètes de busybox:
mount
revient à faire
busybox mount

exit

adb push files/su /system/bin

adb shell

chown root.shell /system/bin/su

chmod 06755 /system/bin/su

rm /system/xbin/su

ln -s /system/bin/su /system/xbin/su

rm /data/local/tmp/*

exit

Installation de Superuser (optionnel):

adb push files/Superuser.apk /system/app/.

adb reboot[/code]

FINI!

Pour verifier:

[code]# adb shell
$ su

-> on est root sous android[/code]

FINI!

ADB (Android Data Bridge): Permet d’installer de manipuler votre système android à distance. C’est pratique pour éditer des fichiers de conf sans être obliger de passer par le terminal et le clavier de votre téléphone.

BUSYBOX: regroupe des implémentations simples des outils de base pour systèmes UNIX-Like. Sans lui le shell d’android est vraiment rude.

N.B: Il est peut être possible de demarrer adb en simple user en modifiant les regles udev.

Toujours bon à savoir.

Up.

J’ai finalement réussi à “rooter” mon smartphone (Motorola Defy+), et ce fût un jeu d’enfant (pas 36 manips dégueulasses…)

merci qui?

merci à Framaroot :041
forum.xda-developers.com/showthr … ?t=2130276
korben.info/rooter-telephone-and … ateur.html

Le phone étant “rooté”, que faire? Et bien déjà :

à suivre :stuck_out_tongue:

tester des ROMs alternatives comme Cyanogen (la pus connu, mais sujette à polémique en ce mmoment)

Quelle polémique?

oui effectivement quelle polémique?

J’ai une rom cyanogen mais il y a quand même un truc qui me gène beaucoup:

on a accès au fichier /data/misc/wifi/wpa_supplicant.conf et il a dedans le pass du wifi en claire :12

C’est pareil sur ta machine. Le mot de passe doit pouvoir être reconstitué car il ne s’agit pas d’un processus d’authentification mais de construction d’une clef de décodage, si tu n’as pas la clef, tu ne décodes rien. Il n’est pas possible de se limiter à un hachage de la clef.

bonjour françois

je le trouve où sur ma machine?
j’utilise network-manager-gnome.

Berk… Regarde sous /var/run et /var/lib je pense, tu as deux façons de le stocker. Soit sous forme précalculée via wpa_passphrase (SSID+clef), sous sous forme directe. Ça peyut être aussi sous sous /etc par exemple dans /etc/NetworkManager/system-connections. Je charcherais d’abord là.

ah oui tu as raison je trouve la clé dans /etc/NetworkManager/system-connections/monwifi

À noter que Linux Deploy fait partie des solutions à base de chroot. Perso je ne trouve pas ça pratique, à peine mieux qu’un double boot : Linux ne peut pas accéder facilement aux données et périphériques Android, à moins de se coltiner des points de montage à réaliser depuis Android à chaque changement.
C’est pas pour vendre ma soupe (je n’ai fait que traduire un tuto existant :wink:) mais les solutions comme Debian Kit à base de bind-mount me paraissent plus intéressantes même si, évidemment, c’est un poil plus délicat quand tu as une ROM custom (les ROM constructeur sont “clean” – à ce niveau du moins – y’a pas du tout de GNU dessus donc pas de conflit). Disons simplement que l’intégration est bien meilleure. :slightly_smiling:

Je testerai ça :wink:

En fait tout est parti de la non-intégration par défaut de l’application “Focal” dans la ROM Cyanogen.
Je vous invite à lire l’interview du développeur pour plus d’explication.

Pour faire court, Cyanogen essaye de monétiser la solution, ce qui n’est absolument pas gênant. Par contre ce sont les moyens utilisés qui sont plus critiquables. Alors que tous les développements étaient sous GPL depuis le départ, ils tentent par tous les moyens de faire changer les licences des logiciels dontl’équipe principale n’est pas propriétaire et transférer le copyright au projet Cyanogen si possible. C’est le cas de “Focal”, et comme le dev a refusé de changer la licence, il y a eu rupture.

En fait il y a de gros risque que Cyanogen passe en sources fermées, en partie ou complètement. Le fait que Cyanogen ai monté une boite avec des fonds d’investissements n’est surement pas innocent dans les choix politiques.

Il est dommage qu’un tel projet qui a joué le jeu des logiciels libre, semble passer du coté obscure de la force :scared-ghostface:

« Ça va forker » :unamused:

Un projet omnirom est en cours avec des anciens de Cyanogen.