Pourquoi le binaire su ne peut-il pas être simplement copié (réponse technique s'il vous plaît)

J'ai rooté plusieurs appareils Samsung et le "but" sous-jacent semble être de récupérer le subinaire /system/xbinet d'installer Superuser.apk .

Ma question est pourquoi faut-il sauter à travers tous ces cerceaux pour rooter le téléphone (installer une récupération personnalisée et flash ROM pré-enracinée ou exploiter l'installation actuelle)? Ne pourrait-on pas simplement télécharger un su précompilé, le déplacer sur la carte SD et l'exécuter via adb? Ce qui semble rendre une ROM «pré-enracinée», c'est qu'elle a le superutilisateur et le binaire su dans leurs chemins système respectifs. Je ne vois pas pourquoi il est si important de s'en échapper /system/xbin.

— user974896
source

Réponses:

Le binaire su a besoin à la fois de l'exécution et du jeu de bits d'autorisation setuid. Le premier est nécessaire pour que le fichier puisse être exécuté et le second est qu'il s'exécute automatiquement avec les droits du propriétaire du fichier (définir l'ID utilisateur ou setuid. Dans ce cas, le propriétaire est root. En savoir plus ici ).

Les fichiers sur le stockage externe n'ont pas les bits d'autorisation exécutable et setuid définis et il ne peut pas être accordé sans droits root. Notez également que la carte SD est montée avec le drapeau 'noexec' pour empêcher généralement l'exécution au démarrage:

shell@android:/sdcard $ ./su
/system/bin/sh: ./su: can't execute: Permission denied
126|shell@android:/sdcard $ chmod 4755 su
Unable to chmod su: Operation not permitted
10|shell@android:/sdcard $ mount | grep /mnt/sdcard
/dev/block/mmcblk0p1 /mnt/sdcard vfat [...],noexec,[...]

C'est essentiellement pourquoi vous ne pouvez pas simplement copier susur la carte SD, puis l'exécuter pour vous accorder la racine.

— eldarerathis
source

C'est donc la seule chose qui empêche l'enracinement, le fait que / sdcard n'est pas exécutable et que vous ne pouvez pas chmod? Une fois que su est à l'endroit approprié où il peut être exécuté, votre golden est exécutable. Je pense qu'il y aurait une couche de sécurité pour empêcher quelqu'un d'exécuter simplement su. Sur mon serveur et sur la boîte Debian, je ne peux pas simplement exécuter su en tant qu'utilisateur normal, on me demande un mot de passe. Je suppose que l'hypothèse est que si l'on peut installer su, ils peuvent écraser le fichier fantôme pour changer le mot de passe?

— user974896

@ user974896: Eh bien il n'y a nulle part ailleurs pour un utilisateur non-système pour le mettre qu'il peut être exécuté, et Android n'a même pas un passwdou des shadowfichiers de toute façon. Vous avez littéralement besoin de root pour mettre sudans un emplacement exécutable, c'est pourquoi les méthodes d'enracinement impliquent soit un exploit d'escalade de privilèges, soit une récupération personnalisée (où tous les paris sont fondamentalement désactivés).

— eldarerathis

Oui. Telle est la réponse.

— Android Quesito

@ user974896: en plus de la carte / sdcard montée sur noexec, l'appel système setuid ne peut être appelé que lorsque le bit d'autorisation suid est défini dans l'exécutable, et l'appel système chown et chmod permettra uniquement à root de définir le bit setuid d'un fichier appartenant à root (en fait, seul root peut créer un exécutable pouvant s'exécuter avec les privilèges root). Tout le monde peut appeler su, mais à moins que l'appelant ne soit autorisé à le faire dans la base de données de Superuser (ou sous Linux traditionnel, dans la base de données passwd / shadow), l'appel ne réussira pas. Seule l'application Superuser (et les processus privilégiés) peuvent modifier la base de données Superuser.

— Lie Ryan

@ user974896: Cela, en plus du système de sécurité normal dans Android dans lequel chaque application Dalvik s'exécute en tant que son propre utilisateur, signifie que les applications que seule l'application dans la liste blanche de Superuser peut escalader vers la racine sans invite, tout le monde sera refusé (si c'est dans la liste noire), ou obligera le superutilisateur à demander l'autorisation à l'utilisateur.

— Lie Ryan

L'enracinement implique d'exploiter la faiblesse en fonction de la version d'Android, donc " sauter à travers tous les cerceaux pour rooter le téléphone "

C'est un poulet et un œuf!

Pour exploiter root, vous avez besoin d'un démon adb non sécurisé (c'est-à-dire la possibilité de remonter /system) sur le combiné, et pour avoir un adb non sécurisé, vous avez besoin de root! ET aussi, vous avez besoin d'un chargeur de démarrage déverrouillé.

Jetez un oeil à un exploit appelé zergRush trouvé sur github; la fonction d'intérêt est appelée do_fault()là où une tentative est faite pour "casser" le cadre de pile du volddémon de 'en se connectant au canal qui lui appartient, et le faire planter en écrasant le pointeur de pile pour pointer vers un copié version du shell boomshqui s'exécute ensuite à partir de /data/local/tmp.

Après avoir lu la source, vous comprendrez maintenant pourquoi la copie du subinaire ne suffit pas pour que le combiné soit "enraciné" et pourquoi les cercles doivent être sautés. Et aussi, comme le bit exécutable au niveau du système de fichiers pour la carte SD est bloqué, alors n'y allez pas - c'est là pour des raisons évidentes! :)

— t0mm13b
source

Merci pour les liens, je les relirai plus tard. Donc, même si la carte SD était modifiée par 777 de l'usine, je ne pouvais toujours pas devenir root en la téléchargeant et en l'exécutant simplement?

— user974896

correct! Ne pas aller! Cela ne fait pas chmodla moindre différence et puisque la ROM installée en usine aura protégé un lá, vous avez besoin de root pour y parvenir, ce qui coupe les autorisations de la carte SD pour le faire! :)

— t0mm13b

Eh bien, qu'est-ce qui rend su si spécial s'il se trouve dans / system / xbin? Si vous entrez dans le shell adb (ou exécutez une application en tant qu'utilisateur normal), vous êtes un utilisateur non privilégié. Pourquoi exécuter su quand il est dans / system / xbin vous fait rooter au lieu de l'exécuter dans notre chmod 777 / sdcard théoriquement?

— user974896

/system/xbinest le répertoire dans lequel les utilitaires busybox vont, et ... dans un combiné enraciné, l'émission echo $PATHproduira / sbin: / vendor / bin: / system / sbin: / system / bin: / system / xbin <- remarquez-le! C'est sur le chemin! Pour avoir ça là-dedans, vous avez besoin de racine, donc beaucoup de situations de poulet et d'oeufs ...: D

— t0mm13b

Oui, je sais que c'est là que ça va par défaut. Ce que je veux dire, c'est ce qui est si spécial de le faire fonctionner là-bas. Pourquoi l'exécution de ./su dans / sdcard /, / data / ou tout autre répertoire non root requis ne fonctionnerait pas en supposant que l'usine a expédié la ROM avec le répertoire chmodded à 777. Ce que je veux dire fondamentalement est la seule chose qui empêche l'un de télécharger et exécuter ./su est le fait que les répertoires dans lesquels un utilisateur non root peut le faire sont non exécutables ou y a-t-il une image plus grande.

— user974896