10 votes

Pourquoi "adb root" ne fait-il rien?

J'ai un OnePlus 6T. Il est rooté par TWRP et Magisk. J'ai défini ro.debuggable sur 1. Mais lorsque je tape adb root, cela donne ceci :

C:\Users\ituser> adb root

C:\Users\ituser> adb remount
Not running as root. Try "adb root" first.

entrer la description de l'image ici

Je ne peux même pas utiliser adb pull sur des fichiers système.

1 votes

Je me demande pourquoi cela ne renvoie pas un message d'erreur. À ma connaissance, adb root ne fonctionne pas sur les "compilations de production" (comme les ROM officielles, même si elles sont rootées). Donc, à moins d'avoir une "ROM de développement", il y a peu de chances que cela fonctionne.

16voto

Irfan Latif Points 16863

En production — utilisateur build d'une ROM — vous ne pouvez pas démarrer adbd en tant que root à moins que la ROM ou au moins le binaire adbd soit reconstruit avec les modifications requises. La raison est le drapeau de compilation ALLOW_ADBD_ROOT (1, 2).
C'est pourquoi adbd Insecure a été développé, qui a remplacé le binaire adbd par un binaire modifié.

Sur un build userdebug ou eng (ou avec un binaire adbd non sécurisé extrait de l'un de ces types de build):

  • Si ro.secure=0, adbd s'exécute en tant que root lorsqu'il est activé depuis les paramètres (Options pour les développeurs) (3). Cependant adb root ne fonctionnera pas (4).
  • Si ro.debuggable=1, adb root redémarrera adbd en tant que root (5, 6).

Cependant, adbd peut être construit à partir du code source modifié pour éviter toutes ces vérifications. De plus, SELinux doit également être pris en compte, s'il est en mode enforcing. adbd doit être autorisé à s'exécuter dans un contexte de super utilisateur non restreint : u:r:su:s0 (7, 8), ce qui n'est pas le cas pour les builds user (9, 10, 11). Voir cette réponse pour plus de détails.

Les propriétés Android peuvent être écrasées en utilisant /data/local.prop sur les builds userdebug/eng c'est-à-dire si le drapeau de compilation ALLOW_LOCAL_PROP_OVERRIDE est défini (12, 13). Mais cela ne fonctionne pas pour les propriétés ro.* (14) et il en va de même pour l'outil en ligne de commande setprop. Cependant le fichier default.prop / prop.default — qui pourrait se trouver à différents endroits possibles en fonction des configurations de build de l'appareil (15) — peut être modifié pour changer les propriétés en lecture seule (si elles ne sont pas déjà définies à partir d'un autre fichier de propriétés ou fichier *.rc). Si le fichier se trouve dans le ramdisk, boot.img doit être modifié.

L'outil resetprop de Magisk peut réinitialiser les propriétés en lecture seule même si elles sont déjà définies. Les propriétés ro.secure et ro.debuggable ont peut-être été modifiées dans le cadre de la politique MagiskHide (16), que vous pouvez rétablir pour permettre à adbd de s'exécuter en tant que root.

Une autre propriété connexe est ro.adb.secure, qui contrôle l'authentification par clé publique. En définissant ro.adb.secure=0 sur les builds userdebug/eng, l'authentification est ignorée (pas de message périphérique non autorisé jamais) (17, 18, 19); voir aussi : Emplacement du stockage des “adb_keys”.

2 votes

En tant qu'information supplémentaire, le type de construction de la ROM peut être trouvé en regardant ro.build.type

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X