Mit Root auf 2.0.1

[mov]

so hab leicht den überblick verloren... vlt hilfts auch anderen.

Also mit root 2.0 (evt. gelöschten motonav usw.) kann man nicht auf das offizielle 2.0.1 updaten, sondern sollte auf das root 2.0.1 warten. Richtig?

Oder ist es doch möglich von Root 2.0 auf das offizielle 2.0.1 zu updaten? aber nur mit Rootverlust?

Und mit Root 2.0.1 ist es nicht möglich auf das offizielle 2.1 zu updaten. Sondern nur mit Costum Roms?

Danke für kurze Aufklärung
Nächtliche Grüße

 

[nodch]

Du kannst mit dem gerooteten 2.0er offiziell auf die 2.0.1 updaten. Willst du Root behalten, solltest du auf eine entsprechend angepasste 2.0.1 warten. So verhält es sich auch mit allen künftigen Updates.

 

[Spacefish]

Du kannst mit dem gerooteten 2.0er offiziell auf die 2.0.1 updaten. Willst du Root behalten, solltest du auf eine entsprechend angepasste 2.0.1 warten. So verhält es sich auch mit allen künftigen Updates.

Ist denn jetzt definitiv bekannt das 2.0.1 das su binary entfernt?

 

[sharky]

Ich denke das wäre erst dann bekannt, wenn jemand die update.zip die dem root exploit zu grunde liegt einspielt und vorher den root exploit einrichtet.
Und einmal mit offiziellem update auf 2.0.1 gibts bisher keinen weg zurück soweit ich weiss.

Ich für meinen teil versuchs lieber nicht.

 

[manolis]

oder die update.zip entpacken und schauen welche dateien installiert werden und welche scripte ausgeführt werden

 

[sharky]

da es sich um binary patches in einem proprietären format handelt (so hab ich zumindest nen post in einem anderen forum verstanden), ist das nicht ganz so einfach.

 

[micclass]

Ja, der patch ist binär und in einem zumindest mir nicht bekannten Format. Wenn man mit "zip -F update.zip" (natürlich auf einem Linux-System) den update fie wieder lesbar macht und dann mit "unzip update.zip" auspackt, erhält man die folgende Struktur:

./boot.img
./META-INF
./META-INF/MANIFEST.MF
./META-INF/CERT.SF
./META-INF/CERT.RSA
./META-INF/com
./META-INF/com/google
./META-INF/com/google/android
./META-INF/com/google/android/ssh.sh
./META-INF/com/google/android/updater-script
./META-INF/com/motorola
./META-INF/com/motorola/android
./META-INF/com/motorola/android/mtd.cfg
./install-recovery.sh
./recovery-from-boot.p
./bp.img
./SHOLS_U2_01.03.3_to_SHOLS_U2_01.15.0_REQ461.bin

Der letzte File (ca. 27MB gross) ist der eigentliche Patch. Das updater script sieht folgendermassen aus:

show_progress(0.500000, 0);
mount("MTD", "system", "/system");
package_extract_file("recovery-from-boot.p", "/system/recovery-from-boot.p");
package_extract_file("install-recovery.sh", "/system/etc/install-recovery.sh");
assert(package_extract_file("SHOLS_U2_01.03.3_to_SHOLS_U2_01.15.0_REQ461.bin", "/tmp/delta.bin"), package_extract_file("META-INF/com/motorola/android/mtd.cfg", "/tmp/mtd.cfg"), rb_fs_patch("/tmp/delta.bin", "/"), delete("/tmp/mtd.cfg"));
set_perm_recursive(0, 0, 0755, 0644, "/system/");
set_perm_recursive(0, 2000, 0755, 0755, "/system/bin");
set_perm(0, 3003, 02755, "/system/bin/netcfg");
set_perm(0, 3004, 02755, "/system/bin/ping");
set_perm_recursive(1002, 1002, 0755, 0440, "/system/etc/bluez");
set_perm(0, 0, 0755, "/system/etc/bluez");
set_perm(1002, 1002, 0440, "/system/etc/dbus.conf");
set_perm(1014, 2000, 0550, "/system/etc/dhcpcd/dhcpcd-run-hooks");
set_perm(0, 2000, 0550, "/system/etc/init.goldfish.sh");
set_perm(0, 0, 0544, "/system/etc/install-recovery.sh");
set_perm_recursive(0, 0, 0755, 0555, "/system/etc/ppp");
set_perm_recursive(0, 2000, 0755, 0755, "/system/usr/bin");
set_perm(0, 0, 0755, "/system/usr/bin");
set_perm_recursive(0, 2000, 0755, 0755, "/system/xbin");
unmount("/system");
assert(package_extract_file("boot.img", "/tmp/boot.img"),
write_raw_image("/tmp/boot.img", "boot"),
delete("/tmp/boot.img"));
assert(package_extract_file("bp.img", "/tmp/bp.img"),
write_raw_image("/tmp/bp.img", "bpsw"),
delete("/tmp/bp.img"));

Also ist klar, dass - zumindest ich - den update prozess nicht genug verstehe um daraus abzuleiten, ob das "su" binary beim update überschrieben wird oder nicht.

Gruss Micha

 

[micclass]

... gerade fällt mir beim querlesen noch auf, dass das Updatescript zumindest das Setuid-Bit des su Binaries zurücksetzen würde und damit "su" nicht mehr funktionieren würde ...

(So interpretier ich zumindest die zwei Zeilen
set_perm_recursive(0, 0, 0755, 0644, "/system/");
set_perm_recursive(0, 2000, 0755, 0755, "/system/bin");
aber man möge mich gerne eines besseren belehren ;-) )

Gruß Micha

 

[T045T]

Richtig, genau das hat ein Kollege bei Alldroid.org durch mutiges Ausprobieren rausgefunden oder zumindest sowas in der Art...

Ich hab mich mal schnell ein wenig eingelesen. Hier sind meine Ergebnisse soweit:
set_perm_recursive() und set_perm() nehmen Daten in der folgenden Reihenfolge an:

set_perm_recursive(uid, gid, ordner-berechtigungen, datei-berechtigungen, ordner-pfad)
set_perm(uid, gid, berechtigungen, ordner-/datei-pfad)

Die UID 2000 beschreibt die Gruppe der adb- und debug-shell-user. Wenn jetzt aber die permissions für alles in /system/bin (also auch su) auf 755 gesetzt werden, müsste man doch eigentlich immer noch Lese- und Ausführrechte (5) haben, wenn man su in der shell (oder sonstwo, andere User haben ja auch 5) aufruft, oder?

Wie passt das damit zusammen, dass es anscheinend doch nicht funktioniert?

Und zum Abschluss noch die Frage: Man kann das script nicht einfach verändern, damit die permissions von su in Ruhe gelassen werden, oder? Es gibt da eine checksum oder so was, richtig?

 

[sharky]

naja, wir wollen su ja aber mit root rechten ausführen und von daher bedarf es da des setuid bits.
siehe auch Setuid – Wikipedia

 

[micclass]

Ja genau so verstehe ich das auch "su" würde anschliessend 755 rechte haben statt 4755 (sprich das Suid-Bit wäre zurückgesetzt und genau das würde die funktion von su verhindern).
Das Script zu verändern dürfte nicht so einfach sein, da ja das ganze Zip File digital unterschrieben ist. Sprich man bräuchte den digtalen Schlüssel von Motorla (den hoffentlich niemand ausser Motorola selbst hat). Also da seh ich keine chance. Das geht erst, wenn jemand den updater so verändert hat, dass updates auch ohne digitale Unterschrift verwendet werden können.

 

[T045T]

hmm, okay, wieder was gelernt das mit dem suid-bit war mir nicht bewusst...
Also heißt es jetzt erst mal warten bzw frisch ans Werk (abhängig von den eigenen programmier- und hackfähigkeiten)?

 

[kuulthag]

Wann kommt es denn 2.0.1 Update nach Österreich oder Deutschland ? gibt es eine möglichkeit manuell zu update ?

 

[karmapolis]

Vielleicht ist das Entfernen des "noexec" Flagge von der sdcard Mount-Optionen für /etc/fstab? Ich weiß, es wäre ein Sicherheitsrisiko, aber ich meine es nur als ein Mittel, um während der Root-Update auf 2.0.1. Ich entschuldige mich für meine groben Deutsch.

 

[Archer]

Vielleicht ist das Entfernen des "noexec" Flagge von der sdcard Mount-Optionen für /etc/fstab? Ich weiß, es wäre ein Sicherheitsrisiko, aber ich meine es nur als ein Mittel, um während der Root-Update auf 2.0.1. Ich entschuldige mich für meine groben Deutsch.

Android does not rely on fstab - the file systems are mounted by the init.rc script which is in the initrd...