Warum kann die su-Binärdatei nicht einfach kopiert werden (technische Antwort bitte)

Ich habe mehrere Samsung-Geräte gerootet und das zugrunde liegende "Ziel" scheint sozusagen darin zu bestehen, die suBinärdatei einzuspielen /system/xbinund Superuser.apk zu installieren .

Meine Frage ist, warum muss man durch all diese Reifen springen, um das Telefon zu rooten (benutzerdefinierte Wiederherstellung installieren und vorgerootetes ROM flashen oder die aktuelle Installation ausnutzen)? Könnte man nicht einfach ein vorkompiliertes su herunterladen, auf die SD-Karte verschieben und über adb ausführen? Die Sache, die ein ROM "pre-rooted" zu machen scheint, ist, dass es Superuser und die su-Binärdatei in ihren jeweiligen Systempfaden hat. Ich verstehe nicht, warum es so wichtig ist, dass es davon gerannt wird /system/xbin.

Antworten (2)

Die su-Binärdatei benötigt sowohl das Ausführungs- als auch das setuid-Berechtigungsbit gesetzt. Das erste ist erforderlich, damit die Datei ausgeführt werden kann, und das zweite, dass sie automatisch mit den Rechten des Dateibesitzers ausgeführt wird (gesetzte Benutzer-ID oder Setuid. In diesem Fall ist der Besitzer root. Lesen Sie hier mehr ).

Für Dateien auf dem externen Speicher sind die Berechtigungsbits für ausführbare Dateien und setuid nicht gesetzt, und sie können ohne Root-Rechte nicht gewährt werden. Beachten Sie auch, dass die SD-Karte mit dem Flag „noexec“ gemountet wird, um die Ausführung generell beim Booten zu verhindern:

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,[...]

Das ist im Grunde der Grund, warum Sie nicht einfach suauf die SD-Karte kopieren und sie dann ausführen können, um sich selbst Root zu gewähren.

Das ist also das einzige, was das Rooten verhindert, die Tatsache, dass /sdcard nicht ausführbar ist und Sie nicht chmod können? Sobald sich su an der entsprechenden Stelle befindet, kann Ihre goldene ausführbare Datei chmodded werden. Ich würde denken, dass es eine Sicherheitsebene geben würde, um zu verhindern, dass jemand einfach su ausführt. Auf meinem Server und meiner Debian-Box kann ich su nicht einfach als normaler Benutzer ausführen, ich werde nach einem Passwort gefragt. Ich denke, die Annahme ist, dass, wenn man su installieren kann, die Shadow-Datei überschrieben werden kann, um das Passwort zu ändern?
@ user974896: Nun, es gibt keinen anderen Ort, an dem ein Nicht-Systembenutzer angeben kann, dass es ausgeführt werden kann, und Android hat sowieso nicht einmal passwdoder shadow-Dateien. Sie brauchen buchstäblich root, um sueinen ausführbaren Speicherort zu erstellen, weshalb Root-Methoden entweder einen Privilegien-Eskalations-Exploit beinhalten oder in eine benutzerdefinierte Wiederherstellung einsteigen (bei der im Grunde alles ausgeschlossen ist).
Ja. Das ist die Antwort.
@user974896: Zusätzlich zu der /sdcard, die noexec gemountet wird, kann der setuid-Systemaufruf nur aufgerufen werden, wenn das suid-Berechtigungsbit in der ausführbaren Datei gesetzt ist, und der chown- und chmod-Systemaufruf erlaubt nur root, das setuid-Bit einer Datei zu setzen im Besitz von root (effektiv kann nur root eine ausführbare Datei erstellen, die mit root-Rechten ausgeführt werden kann). Jeder kann su aufrufen, aber wenn der Aufrufer dies nicht in der Superuser-Datenbank (oder in herkömmlichem Linux in der passwd/shadow-Datenbank) darf, wird der Aufruf nicht erfolgreich sein. Nur die Superuser-App (und privilegierte Prozesse) können die Superuser-Datenbank ändern.
@ user974896: Dies bedeutet zusätzlich zu dem normalen Sicherheitssystem in Android, in dem jede Dalvik-Anwendung als ihr eigener Benutzer ausgeführt wird, dass Anwendungen, die nur Anwendungen in der Whitelist von Superuser ohne Aufforderung zum Root eskalieren können, alle anderen abgelehnt werden (falls dies der Fall ist). in der Blacklist) oder veranlasst den Superuser, den Benutzer um Erlaubnis zu bitten.

Beim Rooten wird die Schwachstelle je nach Android-Version ausgenutzt, daher " springen Sie durch alle Reifen, um das Telefon zu rooten " .

Es ist ein Huhn und Ei!

Um root auszunutzen, benötigen Sie einen ungesicherten ADB-Daemon (dh die Fähigkeit zum erneuten Einhängen /system) auf dem Mobilteil, und um einen ungesicherten ADB zu haben, benötigen Sie Root! UND außerdem benötigen Sie einen entsperrten Bootloader.

Sehen Sie sich einen Exploit namens zergRush an, der auf github gefunden wurde; Die interessierende Funktion wird aufgerufen, do_fault()wenn ein Versuch unternommen wird, den Stack-Frame des vold's-Daemons zu "brechen", indem eine Verbindung zu der Pipe hergestellt wird, die ihm gehört, und ihn zum Absturz bringt, indem der Stack-Zeiger so überschrieben wird, dass er auf eine Kopie zeigt Version der Shell boomsh, die dann von ausgeführt wird /data/local/tmp.

Nachdem Sie den Quelltext gelesen haben, werden Sie nun erkennen, warum das Kopieren der suBinärdatei nicht ausreicht, um das Mobilteil "zu rooten", und warum Hoops durchgesprungen werden müssen. Und da das ausführbare Bit auf Dateisystemebene für die SD-Karte blockiert ist, gehen Sie nicht dorthin - das ist aus offensichtlichen Gründen da! :)

Danke für die Links, die ich mir später durchlesen werde. Selbst wenn die SD-Karte 777 ab Werk gemoddet wurde, konnte ich immer noch nicht root werden, indem ich sie einfach herunterlud und ausführte?
Korrekt! No Go! Macht keinen Unterschied und da das werkseitig installierte ROM dieses geschützte a lá hat, benötigen Sie root, um dies zu erreichen chmod-ding die Berechtigungen der SD-Karte, um dies zu tun! :)
Nun, was macht su so besonders, wenn es in /system/xbin ist? Wenn Sie die adb-Shell eingeben (oder eine App als normaler Benutzer ausführen), sind Sie ein nicht privilegierter Benutzer. Warum führt die Ausführung von su, wenn es sich in /system/xbin befindet, dazu, dass Sie root werden, anstatt es theoretisch in unserem chmod 777 /sdcard auszuführen?
/system/xbinist das Verzeichnis, in das die Busybox-Dienstprogramme gehen, und ... in einem gerooteten Mobilteil ergibt die Ausgabe echo $PATHvon /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin <- Beachten Sie es! Es liegt im Weg! Um das da drin zu haben, braucht man root, also viele Henne-Eier-Situationen ... :D
Ja, ich weiß, dass es standardmäßig dorthin geht. Was ich meine, ist das Besondere daran, es dort zu betreiben. Warum sollte das Ausführen von ./su in /sdcard/, /data/ oder einem beliebigen nicht als Root erforderlichen Verzeichnis nicht funktionieren, vorausgesetzt, das Werk hat das ROM mit dem Verzeichnis chmodded bei 777 geliefert. Was ich im Grunde meine, ist das einzige, was einen am Herunterladen hindert und das Ausführen von ./su ist die Tatsache, dass die Verzeichnisse, in denen ein Nicht-Root-Benutzer dies tun kann, nicht ausführbar sind, oder gibt es ein größeres Bild.
Lass uns in den Chatroom gehen, um all diese Kommentare zu ersparen....
Warum kann die su-Binärdatei nicht einfach kopiert werden (technische Antwort bitte)
AntwortenHierDatenschutz-Bestimmungen1y, 0v