1. Nimm jetzt an unserem Uhans - 3. ADVENT - Gewinnspiel teil - Alle Informationen findest Du hier!

Mit Root auf 2.0.1

Dieses Thema im Forum "Root / Hacking / Modding für Motorola Milestone" wurde erstellt von mov, 19.01.2010.

  1. mov, 19.01.2010 #1
    mov

    mov Threadstarter Erfahrener Benutzer

    Beiträge:
    214
    Erhaltene Danke:
    12
    Registriert seit:
    03.01.2010
    Phone:
    Motorola Razr
    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
     
  2. nodch, 20.01.2010 #2
    nodch

    nodch Fortgeschrittenes Mitglied

    Beiträge:
    278
    Erhaltene Danke:
    104
    Registriert seit:
    26.06.2009
    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.
     
  3. Spacefish, 20.01.2010 #3
    Spacefish

    Spacefish Android-Hilfe.de Mitglied

    Beiträge:
    83
    Erhaltene Danke:
    31
    Registriert seit:
    12.01.2010
    Phone:
    Motorola Milestone
    Ist denn jetzt definitiv bekannt das 2.0.1 das su binary entfernt?
     
  4. sharky, 20.01.2010 #4
    sharky

    sharky Erfahrener Benutzer

    Beiträge:
    223
    Erhaltene Danke:
    45
    Registriert seit:
    12.12.2009
    Phone:
    Samsung Galaxy S5 G900F
    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.
     
  5. manolis, 20.01.2010 #5
    manolis

    manolis Neuer Benutzer

    Beiträge:
    6
    Erhaltene Danke:
    2
    Registriert seit:
    19.01.2010
    Phone:
    Motorola Milestone
    oder die update.zip entpacken und schauen welche dateien installiert werden und welche scripte ausgeführt werden
     
  6. sharky, 20.01.2010 #6
    sharky

    sharky Erfahrener Benutzer

    Beiträge:
    223
    Erhaltene Danke:
    45
    Registriert seit:
    12.12.2009
    Phone:
    Samsung Galaxy S5 G900F
    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.
     
  7. micclass, 20.01.2010 #7
    micclass

    micclass Neuer Benutzer

    Beiträge:
    12
    Erhaltene Danke:
    4
    Registriert seit:
    20.01.2010
    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
     
  8. micclass, 20.01.2010 #8
    micclass

    micclass Neuer Benutzer

    Beiträge:
    12
    Erhaltene Danke:
    4
    Registriert seit:
    20.01.2010
    ... 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
     
  9. T045T, 20.01.2010 #9
    T045T

    T045T Junior Mitglied

    Beiträge:
    35
    Erhaltene Danke:
    2
    Registriert seit:
    19.01.2010
    Richtig, genau das hat ein Kollege bei Alldroid.org durch mutiges Ausprobieren rausgefunden :D 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:
    Code:
    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?
     
  10. sharky, 20.01.2010 #10
    sharky

    sharky Erfahrener Benutzer

    Beiträge:
    223
    Erhaltene Danke:
    45
    Registriert seit:
    12.12.2009
    Phone:
    Samsung Galaxy S5 G900F
    naja, wir wollen su ja aber mit root rechten ausführen und von daher bedarf es da des setuid bits.
    siehe auch Setuid – Wikipedia
     
  11. micclass, 20.01.2010 #11
    micclass

    micclass Neuer Benutzer

    Beiträge:
    12
    Erhaltene Danke:
    4
    Registriert seit:
    20.01.2010
    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.
     
  12. T045T, 20.01.2010 #12
    T045T

    T045T Junior Mitglied

    Beiträge:
    35
    Erhaltene Danke:
    2
    Registriert seit:
    19.01.2010
    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)?
     
  13. kuulthag, 20.01.2010 #13
    kuulthag

    kuulthag Android-Hilfe.de Mitglied

    Beiträge:
    65
    Erhaltene Danke:
    0
    Registriert seit:
    21.03.2009
    Wann kommt es denn 2.0.1 Update nach Österreich oder Deutschland ? gibt es eine möglichkeit manuell zu update ?
     
  14. karmapolis, 20.01.2010 #14
    karmapolis

    karmapolis Neuer Benutzer

    Beiträge:
    1
    Erhaltene Danke:
    0
    Registriert seit:
    20.01.2010
    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.
     
  15. Archer, 20.01.2010 #15
    Archer

    Archer Android-Experte

    Beiträge:
    450
    Erhaltene Danke:
    81
    Registriert seit:
    17.07.2009
    Android does not rely on fstab - the file systems are mounted by the init.rc script which is in the initrd...
     

Diese Seite empfehlen