Aktivierung des Root-Accounts

[kaju]

Bei mir läuft HC.

 

[dirkw01]

Den Command adb.exe kennt mein System nicht. Muß da noch etwas heruntergeladen und installiert werden?
Danke.

Öffne ein CMD-Fenster und navigiere zu dem Ordner, in den Du mein ZIP entpackt hast. Dort gibt es ein ADB.exe.
Auch den Batchjob musst Du in diesem Ordner ausführen.

Gruß
Dirk

 

[kaju]

Und das ist das Ergebnis von "mount".

 

[dirkw01]

Und das ist das Ergebnis von "mount".

Und hier endet mein 'Latein' sprich meine Linux-Kenntnisse. :blushing:
Vielleicht hat 'Andri Od' da mehr zu bieten.

Die einzige Idee wäre, erst den Update auf ICS durchzuführen und dann das Rooten erneut zu versuchen.

Gruß
Dirk

 

[kaju]

Was ist schon wieder ein "Batchjob" ? Ich hab zu tun dass ich die Zeilen/Befehle fehlerfrei abgetippt bekomm. Ich bin in Sachen DOS oder anderweitige Befehlsschreibweise total aufgeschmissen.

Der ursprüngliche Beitrag von 20:04 Uhr wurde um 20:05 Uhr ergänzt:

Ok ,ich danke dir dennoch für deine Mühe.

 

[dirkw01]

Was ist schon wieder ein "Batchjob" ? Ich hab zu tun dass ich die Zeilen/Befehle fehlerfrei abgetippt bekomm. Ich bin in Sachen DOS oder anderweitige Befehlsschreibweise total aufgeschmissen.

Ein Batchjob ist nix anderes, als Befehle, die Du sonst manuell eintippen müsstest, quasi automatisch ablaufen zu lassen. Dazu werden die Befehle nacheinander in eine Datei geschrieben.
'Root_MEDION_LifeTab_P9516.bat' ist genau so eine Datei.
Du kannst Sie mit dem Notepad öffnen und erkennen, daß dort genau die Dir inzwischen bekannten Befehle eingetragen sind.

Gruß
Dirk

 

[pseiko]

Die Frage ist, ob bei einem Lifetab mit Honeycomb dasselbe Blockdevice auf /system gemountet ist, wie bei ICS (/dev/block/mmcblk0p3).

Kannst Du in der adb-Shell mal das Kommando "mount" absetzen, und das Ergebnis hier posten?
Gruß
A.O.

hiho, folgendes kommt bei mir mit dem mount befehl raus.

C:\Users\pseiko>adb shell
$ mount
mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mmcblk0p3 /system ext4 ro,relatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p7 /data ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p4 /cache ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p8 /data/temp ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0
/dev/fuse /mnt/sdcard fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
$

Mir fällt dabei auf das mmcblk0p3 "ro" also read-only ist obwohl man ja mit dem Batch Job (oder manueller Eingabe) ein chmod auf 755 ausführt. Oder werden die Eingaben immer nach einem Neustart zurückgesetzt? Denn wenn das so ist, dann bringt das chmod nix weil ja immer von 755 auf 400 (od 444) gesetzt wird. Bitte um Korrektur wenn ich falsch liege.

Achja noch etwas...wenn ich den Batch Job starte dann wird ja ein daemon gestartet doch der Batch Job macht erst dann weiter wenn ich mein LT "aufwecke" (immer wenn der Bildschirm schwarz wird).

 

[dirkw01]

Hier zum Vergleich mein Mount mit ICS:

d:\Android\Root_MEDION_LifeTab_P9516\Root_MEDION_LifeTab_P9516>adb shell
shell@android:/ $ mount
mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/platform/sdhci-tegra.3/by-num/p3 [COLOR="Red"]/system[/COLOR] ext4 ro,relatime,user_xattr,acl,barrier=1,data=o
rdered 0 0
/dev/block/platform/sdhci-tegra.3/by-num/p7 /data ext4 rw,nosuid,nodev,noatime,errors=panic,user_xat
tr,acl,barrier=1,journal_async_commit,nodelalloc,data=writeback 0 0
/dev/block/platform/sdhci-tegra.3/by-num/p4 /cache ext4 rw,nosuid,nodev,noatime,errors=panic,user_xa
ttr,acl,barrier=1,journal_async_commit,nodelalloc,data=writeback 0 0
/dev/block/mmcblk0p8 /data/temp ext4 rw,nosuid,nodev,noatime,user_xattr,acl,barrier=1,data=ordered 0
 0
/dev/fuse /mnt/sdcard fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,a
llow_other 0 0
/dev/block/vold/179:9 /mnt/sdcard2 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fm
ask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=
remount-ro 0 0
shell@android:/ $

Hier ist '/system' auf '/dev/block/platform/sdhci-tegra.3/by-num/p3' gemapt?!

Hallo? Wo sind die Linux-Experten?

Gruß
Dirk

 

[pseiko]

Hm bei dir steht aber auch
/dev/block/platform/sdhci-tegra.3/by-num/p3

und bei mir
/dev/block/mmcblk0p3

Scheinbar ändert sich nach dem Upgrade auf ICS der Mount-Pfad des Filesystems. Wenn beides das Gleiche ist, dann steht aber bei mir auch /system.

Ich hab übrigens etwas recherchiert weil mir der Befehl debugfs so nichts sage und bin auf folgende Page gestoßen:
debugfs(8): ext2/ext3/ext4 file system debugger - Linux man page

Der Parameter "-w" der im Skript oder auch in der manuellen Eingabe vorkommt bedeutet folgendes:

Specifies that the file system should be opened in read-write mode. Without this option, the file system is opened in read-only mode.

Das heißt dadurch sollte das Filesystem beschreibbar werden und das funktioniert eben bei mir nicht. Bekomme immer den Fehler "Permission denied...".

Kann mir einer sagen mit welchem User man überhaupt sich in der adb shell bewegt?

 

[Jason101]

Öffne ein CMD-Fenster und navigiere zu dem Ordner, in den Du mein ZIP entpackt hast. Dort gibt es ein ADB.exe.
Auch den Batchjob musst Du in diesem Ordner ausführen.

Gruß
Dirk

Danke. Das Ergebnis von adb.exe devices ist:
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached

Ich schaffe es offensichtlich nicht, den ADB-Treiber zu installieren.
Der Batchjob läuft an und sagt:
Sie muessen die MEDION LifeTab ADB-Treiber installierem. die mit ...

Kleine Wiederholung:
"Im Device Manager ist mein Lifetab unter Portable Devices als MD_LIFETAB_9516 aufgeführt. Über das USB-Kabel komme ich auf das Lifetab.

Bei Update des Treibers über Norberts/Dirks File "android_winusb.inf" sagt er: "The specified location does not contain information about your hardware."
Bei den bereits installierten Treiber-Details/Device Instance Id finde ich: USB\VID_17EF&PID_7483\0A58308440A0F057

Deinstalliere ich den Treiber und schließe ich das Lifetab neu an, erkennt er die neue Hardware und installiert automatisch wieder den MTB-Treiber.

Was mache ich falsch, bzw. müßte ich eventuell die Inf-File abändern?"

Gibt es einen anderen Weg, den ADB-Treiber zu installieren?

 

[pseiko]

zu meinem vorherigen Post (https://www.android-hilfe.de/forum/...root-accounts.281687-page-9.html#post-3912956) hätte ich noch zusätzlich folgende Bitte: Kann mir jemand bei dem das rooten funktioniert in der adb shell den Befehl "id" ohne " " absetzen und das Ergebnis posten?
Ich denke das Problem könnte auch sein das ich mir dem User shell unterwegs bin und zum rooten (generell braucht ja eine Änderung des Filesystems) root-Rechte.

$ id
id
uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),3001(net_bt_admin),3002(net_bt),3003(inet)
$

 

[164072]

Ich habe mich jetzt mal näher mit dem befasst, was bei dieser root-Methode abläuft. Im Ergebnis würde ich behaupten: es funktioniert -wenn überhaupt- nur mit ICS.
Grundlage des Ganzen ist nämlich, dass beim Systemstart das Verzeichnis /data/local und /data/local/tmp dem User shell:shell zugeordnet wird, und die Gruppe shell Schreibrechte hat. In der init.rc steht:

   mkdir /data/local 0771 shell shell
    mkdir /data/local/tmp 0771 shell shell

Somit hat die adb-Shell (die kommt eben als User shell:shell) Schreibrechte auf /data/local, und wir können die Dateien rüberkopieren. Und wir können den Link auf das Blockdevice des /system-Filesystems setzen.
Diese Zeilen der init.rc werden -im Gegensatz zu HC!- bei ICS auch ausgeführt, wenn /data/local/tmp bereits existiert. Das ist der Schritt, der letztendlich /system für den User shell:shell beschreibbar macht, was wiederum Voraussetzung für ein erfolgreiches debugfs -w ...ist.
Der Rest ist dann simpel...
Bei HC bekommt also der gelegte Link zum/system- Blockdevice keine Schreibberechtigung für die adb-shell, und deswegen wird es mit HC so nicht klappen.

Gruß
A.O.

PS: Achso, /dev/block/mmcblk0... sind die generischen Devicefiles. /dev /block/platform/sdhci-tegra.3/by-num/... sind nur symbolische Links darauf.

 

[pseiko]

Zwei Dinge vorweg:
1. Ich hab gestern doch noch aufgrund der Rückmeldungen auf ICS upgegraded und rooten versucht (!). Es ist jedoch dabei geblieben das es nicht funktioniert hat wobei jetzt dürfte es nur noch eine Kleinigkeit sein. Ich schicke heute wenn ich nachhause komme mal das Log aus cmd und poste es hier. Vielleicht kommen wir gemeinsam noch auf den Fehler drauf. *i hope so*
2. Gestern habe ich die Auswertung von "id" gepostet und da steht "shell" demnach müsste ich als User "shell" in der adb shell eingeloggt sein und deshalb sollte ich auch bei HC die benötigten Rechte haben das Filesystem mit rw zu mounten.

Weiters will ich dann auch gerne mal aufschlüsseln was wo wie passiert und nehme mir dazu norbert's Beitrag (ich hoffe du verzeihst mir ):

adb push debugfs /data/local/
adb push su /data/local/
adb shell

adb wird benötigt um generell den Zugang zum LT herzustellen. Näheres hier: https://www.android-hilfe.de/forum/...leitung-adb-unter-linux-einrichten.83753.html
push (wie der Name schon sagt) wird benötigt damit Daten vom lokalen Rechner auf das LT kopiert werden können. Equivalent zum "copy"-Befehl in der CMD.
debugfs (in weiterer Folge mit dem Parameter -w) mountet dann /dev/block/mmcblk0p3 mit Schreibrechten. Standardmäßig ist das Filesystem Read-Only (ro) jedoch werden später für gewisse Aktionen eben auch Schreibrechte benötigt (Read-Write; rw).
/data/local ist ein Verzeichnis am LT wo wir die Befehle debugfs, su, usw. kopieren. Es wird sozusagen unser Arbeitsverzeichnis (engl. working directory; interessant dabei es gibt unter Linux den Befehl "pwd" der bedeutet "print working directory" d.h. man sieht in welchen Verzeichnis man sich gerade befindet falls mal der Überblick verloren geht.)
su ist die Kurzform von substitueuser und ermöglich es dem User (um es mit den Worten von Andri Od auszudrücken) sich als ein anderer User zu "verkleiden" oder auszugeben.
Mit shell bzw eigentlich adb shell kommt man auf die Shell des LT's. Ähnlich der CMD nur das die Befehle grundlegend auf Linux basieren und dieses Linux eine extrem abgespeckte Version ist.

(so, mal Zwischenspeichern bevor der Text bzw die Session flöten geht ^^)

$ cd /data/local/
$ mv tmp tmp.back

Das Dollar ($) Zeichen zeigt uns das wir uns mit dem Befehl "adb shell" auf die "cmd" des LTs begeben haben und nun die weiteren Befehl direkt am LT absetzen.
cd ist equivalent zum Dos Fenster und heißt "change directory". Wir wechseln also ins Verzeichnis /data/local/.
mv = move. Wir verschieben mit mv das vorhandene File tmp ins gleiche Verzeichnis wo es eh auch jetzt schon liegt, nämlich /data/local/ jedoch mit der Endung .back (steht für Backup). Im Grunde verschieben wir es gar nicht verschoben, sondern benennen es einfach um da sich auch der Speicherort für die Datei nicht ändert.

$ ln -s /dev/block/mmcblk0p3 tmp
$ exit

ln (LN) = link. Links, kennen wir vom Browser bzw Internetsurfen, sind nichts anderes wie anklickbare Texte welche einen Verweis auf eine Webseite darstellen. Anders genannt sind es Favoriten. Nun jetzt geht es nicht um Favoriten im eigentlichen Sinn sondern um die Bedeutung des Verlinkens. Mit ln erstellen wir also eine Verlinkung auf /dev/block/mmcblk0p3 und benennen das Ganze schlicht "tmp". Wie wenn ich z.B. die Seite Android Forum & Community - Android-Hilfe.de unter den Favoriten als "Bestes Forum ever" speichere Der Parameter "-s" gibt noch an das es sich um einen symbolischen Link oder Softlink handelt. Es gibt dann noch Hardlinks, block, usw. Wer den Unterschied kennenlernen will kann ja hier reinschauen (Q & A: The difference between hard and soft links LG #105).
Der Befehl "exit" lässt schon erahnen das man nun die shell verlässt und sich dann wieder auf der cmd befindet. Dieser Befehl ist ebenfalls gleich wie im Dos Fenster.

adb reboot
adb shell

Reboot führt einen Neustart des LTs durch. Da der Befehl von der cmd aus ausgeführt wird, muss adb vorangestellt werden. Ist der Reboot durchgeführt begeben wir uns wieder auf die Shell des LTs.

$ cd /data/local

$ zeigt uns wie vorhin erwähnt das wir uns wieder auf der shell befinden. In weiterer Folge wechseln wir mit cd ins Verzeichnis /data/local/.

$ toolbox chmod 755 /data/local/debugfs

Bei Toolbox bin ich selbst unsicher wo das herkommt weil mir der Befehl ansich unbekannt ist.
Die Information darüber habe ich hier gefunden:
xda-developers - View Single Post - ADB shell - Toolbox!

>adb -d shell busybox ls -la "/system/bin/*prop"
lrwxr-xr-x 1 0 2000 7 Dec 19 2009 /system/bin/getprop -> toolbox
lrwxr-xr-x 1 0 2000 7 Dec 19 2009 /system/bin/setprop -> toolbox

Dürfte in der shell hardcoded worden sein und ist eine Verlinkung auf busybox. Busybox wiederum ist eine Sammlung an Linux Befehlen:
Busybox - nookDevs

Gut wir führen also ein chmod aus. chmod heißt Change Mode wobei es sich um die Read, Write und Execute Rechte handelt.
Kurz erklärt:
Eine Datei unter Linux hat i.d.R. 3 Berechtigungsstufen.

drw-rw-r-- 2 unixguy uguys 96 Dec 8 12:53 mydir

Die Pipes (|) hab ich selbst eingefügt und sind normal nicht zu sehen. Die erste Stelle wird speziell behandelt und kann z.B. ein Verzeichnis sein (d), ein Link (l, L) oder ähnliches.
Die eigentichen Hinweise bzgl Berechtigungen erfolgt danach.
Hier hat das Verzeichnis "mydir" rw,rw,r das bedeutet der Owner (=Besitzer) hat Lese- und Schreibrechte auf das Verzeichnis, die Gruppe ebenfalls und alle anderen (Other) haben nur Leserechte darauf.
Der Owner heißt "unixguy", die Gruppe "uguys" und Other wird nie angeführt.

4 = Read also nur lesen
5 = Reade/Execute...lesen und ausführen
6 = Read/Write...lesen und schreiben
7 = Full...Volle Berechtigung also Read/Write/Execute
0 = Jedes Recht entzogen

Nachdem /data/local/debugfs auf 755 (Full-Read/Exe-Read/Exe) gesetzt wurde, kann der Befehl ausgeführt werden. An dieser stelle muss ich sagen weiß ich nicht (mehr) warum ein chmod überhaupt notwendig ist, wahrscheinlich aber wird sobald debugfs auf das LT gepushed wurde Rechte vom Filesystem festgelegt, mit der das Ausführen des Befehls nicht möglich ist.

$ /data/local/debugfs -w /data/local/tmp

Der Parameter "-w" wie schon am Anfang erwähnt vergibt Schreibrechte auf das angegebene Filesystem. Hier werden Schreibrechte auf /data/local/tmp vergeben.

debugfs: cd xbin

Wir wechseln in das Verzeichnis xbin. "BIN" wird unter Linux generell Binaries genannt und dabei handelt es sich um nichts anderes als ausführbare Programme.

debugfs: rm su
[Anmerkung: falls hier eine Fehlermeldung kommt, einfach ignorieren]

rm = remove. Das zielt lediglich darauf ab, ein evtl. in /system/xbin bereits vorhandenes su zu löschen. Ist bei unseren LTs nicht der Fall, daher kommt die zu ignorierende Fehlermeldung.

debugfs: write /data/local/su su

Hier wird die per adb auf /data/local/su gepushte Datei nach /system/xbin/su geschrieben. Man kann "su" auch direkt mal ausführen dann sieht man auch was dabei die Ausgabe wäre.

Für die nächsten Befehle wäre es wiederum gut zu wissen was Inodes sind: Understanding UNIX / Linux filesystem Inodes
Kurz gesagt alles in einem Linux/Unix Filesystem (Dateien, Ordner, Links, usw)hat eine Inode (ID demnach eindeutig im ganzen Filesystem) und die Inode ist immer eine Zahl mit mehreren Stellen.

debugfs: set_inode_field su mode [B][COLOR="Red"]010[/COLOR][COLOR="SeaGreen"]6[/COLOR][COLOR="DarkOrchid"]755[/COLOR][/B]
debugfs: set_inode_field su uid 0
debugfs: set_inode_field su gid 0

Im ersten set_inode_field wird dem Filesystem mitgeteilt, wie die frisch nach /system/xbin geschriebene Datei su "aussehen" soll.
Von links nach rechts:
010 = "normale" Datei (kein Link, kein Verzeichnis, kein Special File usw.)
6 = "Sticky Bits" für owner und group gesetzt
755 = rwxrwxr-x
Somit also im Ergebnis die Rechte für su: rwsrwsr-x

Im zweiten set_inode_filed wird die User-ID auf 0 gesetzt. Jeden User in einem Linux/Unix System kann über seinen Namen oder seine ID ansprechen.
Mit dem Befehl "id" bzw "adb shell id" wird angezeigt mit welchem User man gerade eingeloggt ist. In Klammer steht dann auch die User ID passend zum Namen. Dabei muss man wissen das der User "root" (der Allmächtige, wie bei Windows der User Administrator oder eher noch "System" weil selbst Administrator hat nicht alle Rechte, System hingegen schon) immer die ID 0 (Null) trägt. Wir wollen also dass das Programm "su" immer als "root" ausgeführt wird.

Zum Hintergrund Anmerkung von Andri Od:
Das wollen wir in der Tat, aber das wird erst in Kombination mit den "Sticky-Bits" von oben so. Unix/Linux führt Dateien immer im Kontext des Users aus, der gerade angemeldet ist, und zwar unabhängig davon, wem sie "gehören". Erst das "s" bei der Execute-Berechtigung von Owner und Gruppe führt die Datei in dem Kontext des Owners oder der Gruppe -i.d.F. root:root- aus.

Ebenso wird die "gid" (Group ID) auf "root" gesetzt. Wir hatten gelernt es gibt immer User, Group und Other. Für Other wird in diesem Fall die gleiche Berechtigung für die Gruppe vergeben.

Zum Hintergrund Anmerkung von Andri Od...ergänzend:
Die drei obigen debugfs-Kommandos sorgen also dafür, dass su mit root-Berechtigung ausgeführt wird.

Der Exploit kommt durch die Geschichte zustande, dass -bei ICS!- durch den init-Prozess /data/local/tmp Schreibberechtigung für shell:shell verpasst bekommt, und durch den symbolischen Link des Blockdevice-Files /dev/block/mmcblk0p3 auf /data/local/tmp das /system-Filesystem letzendlich diese Schreibberechtigung "erbt". Somit kann über debugfs das Binary su von shell:shell platziert und seine Rechte entsprechend angepasst werden.

debugfs: quit

Mit "quit" oder "q" kann aus dem Programm debugfs ausgestiegen werden.

$ rm /data/local/tmp
$ mv /data/local/tmp.back /data/local/tmp
$ exit

Die erste Zeile löscht das File "tmp", die Zweite benennt tmp.back zurück auf tmp und die Dritte beendet die shell.

adb reboot
adb shell

Danach wird das LT neu gestartet und wir steigen wieder in die Shell ein.

$ /system/xbin/su

Unter Linux kann man durch das Absetzen des Befehls "su" (ohne zusätzliche Parameter) die Berechtigung des Users "root" annehmen da ohne Parameter immer root genommen wird. Mit "su johnny" könnten die Rechte vom User "johnny" übernommen werden. (Versucht nicht die Rechte von "johnny" anzunehmen, es wird nicht funktionieren da es sich hierbei nur um ein Beispiel handelt )
Mit su (substitue user)wird man also mit root-Rechten ausgestattet und wer ist besser als ROOT (?)

# id
id=0(root) gid=0(root) .... das sollte so Aussehen, dann passt es
# exit

Nachdem wir also mit dem Befehl SU zu Root wurden können wir mit id prüfen, ob wir tatsächlich root sind. Wie erwähnt zeigt id an mit welchem User man gerade eingeloggt sind. Wenn also die Rückmeldung id=0 und gid=0 ausgegeben wird, wissen wir, wir sind wirklich der User root.
Mit exit wird die shell wieder beendet.

$ rm /data/local/su
$ rm /data/local/debugfs
$ exit

Danach wird su und debugfs gelöscht da wir diese Befehle nicht mehr benötigen und steigen aus der shell aus.

Edit: An dieser Stelle nochmal ein herzliches Dankeschön an Andri Od der meine Anleitung bzw Aufschlüsselung des Codegewirrs aufmerksam durchgelesen hat und Korrekturen mir per PN schickte. Sollte noch jemanden etwas auffallen, bitte einfach melden.

 

[164072]

...
2. Gestern habe ich die Auswertung von "id" gepostet und da steht "shell" demnach müsste ich als User "shell" in der adb shell eingeloggt sein und deshalb sollte ich auch bei HC die benötigten Rechte haben das Filesystem mit rw zu mounten.
...

Nein, eben nicht!

Die Anweisung in der /init.rc

[COLOR=SeaGreen]mkdir[/COLOR] /data/local/tmp [COLOR=Red]0771[/COLOR] [COLOR=Purple]shell shell

[/COLOR]wird, wie ich gestern ausgeführt habe, vom init-Prozess unter HC anders gehandhabt, als unter ICS. Während ICS implizit den "chmod 0771 /data/local/tmp" und den "chown shell:shell /data/local/tmp" auch dann durchführt, wenn der "mkdir"-Befehl selbst in die Hose geht (und das tut er, sobald /data/local/tmp existiert), tut HC an der Stelle gar nichts. Und deswegen bekommt das auf /data/local/tmp gelinkte Blockdevice /dev/block/mmcblk0p3 unter HC nach dem Reboot keine Schreibberechtigung für den User shell:shell.

Gruß A.O.

 

[norbert]

sofern sich nicht noch jemand findet, der sein Tablet unter Android 3.2 mit der Methode gerootet hat, würde ich im ersten Post einen entsprechenden Hinweis setzen, daß dafür zwingend 4.0 erforderlich ist.

 

[pseiko]

Achso das hatte ich dann falsch verstande. Ergibt natürlich Sinn. Und ein chown wiederum nicht möglich ist weil das FS dafür rw sein müsste. Eieiei des ewige kreisen. Schade aber auch. Ich wollte eh nicht ewig auf HC sitzen bleiben schon alleine weil ja mit ICS telefonieren möglich sein soll ?! Danke aber für den die ausführliche Information nochmal.

@ norbert
Ja wäre denk ich wirklich sinnvoll. Wenigstens haben wir aber so auch wiederum unser Wissen erweitern können was ja auch nicht schlecht ist.

Wie gesagt bei mir hat es mit ICS jetzt auch noch nicht funktioniert aber das Log dazu kann ich erst später posten. Hoffentlich klappts dann endlich.

 

[164072]

Für alle gerooteten würde ich dann noch empfehlen, die App
"OTA RootKeeper" aus dem Spielzeugladen zu installieren.
https://play.google.com/store/apps/details?id=org.projectvoodoo.otarootkeeper&hl=de

Damit wird eine Kopie des su-Binaries samt seiner Rechte an (nach bisherigen Erkenntnissen!) sicherer Stelle aufbewahrt.
Es kann sein, dass damit das LT im Fall der Fälle auch nach dem nächsten OTA-Update (falls da jemals noch eins kommen mag) wieder gerootet werden kann.
Außerdem kann man damit mal temporär un-rooten, falls man das möchte. Das funktioniert auch, ich habs probiert. Das su-Binary landet nach dem re-rooten zwar in /system/bin (statt /system/xbin), aber das tut keinen Abbruch.

@norbert: kann man vielleicht gleich mit als Tipp in das Eingangsposting des Threads mit aufnehmen.

Gruß
A.O.

 

[kaju]

Hallo Leute abgesehen davon, dass rooten nur mit ICS möglich ist/sei - wie bekommt ihr überhaupt ICS auf euer P9516 drauf? Ich versuchte schon alles ;Tablett aus, neu gestartet - update versucht ;sim Karte raus, sd Karte raus, neu gestartet, auch nix! Es kommt immer die Meldung "... das Betriebssystem ist auf dem neusten Stand.." Hotline von Medion angerufen, da bekommt man auch nur lasche Antworten. Die ehrlichste war, dass es eher ratsam wäre, das mit dem Updaten zu lassen, wegen den vielen Fehler. Gibt es eigentlich auch schon Custom Roms für das LT.?

 

[pseiko]

So endlich zuhause konnte ich die .bat zwar ausführen aber wie gesagt bekomme ich eine Fehlermeldung:

Installiere Superuser.apk...
failed to copy 'Superuser.apk' to '/data/local/tmp/Superuser.apk': No such file or directory

LifeTab neu starten. Kann 1-2 Minuten dauern...

Wenn Ihr LifeTab neu gestartet ist, ist es geROOTet!

Drücken Sie eine beliebige Taste . . .

EDIT: soooooooo endlich hab ich auch root Rechte. In meinem Fall war definitiv die .bat Datei von dirk Schuld denn als ich die Befehle nach norbert's Anleitung abgearbeitet hab hat alles funktioniert. ABER EBEN ERST NACHDEM ICH AUCH AUF ICS UPGEGRADED HATTE

Ich hab die Eingabe/Ausgabe mitgeloggt und wenn alles klappt sollte es wie folgt aussehen:

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\pseiko\Downloads>cd LT_rooten

C:\Users\pseiko\Downloads\LT_rooten>adb push debugfs /data/local/
1131 KB/s (1862336 bytes in 1.606s)

C:\Users\pseiko\Downloads\LT_rooten>adb push su /data/local/
699 KB/s (22364 bytes in 0.031s)

C:\Users\pseiko\Downloads\LT_rooten>adb shell
shell@android:/ $ cd /data/local
cd /data/local
shell@android:/data/local $ mv tmp tmp.back
mv tmp tmp.back
shell@android:/data/local $ exit
exit

C:\Users\pseiko\Downloads\LT_rooten>adb reboot

C:\Users\pseiko\Downloads\LT_rooten>adb shell
shell@android:/ $ cd /data/local
cd /data/local
shell@android:/data/local $ toolbox chmod 755 /data/local/debugfs
toolbox chmod 755 /data/local/debugfs
shell@android:/data/local $ /data/local/debugfs -w /data/local/tmp
/data/local/debugfs -w /data/local/tmp
debugfs 1.42 (29-Nov-2011)
debugfs:  cd xbin
cd xbin
debugfs:  rm su
rm su

debugfs:  write /data/local/su su
write /data/local/su su
Allocated inode: 20247
debugfs:  set_inode_field su mode 0106755
set_inode_field su mode 0106755
debugfs:  set_inode_field su uid 0
set_inode_field su uid 0
debugfs:  set_inode_field su gid 0
set_inode_field su gid 0
debugfs:  quit
quit
shell@android:/data/local $ rm /data/local/tmp
rm /data/local/tmp
shell@android:/data/local $ mv /data/local/tmp.back /data/local/tmp
mv /data/local/tmp.back /data/local/tmp
shell@android:/data/local $ exit
exit

C:\Users\pseiko\Downloads\LT_rooten>adb reboot

C:\Users\pseiko\Downloads\LT_rooten>adb shell
shell@android:/ $ /system/xbin/su
/system/xbin/su
shell@android:/ # id
id
uid=0(root) gid=0(root) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats)
shell@android:/ # exit
exit
shell@android:/ $ rm /data/local/su
rm /data/local/su
127|shell@android:/ $ rm /data/local/debugfs
rm /data/local/debugfs
shell@android:/ $ exit
exit

C:\Users\pseiko\Downloads\LT_rooten>

Was mir noch passiert ist, ich hab nach jedem Reboot des LTs es vom USB abstecken und neu anstecken müssen da es zwar im Gerätemanager erkannt wurde allerdings mit einem gelben Rufzeichen unter Tragbare Geräte aber im Computer/Arbeitsplatz es nicht aufschien. Erst nach ab-/anstecken war es nach jedem Reboot wieder da. Machte aber nix aus da es trotzdem funktioniert hat.

Eine abschließende Frage: Sollte man falsche Standorte und USB Debugging wieder deaktivieren?

 

[164072]

Ich hab die ausm Laden genommen:

https://play.google.com/store/apps/details?id=com.noshufou.android.su&hl=de