Wir rooten das Milestone [Gelöst]

[SeraphimSerapis]

Dieser Thread ist Teil vom OTA-Thread, bei dem es ums rooten des Milestone geht. Da das ganze im OTA-Thread OT ist, hier ein neuer Thread


Ich habe Kontakt mit dem "Urrooter" und MoDaCo aufgenommen, und nach Zusammenarbeit gefragt, damit auch wirklich ein gültiges update.zip dabei rauskommt.

Leider kann ich das bisher ja noch nicht testen, und auf ein gebricktes Phone hat hier niemand Lust.

Bin mal gespannt.

EDIT: Um euch mal zu zeigen wo ich momentan bin, bzw. was für uns zur Zeit das Problem ist:
Das ist mein bisheriges Ergebnis: http://h1377582.stratoserver.net/milestone/update.zip

Flashen bringt noch nichts.. die Signatur ist falsch. ( <- wer damit sein Phone zerstört o.ä. ist selbst schuld )
Das droid-Update hat eine Datei-Größe von etwa 10,2 MB, obwohl es sich nur um unter 63K Inhalt handelt.

Im droid-Update ist eine "update-binary" vorhanden, welche laut dem "Urrooter" die "update-script"-Datei interpretiert.
Da die binary aber verschlüsselt ist, und beim G1 damals so eine Datei nicht in den updates vorhanden ist, kann ich nicht genau sagen,
was ich mit der Datei anfangen soll - oder ob es dann mit 2.0.1 reicht, wenn ich die Datei aus dem 2.0.1er Update entnehme, und in mein
Update integriere.

Bin für Ideen gerne offen:
Probleme:
1. Wieso ist die droid-root.zip 10,2mb groß, und das ohne Inhalt?
2. Was macht die "update-binary"-Datei?
3. Können wir die "update-binary" umgehen, um ohne 2.0.1 root zu erlangen?

Gruß Tim

 

[hope13]

Ich habe Kontakt mit dem "Urrooter" und MoDaCo aufgenommen, und nach Zusammenarbeit gefragt, damit auch wirklich ein gültiges update.zip dabei rauskommt.

Leider kann ich das bisher ja noch nicht testen, und auf ein gebricktes Phone hat hier niemand Lust.

Bin mal gespannt.

EDIT: Um euch mal zu zeigen wo ich momentan bin, bzw. was für uns zur Zeit das Problem ist:
Das ist mein bisheriges Ergebnis: http://h1377582.stratoserver.net/milestone/update.zip

Flashen bringt noch nichts.. die Signatur ist falsch. ( <- wer damit sein Phone zerstört o.ä. ist selbst schuld )
Das droid-Update hat eine Datei-Größe von etwa 10,2 MB, obwohl es sich nur um unter 63K Inhalt handelt.

Im droid-Update ist eine "update-binary" vorhanden, welche laut dem "Urrooter" die "update-script"-Datei interpretiert.
Da die binary aber verschlüsselt ist, und beim G1 damals so eine Datei nicht in den updates vorhanden ist, kann ich nicht genau sagen,
was ich mit der Datei anfangen soll - oder ob es dann mit 2.0.1 reicht, wenn ich die Datei aus dem 2.0.1er Update entnehme, und in mein
Update integriere.

Bin für Ideen gerne offen:
Probleme:
1. Wieso ist die droid-root.zip 10,2mb groß, und das ohne Inhalt?
2. Was macht die "update-binary"-Datei?
3. Können wir die "update-binary" umgehen, um ohne 2.0.1 root zu erlangen?

Gruß Tim

Kannst du mal das Droid Update zur Verfügung stellen.

 

[SeraphimSerapis]

Kannst du mal das Droid Update zur Verfügung stellen.

selbstverständlich: 4shared.com - online file sharing and storage - download droid-root.zip

andere Quellen hier: AllDroid.org - View topic - How to Root your Droid<<<ONLY

Das ist btw auch der Thread, wo erste Erklärungen gemacht werden.

Es könnte auch reichen, wenn wir meine Datei einfach an das originale 2.0.1er Update (auf welches wir warte) mit folgender Methode anhängen:
Windows (mit CMD):

copy /b UPDATEDATEI2.0.1.zip+DATEIMITSUPERUSERMODIFIKATIONEN.zip update.zip

 

[janus_01]

Coole Sache, dass sich mal was mit Root tut (reimt sich)...

Und Nuutsch übernimmt den Telefonterror...!

Fröhliche Weihnachten...

 

[herrlado]

Der hat doch dieses Tool zur Verfügung gestellt, womit man es bequem mergen kann? Siehe Anhang!

selbstverständlich: 4shared.com - online file sharing and storage - download droid-root.zip

andere Quellen hier: AllDroid.org - View topic - How to Root your Droid<<<ONLY

Das ist btw auch der Thread, wo erste Erklärungen gemacht werden.

Es könnte auch reichen, wenn wir meine Datei einfach an das originale 2.0.1er Update (auf welches wir warte) mit folgender Methode anhängen:
Windows (mit CMD):

 

[herrlado]

Und hier steht nochmal ganz genau wie/warum der Hack möglich wurde
Software:Root Access - Droid-Devs

 

[brahma]

1. Wieso ist die droid-root.zip 10,2mb groß, und das ohne Inhalt?

DAS ist eine sehr gute Frage....

260K ./META-INF/com/google/android/update-binary
4,0K ./META-INF/com/google/android/updater-script
268K ./META-INF/com/google/android
272K ./META-INF/com/google
276K ./META-INF/com
280K ./META-INF
11M ./droid-root.zip
76K ./system/bin/su
80K ./system/bin
84K ./system
11M .
11M insgesamt

Dabei sei angemerkt das . so gross ist weil im gleich Verzeichnis eben die droid-root-zip liegt....

 

[SeraphimSerapis]

DAS ist eine sehr gute Frage....

Dabei sei angemerkt das . so gross ist weil im gleich Verzeichnis eben die droid-root-zip liegt....

Genau das wundert mich eben auch - ich kann nicht nachvollziehen, woher die 10,xx MB kommen, die nicht in der .zip sind. Es handelt sich hierbei ja nicht um die root-Datei, welche an das reguläre Update gehängt wurde.

Der hat doch dieses Tool zur Verfügung gestellt, womit man es bequem mergen kann? Siehe Anhang!

hallo herrlado, das tool sollte im prinzip das selbe tun, was der cmd befehl auch macht.

dennoch natürlich praktisch

 

[hope13]

Genau das wundert mich eben auch - ich kann nicht nachvollziehen, woher die 10,xx MB kommen, die nicht in der .zip sind. Es handelt sich hierbei ja nicht um die root-Datei, welche an das reguläre Update gehängt wurde.



hallo herrlado, das tool sollte im prinzip das selbe tun, was der cmd befehl auch macht.

dennoch natürlich praktisch


Ich wäre dafür, dass wir mal ins Root-Forum umziehen, da dieser Thread hier ja das reguläre Update betrifft.

Kann mir das so vorstellen wie es unter Mac OS auch geht, man erstellt ein Volumen mit fester Größe und schiebt dann Daten rein...fertig

so sieht das für mich auf jeden Fall so aus und hilft vielleicht ein Sauberes Update zu gewährleisten, das eben mehr Ressourcen angefordert werden als letztendlich gebraucht wird.

 

[Edgar_Wibeau]

SeraphimSerapis: Es gibt nur ein Problem:
droid-superuser.zip von alldroid.org ist ein (unvollständiges) Archiv zum Anhängen, es enthält einen gefälschten Zip-Header mit der resultierenden Dateiendung. Das funktioniert, weil bei Zips der Header nicht am Anfang steht, sondern am Ende. Beim Auspacken gibt es folgende Meldung:

$ unzip droid-superuser.zip
Archive:  droid-superuser.zip
error [droid-superuser.zip]:  missing 10648643 bytes in zipfile
  (attempting to process anyway)
  inflating: META-INF/com/google/android/updater-script
error [droid-superuser.zip]:  attempt to seek before beginning of zipfile
  (please check that you have transferred or created the zipfile in the
  appropriate BINARY mode and that you have compiled UnZip properly)
  inflating: system/bin/su
  inflating: system/app/Superuser.apk

Es enthält also nur die Dateien
META-INF/com/google/android/updater-script,
system/bin/su und
system/app/Superuser.apk,
letzteres enthält wiederum eine Menge Zeugs, von dem ich rein garnichts verstehe

$ unzip system/app/Superuser.apk
Archive:  system/app/Superuser.apk
  inflating: META-INF/MANIFEST.MF
  inflating: META-INF/CERT.SF
  inflating: META-INF/CERT.RSA
  inflating: AndroidManifest.xml
  inflating: classes.dex
 extracting: res/drawable/icon.png
  inflating: res/layout-land/request.xml
  inflating: res/layout-port/request.xml
  inflating: res/layout/main.xml
  inflating: res/layout/permission_item.xml
 extracting: resources.arsc

Nachtrag: dein Zip enthält die selben drei Dateien (plus Verzeichnis-Infos, ich weiß nicht, ob das ein Problem sein kann), aber nicht den notwendigen gefälschten Header.

 

[Edgar_Wibeau]

Der signierte Teil (sowohl beim "signed-voles-ESD56-from-ESD20.84263456.zip" als auch beim 10,2-MB-update-zip-mit-root "droid-root.zip") muss sich irgendwo in den Meta-Daten des Zips finden, ich hab keine Ahnung, wie das funktioniert. Ich vermute also weiterhin, dass nicht das "META-INF/com/google/android/update-binary" die Signatur enthält, sondern das Zip eben irgendwie signiert ist, wenn ich es auspacke kommt folgende Meldung:

$ unzip signed-voles-ESD56-from-ESD20.84263456.zip       
Archive:  signed-voles-ESD56-from-ESD20.84263456.zip                         
signed by SignApk                                                               
  inflating: META-INF/MANIFEST.MF                                               
  inflating: META-INF/CERT.SF                                          
[...]

Es gibt also eine Anwendung "SignApk" (im SDK ohne weitere Downloads, also ohne die APIs hab ich's jedenfalls nicht gefunden), welche Zips entsprechend signieren kann, diese Signatur liegt vermutlich nicht wie der Zip-Index am Ende des Zips. Die Größe der "droid-root.zip" gehört jedenfalls zum Schummel-Spiel, deshalb ist sie wohl mit Unkraut (vermutlich schlicht Nullen) gefüllt und enthält irgendwo mittendrin oder am Anfang die Signatur und am Ende die drei Dateien. Und natürlich den neuen Zip-Header.

 

[severance_]

Hallo!!

Ich kenne mich zwar beim Thema root nicht wirklich aus, dennoch verfolge ich jede seite die ich dazu finde (und das sind reichlich) ... =)

Trotzdem will ich vielleicht einen kleinen Beitrag dazu leisten (was wahrscheinlich 'eh nicht wird - aber egal)

SignApk.zip

die datei hab ich geladen und da sind 4 dateien drinnen ..
signapk.jar
readme.txt
testkeypk8
testkey.x509.pem

vielleicht nutzts ja ^^

lg

 

[SeraphimSerapis]

Der signierte Teil (sowohl beim "signed-voles-ESD56-from-ESD20.84263456.zip" als auch beim 10,2-MB-update-zip-mit-root "droid-root.zip") muss sich irgendwo in den Meta-Daten des Zips finden, ich hab keine Ahnung, wie das funktioniert. Ich vermute also weiterhin, dass nicht das "META-INF/com/google/android/update-binary" die Signatur enthält, sondern das Zip eben irgendwie signiert ist, wenn ich es auspacke kommt folgende Meldung:

$ unzip signed-voles-ESD56-from-ESD20.84263456.zip       
Archive:  signed-voles-ESD56-from-ESD20.84263456.zip                         
signed by SignApk                                                               
  inflating: META-INF/MANIFEST.MF                                               
  inflating: META-INF/CERT.SF                                          
[...]

Es gibt also eine Anwendung "SignApk" (im SDK ohne weitere Downloads, also ohne die APIs hab ich's jedenfalls nicht gefunden), welche Zips entsprechend signieren kann, diese Signatur liegt vermutlich nicht wie der Zip-Index am Ende des Zips. Die Größe der "droid-root.zip" gehört jedenfalls zum Schummel-Spiel, deshalb ist sie wohl mit Unkraut (vermutlich schlicht Nullen) gefüllt und enthält irgendwo mittendrin oder am Anfang die Signatur und am Ende die drei Dateien. Und natürlich den neuen Zip-Header.

Und genau hier liegt aktuell mein Problem - wie signiere ich die Dateien und vor allem - mit was - meine Testkeys werden ja sicherlich nicht genügen.

Dann halt weiterhin die Frage - was packe ich rein, damit ich auf 10,2 MB komme?

Hallo!!

Ich kenne mich zwar beim Thema root nicht wirklich aus, dennoch verfolge ich jede seite die ich dazu finde (und das sind reichlich) ... =)

Trotzdem will ich vielleicht einen kleinen Beitrag dazu leisten (was wahrscheinlich 'eh nicht wird - aber egal)

SignApk.zip

die datei hab ich geladen und da sind 4 dateien drinnen ..
signapk.jar
readme.txt
testkeypk8
testkey.x509.pem

vielleicht nutzts ja ^^

lg

Ein Problem ist, dass man mit SignAPK wohl auch wirklich nur APK-Dateien signieren kann - gilt das auch für Updates?

 

[brahma]

Hab mal versucht auszulesen was geht:

Archive: droid-root.zip
There is no zipfile comment.

End-of-central-directory record:
-------------------------------

Zip archive file size: 10698767 (0000000000A3400Fh)
Actual end-cent-dir record offset: 10698483 (0000000000A33EF3h)
Expected end-cent-dir record offset: 10698483 (0000000000A33EF3h)
(based on the length of the central directory and its expected offset)

This zipfile constitutes the sole disk of a single-part archive; its
central directory contains 9 entries.
The central directory is 814 (000000000000032Eh) bytes long,
and its (expected) offset in bytes from the beginning of the zipfile
is 10697669 (0000000000A33BC5h).

Und zu jeder Datei kann man natürlich auch was rausfinden, steht aber nix unerwartetes drin:

Central directory entry #1:
---------------------------

system/

offset of local header from start of archive: 10648637
(0000000000A27C3Dh) bytes
file system or operating system of origin: Unix
version of encoding software: 3.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 1.0
compression method: none (stored)
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2009 Dec 8 15:15:08
file last modified on (UT extra field modtime): 2009 Dec 8 22:15:07 local
file last modified on (UT extra field modtime): 2009 Dec 8 21:15:07 UTC
32-bit CRC value (hex): 00000000
compressed size: 0 bytes
uncompressed size: 0 bytes
length of filename: 7 characters
length of extra field: 24 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (040755 octal): drwxr-xr-x
MS-DOS file attributes (10 hex): dir

The central-directory extra field contains:
- A subfield with ID 0x5455 (universal time) and 5 data bytes.
The local extra field has UTC/GMT modification/access times.
- A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
01 04 e8 03 00 00 04 e8 03 00 00.

There is no file comment.

Central directory entry #2:
---------------------------

system/bin/

offset of local header from start of archive: 10648702
(0000000000A27C7Eh) bytes
file system or operating system of origin: Unix
version of encoding software: 3.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 1.0
compression method: none (stored)
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2009 Dec 8 15:15:14
file last modified on (UT extra field modtime): 2009 Dec 8 22:15:13 local
file last modified on (UT extra field modtime): 2009 Dec 8 21:15:13 UTC
32-bit CRC value (hex): 00000000
compressed size: 0 bytes
uncompressed size: 0 bytes
length of filename: 11 characters
length of extra field: 24 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (040755 octal): drwxr-xr-x
MS-DOS file attributes (10 hex): dir

The central-directory extra field contains:
- A subfield with ID 0x5455 (universal time) and 5 data bytes.
The local extra field has UTC/GMT modification/access times.
- A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
01 04 e8 03 00 00 04 e8 03 00 00.

There is no file comment.

Central directory entry #3:
---------------------------

system/bin/su

offset of local header from start of archive: 10648771
(0000000000A27CC3h) bytes
file system or operating system of origin: Unix
version of encoding software: 3.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: deflated
compression sub-type (deflation): normal
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2009 Dec 8 15:15:14
file last modified on (UT extra field modtime): 2009 Dec 8 22:15:13 local
file last modified on (UT extra field modtime): 2009 Dec 8 21:15:13 UTC
32-bit CRC value (hex): 2c91e572
compressed size: 48202 bytes
uncompressed size: 72188 bytes
length of filename: 13 characters
length of extra field: 24 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (100755 octal): -rwxr-xr-x
MS-DOS file attributes (00 hex): none

The central-directory extra field contains:
- A subfield with ID 0x5455 (universal time) and 5 data bytes.
The local extra field has UTC/GMT modification/access times.
- A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
01 04 e8 03 00 00 04 e8 03 00 00.

There is no file comment.

Den Rest spar ich mir aufgrund der Länge mal

 

[sharky]

Habt ihr euch schonmal die mühe gemacht das droid-root.zip archiv mit nem hex editor anzusehen?
Dann dürftet ihr erkennen, dass sich dort eigentlich noch weitaus mehr Dateien verstecken.
Unter anderem eine Manifest Datei, sowie Zertifikate und evtl gepatchte Dateien.
bspw. patch/boot.img oder auch patch/system/app/AlarmClock.apk sowie patch/system/app/AlarmClock.odex

Jetzt fragt mich aber nicht wie man diese extrahiert, da kann ich euch keine Antwort drauf liefern.
Aber nach der Ausgabe die Edgar_Wibeau beim entpacken erhalten hat, scheint es sich ja nicht um ein "standard konformes" zip archiv zu handeln. Von daher wunderts mich nicht wirklich, dass man nicht ohne weiters alles entpacken kann.

 

[SeraphimSerapis]

Ich hoffe Zinx Verituse killt mich nicht - ich habe ihm einfach mal eine Mail geschrieben, was die Dateigröße angeht.

Wenn er antwortet, poste ich es hier.

Habt ihr euch schonmal die mühe gemacht das droid-root.zip archiv mit nem hex editor anzusehen?
Dann dürftet ihr erkennen, dass sich dort eigentlich noch weitaus mehr Dateien verstecken.
Unter anderem eine Manifest Datei, sowie Zertifikate und evtl gepatchte Dateien.
bspw. patch/boot.img oder auch patch/system/app/AlarmClock.apk sowie patch/system/app/AlarmClock.odex

Jetzt fragt mich aber nicht wie man diese extrahiert, da kann ich euch keine Antwort drauf liefern.
Aber nach der Ausgabe die Edgar_Wibeau beim entpacken erhalten hat, scheint es sich ja nicht um ein "standard konformes" zip archiv zu handeln. Von daher wunderts mich nicht wirklich, dass man nicht ohne weiters alles entpacken kann.

Darüber habe ich auch nachgedacht - dann ist aber die Frage - woher stammen die Dateien?
Er schreibt ja, dass es sich nicht um das Update auf 2.0.1 handelt.

Bei der anderen Methode nimmt er ja das Update, und hängt die root.zip hintenran.

 

[jamesb]

Ich vermute also weiterhin, dass nicht das "META-INF/com/google/android/update-binary" die Signatur enthält, sondern das Zip eben irgendwie signiert ist

Die Signatur ist im Comment Teil des offiziellen Updates enthalten.

Diese Signatur liegt vermutlich nicht wie der Zip-Index am Ende des Zips. Die Größe der "droid-root.zip" gehört jedenfalls zum Schummel-Spiel, deshalb ist sie wohl mit Unkraut (vermutlich schlicht Nullen) gefüllt und enthält irgendwo mittendrin oder am Anfang die Signatur und am Ende die drei Dateien. Und natürlich den neuen Zip-Header.

Nein, die kompletten Daten des offiziellen Updates sind weiterhin vorhanden + angehaengte neue ZIP mit passender payload und einem editiertem footer der diesen neuen Inhalt komplett als comment ausgibt.
Der footer (6Byte) einer ZIP Datei beschreibt die Groesse des vorherigen comments, daher auch die Limitierung bzgl. der Groesse der modifizierten 2. ZIP.

Dies kann man auch sehr schoen sehen indem man die neue ZIP einfach mal mit einem HEX Editor betrachtet.

Durch diesen Umstand findet das Auslesen der Signatur und auch das verifizieren nur mit dem "orginal Teil" des Updates stat.

Das ist ja der ganze Witz an der Sache welches eigentlich durch den bekannten code Schnipsel in verifier.c verhindert werden sollte.

EDIT: Und nach der Verifizierung verhaelt es sich genauso wie daheim, sprich nur der Inhalt der "hinzugefuegten" ZIP wird verwendet bzw. beim extrahieren beachtet.

 

[Kranki]

Ich hoffe Zinx Verituse killt mich nicht - ich habe ihm einfach mal eine Mail geschrieben, was die Dateigröße angeht.

Das Ding ist von Zinx? Wenn der Name kein unglaublicher Zufall ist, ist der Op in #cyanogenmod auf Freenode, und hängt da auch immer in #android-root rum. Vielleicht ist das eine bessere Kontaktmöglichkeit.
Topic in #android-root ist übrigens "Milestone users: WE NEED AN UPDATE.ZIP". Denke schon, dass da jemand bereit ist, zu erklären, wie man zum Milestone-root kommt.

 

[brahma]

EDIT: Und nach der Verifizierung verhaelt es sich genauso wie daheim, sprich nur der Inhalt der "hinzugefuegten" ZIP wird verwendet bzw. beim extrahieren beachtet.

Versteh ich das richtig? Von den 10,2 MB (org. update.zip + 2. zip) wird nur die 2. Zip-Datei, also deren Inhalt von den paar KB, entpackt da durch das Zusammenfügen im Gesamtzip nur das "Inhaltsverzeichnis" des 2. Zip behalten wurde/vorhanden ist und somit das org. update-zip nicht indexierter "Datenmüll" im Zip-file ist?

PS: Sorry, bin sonst tar-user, zip ist mir mehr ein notwendiges Übel aus der Win-Welt

 

[jamesb]

Versteh ich das richtig? Von den 10,2 MB (org. update.zip + 2. zip) wird nur die 2. Zip-Datei, also deren Inhalt von den paar KB, entpackt da durch das Zusammenfügen im Gesamtzip nur das "Inhaltsverzeichnis" des 2. Zip behalten wurde/vorhanden ist und somit das org. update-zip nicht indexierter "Datenmüll" im Zip-file ist?

PS: Sorry, bin sonst tar-user, zip ist mir mehr ein notwendiges Übel aus der Win-Welt

Fast, so gesehen sind 2 korrekte Inhaltsverzeichnisse vorhanden, nur wird beim entpacken von Hinten angefangen (und da wird sich auch nit drum gescherrt das im footer behauptet wird die ganze 2. ZIP sei nur ein comment) und sobald ein Header erreicht ist wird die Sache als erledigt angesehen.