Diskussion:Rooten

Bereich "Rechtliches"

Hallo,

in anderen Wikipedias zu diesem Thema (Rooten) wird ebenso auf den Aspekt des rechtlichen und die Reaktion der Hersteller/Netzbetreiber eingegangen. Ist es auch sinnvoll hier in der deutschen Wikipedia diese beiden Bereiche hinzuzufügen? Ich für meinen Teil finde es sehr interessant, dass es dazu auch Material gibt, kenne mich da aber nicht wirklich aus und müsste mich dort erst einlesen. Gruß --Pearli123 (Diskussion) 15:32, 7. Aug. 2016 (CEST)

m.E. wäre das eine sinnvolle Erweiterung des Artikels. Sowohl hinsichtlich der Urheberrechtsfragen bei der Modifikation des Systems als auch in Hinblick auf Gewährleistung und Garantie. Zu den letztgenannten Punkten dürfte es Rechtsprechung geben (Gewährleistung bleibt, Garantie wird gem. Garantiebedingungen wohl erlöschen). Bei den Urheberrechtsfragen habe ich noch nie von Rechtsprechung gehört, halte es aber bei Veränderungen der Systempartition (inkl. Parameter-Änderungen) für offensichtlich problematisch. Evtl. gibt's dazu wenigstens einen Fachaufsatz. --gdo 20:27, 9. Aug. 2016 (CEST)

Revert vom 09.08.2016

Ich habe die Änderungen revertiert und zwar aus folgenden Gründen:

1. seriöse Belege wurden entfernt, darüber hinaus:
2. das Rooten erfordert bereits Zugriff auf die Systempartition zwecks su Binary - es ist also nicht erst das Ergebnis des Rootens
3. Änderungen an der Systempartition sind (üblicherweise) auch über den Recovery-Modus und ggf. via ADB möglich; das ist also kein grundsätzliches Charakteristikum von Root-Rechten (wobei es im Artikel nicht um Root-Rechte, sondern um das Rooten geht).
4. Bloatware ist mitnichten immer in der Systempartition enthalten, sondern durchaus auch in der Data-Partition. Dass ein normaler Android-User daher Bloatware generell nicht entfernen könnte, ist so allgemein und umfassend formuliert falsch
5. Die Installation eines neuen Systems erfolgt üblicherweise über eine (Custom-)Recovery oder via ADB - schon allein deshalb, weil regelmäßig ein laufendes System nicht überschrieben werden kann. Zu suggerieren, dass Root-Rechte dafür regelmäßig erforderlich seien, ist falsch.
6. Dass nur wenige Hersteller von Androiden die Bootloader schützen ("sperren") ist unbelegt.
7. Der Verleich mit dem Jailbreak ist nicht OMA-tauglich und völlig unbelegt.
8. die sog. "Vorteile" sind relativ wahllos und unklar. Insbes. ist das "visuelle Design" (wo ist das genau definiert?) auch ohne Root-Rechte durchaus anpassbar. Ggf. müsste das genauer erläutert werden. Eine Übertaktung setzt nicht nur entsprechende Root-Rechte, sondern auch einen solche Maßnahmen zur Verfügung stellenden Kernel voraus, was bei Original-Hersteller-Kerneln regelmäßig nicht gegeben ist - in solchen Fällen bringen Root-Rechte für sich genommen also überhaupt keinen Vorteil. Zu Bloatware und Fremdsystemen: s. oben.
9. Risiken: ungeeignete Quelle, allgemeines Blabla (ein Wiki belegt kein Wiki und Wiki ist kein How To). Im Übrigen gibt es diverse Root-Methoden, die durchaus unterschiedliche Risiken mit sich bringen und es sind keineswegs alle Methoden speziell auf ein bestimmtes Gerät abgestimmt. Der Abschnitt ist daher nebulös, aber nicht enzyklopädisch erhellend.
10. Risiken II: Die Nutzung der Rootrechte ist nicht Gegenstand des Lemmas. Darüber hinaus erfolgt die Verwaltung über eine Superuser-App; die Schlussfolgerung, dass es schädlicher Software damit leicht gemacht wird, ebenfalls Root-Rechte zu erhalten, ist weder plausibel dargestellt noch belegt. BTW: die One-Click-Tools sind tatsächlich Apps, die sich selbst Root-Rechte verschaffen und deren Methoden kann grundsätzlich jede App in sich tragen - das hat mit "Erfahrenheit" des Nutzers erstmal gar nichts zu tun.

Im Ergebnis: m.E. viele durchaus ausbaubare Aspekte, aber in der eingebrachten Form leider unbelegt, Halbwissen und schwammig formuliert. Ein Ausbau der Aspekte ist m.E. durchaus denkbar - nur dann muss auch eine entsprechende enzyklopädische Qualität dahinter stehen. --gdo 20:22, 9. Aug. 2016 (CEST)

zu 1. war sicherlich keine Absicht, ist mir am Ende gar nicht aufgefallen.

zu 2. an sich ja, habe ich schwammig formuliert. besser wäre die Formulierung, dass nach dem rooten ein schreibender Zugriff auf die System-Partition über Android (als OS) möglich ist?

zu 4. selbst auf die /data/-Partition habe ich ohne root-Rechte keinen schreibenden zugriff

zu 7. bei der Übetaktung könnte man entgegengesetzt argumentieren, dass ein übertaktungsfähiger Kernel ohne root-rechte auch keinen Mehrwert bietet.

zu 9. ist ein Diskussionspunkt, dem ich leider nicht weiter folgen kann. ich kenne erfahrenere Nutzer (als mich), die ebenfalls von einer erhöhten Gefahr eines gerooteten Systems ausgehen, superuser app hin oder her

Bei den restlichen Punkten stimme ich dir zu. Es sollte ja auch nicht die letzte Bearbeitung sein. Dass es solch gravierende Mängel aufweist, war mir nicht bewusst.

Gruß --Pearli123 (Diskussion) 11:51, 10. Aug. 2016 (CEST)

zu 2.) mit Root-Rechten lässt sich m.W. die Systempartition auch im laufenden Betrieb rw-mounten (da werden die Rechte gebraucht zunächst gebraucht). M.W. ist die Systempartition aber auch bei gerooteten Geräten nicht ständig rw-gemountet. Für die Modifikation von Daten auf /system dürften dann bei rw-gemounteter Partition aber auch noch root-Rechte erforderlich sein.

zu 3.) "Ich" ist sehr untechnisch formuliert: das Android-Berechtigungssystem bzw. die Berechtigungen des verwendeten Dateisystems ist/sind vielschichtig und "du" kannst auf /data im Rahmen des Berechtigungssystems selbstverständlich Änderungen vornehmen - nur eben nicht mit einem beliebigen Programm an beliebiger Stelle. In /data installierte Bloatware (ja, sowas gibts) kannst Du daher ganz einfach deinstallieren und der Zugriff auf Mediendaten geht mit einschlägigen Apps natürlich auch. Auch lassen sich Systemeinstellungen ändern und auf /data abspeichern (z.B. WLAN-Zugangsdaten), wenn man dazu die vorgesehenen Benutzer-Schnittstellen der "Einstellungen" verwendet. Allerdings wird ein simpler Drittanbieter-Dateiexplorer ohne Root-Rechte wohl auf /data nicht mal etwas lesen können. Insofern kann man sagen, dass der Zugriff auf /data durch den Benutzer ohne Root-Rechte stark reglementiert ist. Aber da es um Bloatware ging: es würde ja genügen, deutlich zu schreiben, dass für die Entfernung von Bloatware von der Systempartition, Root-Rechte erforderlich sind, für die Entfernung von Bloatware auf der /data-Partition hingegen nicht (müsste halt noch allgemeinverständlich formuliert werden).

zu 7.): mir geht es eher darum, Missverständnisse zu vermeiden: mit Root allein lässt sich in der Regel nicht übertakten (wohl aber meist die Taktung reduzieren) und auch sonst eher wenig in den Tiefen der Prozessorsteuerung ausrichten. Root ist notwendige(?) Voraussetzung aber reicht dafür halt nicht aus. Und einen Custom-Kernel muss man eben erstmal finden oder selbst Kompilieren und dann muss man ihn auch noch auf das Gerät draufkriegen (ich hab nur früher bei einem Sony-Androiden mal einen Custom-Kernel verwendet und um das machen zu können, musste auch der Bootloader noch entsperrt sein, weil das Gerät sonst nur einen Sony-signierten Kernel gestartet hätte - ist aber schon eine Weile her). Im Übrigen bin ich mir nicht mal sicher, ob man für das Übertakten mittels Custom-Kernels wirklich technisch zwingend Root-Rechte bräuchte - ist das so? In der Praxis ist die Frage natürlich bedeutunglos, weil jemand mit Custom-Kernel wohl auch stets Root-Rechte haben wird

zu 9.): natürlich ist das Risiko höher, aber ich sehe nicht, wie eine Dritt-App ohne Zutun des Benutzers bereits vorhandene Root-Rechte für sich "kapern" kann; ich meine auch nicht, derartiges schonmal irgendwo gelesen zu haben. Das Risiko besteht also primär darin, dass der Benutzer ganz aktiv Mist baut oder einem Schadprogramm aktiv Root-Rechte einräumt. Zumindest wenn die Installation aus Fremdquellen erlaubt wird, kann eine App sich natürlich auch "einfach so" selbst Root-Rechte verschaffen (das ist ja gerade das Sicherheitsproblem, das KingRoot, KingoRoot und Konsorten aufwerfen) - solche Apps können dann auch ohne weiteres Benutzerzutun jeden beliebigen Schaden anrichten und Benutzerdaten (auch Passwörter, Tastatureingaben etc.) nach Hause schicken. Insofern müsste man die Risiken evtl. etwas differenzierter darstellen und ggf. belegen - dass es sie gibt, steht m.E. ja außer Frage.

ansonsten: ich hab länger gezögert vor dem Revertieren, weil ich Deine Erweiterungen schon als gute Ansätze gesehen habe nur eben doch etwas zu unpräzise. Als ich den Artikel vor kurzem angelegt hatte, habe ich aber auch schon über die spärlich verfügbare Literatur geflucht und deren oft nicht minder schwammige Texte. Und die sog. "Fachpresse" hilft im Detail m.E. nur selten weiter. --gdo 13:56, 10. Aug. 2016 (CEST)

Hallo,

grundlegend stimme ich dir in allen Punkten zu.

Bei mir ist leider auch ein weilchen her, dass ich aktiv an meinen Androiden herumgewerkelt habe. Dennoch möchte ich kurz einen anderen Gedankenansatz einbringen: Ist denn mit rooten im Sinne dieses Artikels der Prozess oder das Ergebnis gemeint? Meiner Meinung nach ist das Ergebnis ja eigentlich die "Root-Rechte" im allgemeinen. Der Prozess, sofern der hier betrachtet wird, beinhaltet ja eigentlich das entsperren des Bootloaders bzw. sämtliche für diesen Vorgang umgangenen Sicherheitskonzepte der Hersteller. Dann wäre es schon vernünftig, zu schreiben, dass Root Rechte (im weiteren Sinne?) zu verschiedenen, auch kernelbezogenen, Berechtigungen führen.

Soweit dazu, um den Kernel zu übertakten gab es glaube ich zwei (bzw. drei) Wege. Einmal war im Kernel an sich ja eingestellt, welche Taktfrequenz genutzt werden soll. Dann noch die Möglichkeit, mittels bestimmter UI's das in Android selbst einzustellen. Ich glaube aber, dass das System an sich auch Parameter beim Start vergibt, die die Taktfrequenz des Kernels einstellen. Um die zu ändern, wären dann wieder Root-Rechte nötig, oder aber ein Zugriff über die Recovery, was aber nachgeprüft werden müsste, wo wir beim Thema für mich sind, ich sollte mehr auf Quellen eingehen, wenn ich weitere Bearbeitungen vornehme, danke dafür.

Was mir dazu weiter einfällt, da es ja zur Diskussion steht, dass vieles auch "einfach" über die Recovery gelöst werden kann: Habe ich mittels einer Custom Recovery nicht auch schon darüber bestimmte "root-ähnliche" Rechte? Oder wie funktioniert darüber der Zugriff. Da die ADB im Recovery Modus ja auch vorhanden ist. Vielleicht kann dazu ein findiger User etwas dazu sagen, der sich da so tief drin auskennt.

Zum Thema der /data/-Partition. Ich erinnere mich daran, auf verschiedene Ordner mittels ADB zugegriffen zu haben, aber nicht ob ich dafür root-Rechte benötige. Lediglich von meinem Smartphone kann ich mit dem ES Datei-Explorer und ausgeschalteter ROOT_Explorer Funktion nicht darauf zugreifen. Ich kann nicht sagen, ob das ein drittklassiger Dateiexplorer ist -.-

Zum Thema der Sicherheit nach dem eigentlichen Root-Vorgang gibt es verschiedene (nicht wissenschaftlich belegte) Theorien. Was ich vor kurzem gelesen habe ist, dass es sogar Apps gibt (natürlich keine Play-Store Apps), die es sogar schaffen, das Telefon zu rooten, ohne dass der Nutzer das von der App erwartet. Ob das wirklich der Fall ist, oder lediglich Theorien von "Experten" kann ich im Moment nicht nachvollziehen. Aber gerade bei solch einer Zugriffskontrolle über eine App, ob jemand Root-Zugriff bekommt oder nicht, scheint mir für "Bösewichte" ein gefundenes Fressen zu sein; Wie gesagt, ich habe mich da mittlerweile schon gut 2 Jahre nicht mehr aktiv damit befasst.

Zu der Literatur: Leider ist es bei Android wirklich schwer, Dinge zu finden, die wirklich von seriösen Quellen stammen. Der Großteil des Contents stammt von Entwicklern, die das privat machen. Dass es zum Thema Android überhaupt Fachpresse gibt, wusste ich nicht einmal.

--Pearli123 (Diskussion) 16:18, 10. Aug. 2016 (CEST)

als ich den Artikel angelegt habe (es war ja vorher nur eine inhaltlich leerlaufende Weiterleitung), hatte ich ihn eigentlich als Ergänzung zu Root-Konto gedacht und hatte eher den Prozess des Rootens im Hinterkopf - aber das muss ja nicht so bleiben. Zumal der Artikel Root-Konto eher allgemein ist und das Rooten deutlich in den Bereich Android/Mobilegeräte fällt. BTW: Rooten erfordert nicht zwingend eine Entsperrung des Boatloaders; letztlich müssen die notwendigen binaries in die Systempartition - welche Hürden die Gerätehersteller dafür aufstellen ist durchaus unterschiedlich ebenso wie die Methoden (als update.zip via (Custom-)Recovery, adb/fastboot mit PC-Tool oder Skript, One-Click-App etc.) Leider hab ich keine brauchbare Literatur gefunden, die die Konzepte mal systematisch darstellt).

Recovery: prinzipiell kriegt man darüber Schreibzugriff für /system - nur die Markengeräte, die ich so in den Händen hatte, haben ausnahmslos nur hersteller-signierte Updates (also "offizielle" Updates) verarbeitet. Ein Custom-Recovery zu Flashen ging bei Sony und BQ problemlos, bei Samsung weiß ich's nicht mehr genau und bei ZTE war dafür ein bootloader unlock erforderlich. Mit einer Custom-Recovery kann man dann in der Regel alles auf /system schreiben, was man möchte, insbes. auch die su-binaries von https://download.chainfire.eu/696/supersu/ Aber wegen der Vielfalt sind allgemeingültige Aussagen trotzdem schwierig.

/data: im Standard kommst Du mit einer selbst installierten App ohne Root-Rechte nicht auf die Partition lesend drauf. Auf einem Samsung(???) hatte ich mal einen Hersteller-Dateibrowser (in /system) gesehen, der Teile von /data lesen und anzeigen konnte (wird entsprechend rechtemäßig vom Hersteller konfiguriert worden sein)

Root durch Apps: ja, sämtliche One-Click-Root-Apps zeigen doch, dass es geht. Diese Apps haben alles dabei, um sich (und dem Nutzer) Root-Rechte zu verschaffen - deshalb lädt der Benutzer sie ja auf sein Smartphone. Aber man könnte den Programmcode natürlich auch in eine Spiele-App mit einbauen, die sich dann ohne Benutzerwissen selbst Root-Rechte verschafft, diese selbst verwaltet und das ganze auch noch heimlich tut. Davor ist aber der Benutzer eines bereits gerooteten Smartphones m.E. nicht besser oder schlechter geschützt als einer, der keine Veränderungen am System vorgenommen hat. --gdo 17:24, 10. Aug. 2016 (CEST)

Wie soll damit jetzt weiter verfahren werden? Ich kenne mich da leider noch nicht so richtig aus :) --Pearli123 (Diskussion) 17:47, 10. Aug. 2016 (CEST)

füge Änderungen einfach ein - aber tue Dir selbst und allen anderen einen Gefallen und arbeite Abschnittsweise und mach nicht eine einzige "große" Bearbeitung: ein einzelner Abschnitt kann auch mit verbleibenden (vermeintlichen) Mängeln gesichtet und ggf. korrigiert oder ergänzt werden. Wenn Du eine große Bearbeitung machst, dann bleibt einem Sichter meist nur die Wahl zwischen alles oder nichts. Und wenn Du Lust und etwas Zeit hast: ich hatte bei meinen Einzelnachweise soweit möglich auf Google-Books verlinkt - vielleicht steht in den Quellen noch etwas mehr zu den oben genannten Fragestellungen, damit man das Beleg-Problem irgendwie in den Griff kriegt. Ansonsten: lass dich nicht aufhalten! --gdo 08:24, 11. Aug. 2016 (CEST)

"schon allein deshalb, weil regelmäßig ein laufendes System nicht überschrieben werden kann" Mal ganz abgesehen von der eigentümlichen Verwendung des Wortes "regelmäßig", verstehe ich nicht, wo das Problem sein soll. Ich verwalte einige Linux-Server und kann die problemlos im laufenden Betrieb "überschreiben". Kernel-Hotswap habe ich noch nicht gemacht, sollte aber auch seit etlichen Jahren sauber funktionieren. Austausch eines gesamten Systems ist halt im laufenden Betrieb viel aufwendiger als Neuinstallation "von außen". Aber eben auch alles andere als unmöglich. --93.198.78.38 14:32, 14. Sep. 2017 (CEST)