FAQ: root für das Milestone

[SeraphimSerapis]

Hallo Leute,
dieses FAQ soll helfen, einen aktuellen Überblick über das Thema "root für das Milestone" zu erhalten.

Natürlich kann ich keinen 100% Garantie auf Richtigkeit gewährleisten und bin auch gerne für Korrekturen/Ergänzungen offen.
Ich werde das FAQ mit der Zeit um ein paar Einträge ergänzen, und bitte zu berücksichtigen, dass ich das auch nur nebenbei mache

Gruß Tim

EDIT: Gerne natürlich auch Feedback

Wer das FAQ sucht - siehe Post #3

 

[nuutsch]

Ja wo ist es denn?

 

[SeraphimSerapis]

Einleitung: Was ist root?
nuutsch hat mich darum gebeten, eine kleine Einleitung zu root zu geben - eigentlich wollte ich das vermeiden, da hier bereits tausend Erklärungen im Board sind.
Da ich aber kein Unmensch bin (meiste Zeit), möchte ich also eine kurze Einleitung geben:

root bezeichnet den obersten Pfad in einem Linux-Dateiverzeichnis, er entspricht quasi der Wurzel, von dem die einzelnen Ordnerstrukturen ausgehen.
Was wir beabsichtigen ist, Superuser-Rechte (bei Windows Administrator) zu erhalten. Wer bereits mit Linux gearbeitet hat, kennt vielleicht Begriffe wie su, sudo und shell.
Es handelt sich hierbei um Befehle, welche ermöglichen, andere Befehle mit Superuser-Rechten auszustatten.

Wer sich auf seinem Android-Telefon das EingabekommandozeilentoolTerminal runterläd (ähnlich wie CMD bei Windows) und mal probeweise shell oder su eingibt,
wird mit einem freundlichen permission denied abgelehnt. Das selbe in grün wird der User erfahren, wenn er versucht in tiefere Ordnerstrukturen im /system-Pfad zu wechseln,
bzw. Befehle auf diese ausüben möchte - er wird ein Operation not permitted erhalten.

Unser Ziel ist es also mit root-Zugang tiefere Einflüsse auf unser Dateisystem zu haben.
Es ist angestrebt selbst elementarste Dateien auszutauschen, zu verändern oder zu löschen.

Weiterhin können wir nur durch root ein Custom-Recovery flashen, welches uns ermöglicht, verschiedene Custom-Roms zu flashen.
Mit einem Custom-Recovery wird nicht mehr auf die Standard-Signatur überprüft, und der User kann im Prinzip flashen, worauf er Lust hat.

ACHTUNG: Genau hier liegt die Gefahr - man kann im System ändern was man möchte - hierbei aber auch wichtige Dateien zerstören und sein Milestone unbrauchbar machen.
Es gilt also die neu erlangte Freiheit mit Bedacht einzusetzen, sich erstmal in das Thema einzulesen, und nicht alles zu flashen, was einem unter die Nase kommt.


Ich hoffe das reicht als Einleitung

Nun das FAQ:

-----------------------------------------------------------------------------------------------------------------------------------
1. Sind root vom Droid und vom Milestone kompatibel?
Leider nein. Das liegt vor allem daran, dass die Dateien wohl verschieden signiert sind.

2. Was genau bedeutet signiert?
Um zu gewährleisten, dass ausschließlich Updates von Motorola geflasht werden, werden diese Roms mit einem einzigartigen Schlüssel signiert.
Das bedeutet für uns, dass wir leider nur Buchstabenmüll sehen, wenn wir die Dateien öffnen.

3. Können wir nicht einfach den Schlüssel rausfinden?
Klar - wenn wir unsere Rechner kombinieren und ein paar Monate bis Jahre suchen lassen

4. Wie wird root auf dem Droid erreicht?
In Android 2.0 gibt es einen Exploit, welcher zulässt, dass Dateien bis zu einer Größe von weniger als 64K nicht korrekt auf ihre Signatur geprüft werden.
Dies bewirkt, dass man Archive in Archive injecten, also integrieren kann.

Dieser Exploit ist Google bereits bekannt gewesen und er wurde fehlerhaft behoben:

int i;
for (i = 4; i < eocd_size-3; ++i) {
         if (eocd[i  ] == 0x50 && eocd[i+1] == 0x4b &&
             eocd[i+2] == 0x05 && eocd[i+1] == 0x06) {
             // if the sequence $50 $4b $05 $06 appears anywhere after
             // the real one, minzip will find the later (wrong) one,
             // which could be exploitable.  Fail verification if
             // this sequence occurs anywhere after the real one.
             LOGE("EOCD marker occurs after start of EOCD\n");
             fclose(f);
             return VERIFY_FAILURE;
         }
     }

Wer ein bisschen Ahnung von Programmierung hat, wird sich sicherlich belustigt fühlen.

5. Hä!?
Es wird sich eine Eigenschaft von Android 2.0 zu eigen gemacht, welche dazu führt, dass Signaturen in Archiven in einer bestimmten Reihenfolge überprüft werden.

In normalen Archiven sieht das so aus (sehr stark vereinfacht):

[Zip header]
[Zip Content]
[Comment (the signature is in here)]
[6 byte footer] (this contains how long the comment is)

Diese Eigenschaft wird genutzt - es wird ein weiteres Archiv an das echte Update angehängt. Dieses enthält unseren Rootzugang in Form der Superuser.apk und einer su-Datei, welche uns den Zugriff für Shell/Su/Sudo ebnet.

Das sieht dann so aus (ebenfalls sehr stark vereinfacht):

[Zip header]
[Zip content]
[Comment (sig still here)]
[6 byte footer]
[Zip header]
[Zip content]
[Comment] (nothing exciting in this one)
[6 byte footer] (this is modified so the comment length is the length of the entire second zip file)

Zinx Verituse, ein Nutzer von Alldroid.org hat es geschafft diese Eigenheit zu nutzen, und hat ein Tool dazu geschrieben.
Dieses wird als Volez bezeichnet und hängt die beiden Archive zusammen.
Dieses Tool ist nur mit dem Droid kompatibel, aber er hat angekündigt, auch eins für das Milestone zu entwickeln.

Volez übernimmt zum Teil folgende Arbeit:

Windows CMD: copy /b UPDATEDATEI2.0.1.zip+DATEIMITSUPERUSERMODIFIKATION EN.zip update.zip

Es werden also zwei Updates kombiniert und ein neues geschaffen

6. Warum lese ich dauernd was über "root ohne Update auf 2.0.1"?
Weil man den Bug auch ausnutzen kann und eine künstlich vergrößerte Datei flashen kann, welche nur den root-Zugriff für Android 2.0 ermöglicht.
Hier gilt zu beachten, dass diese Datei die erste Möglichkeit war, root zu erhalten.

7. Warum müssen wir dann für die "root ohne Update auf 2.0.1"-Methode auf das Update warten?
Weil leider ein paar Dateien aus dem signierten Update extrahiert werden müssen und in das root-Archiv eingefügt werden müssen, damit das System denkt, es handelt sich um ein Update.

8. Hast du nicht angekündigt, root für das Milestone zu erreichen?
Das habe ich Aber da dies hier kein Einmann-Unternehmen sein muss, und sich umso schneller was tut, habe ich Kontakt mit Zinx Verituse aufgenommen und mir ein paar Tipps geben lassen.
Während dieses Gesprächs hat er auch angeboten uns zu helfen, indem er das Milestone für uns rootet, wenn wir ihm das originale Update liefern.
Wir sollten froh über diese Chance sein, da Zinx Verituse ein tiefes Verständnis für die Vorgänge da hat, während die Ergebnisse, die ich hatte zwar korrekt waren, aber sich nur um die sichtbaren Prozesse drehten.

9. Warum sollten wir eigentlich nicht erst das Update flashen?
Weil im aktuellen Repository der Exploit bereits korrekt behoben wurde - wir können nicht wissen (jedenfalls noch nicht, bis das Update raus ist), ob unser Update den Bug-Fix bereits enthält. Jedoch ist davon auszugehen.
In Amerika hat Verizon das Update vor dem Bug-Fix ausgeliefert und von daher können die User dort auch manuell auf 2.0.1 updaten und danach root erlangen.

Wir sollten erstmal vorsichtig sein, bevor wir uns den Zugang zu root verwähren, da es zur Zeit noch keine Info über einen weiteren root-Zugang gibt.

10. Werden die tollen amerikanischen Roms auf den Milestones laufen?
Jedenfalls nicht, ohne dass Zusatzmodifikationen gemacht werden.
Bei dem Milestone handelt es sich um ein GSM-Gerät, während das Droid auf CDMA basiert. Wie groß die zugehörigen Änderungen sind, und ob sie sich nur auf den Kernel beziehen ist mir leider nicht klar.

Dennoch kein Grund zur Sorge - auch in Europa haben wir fähige Entwickler.
MoDaCo, ein Spezialist aus England, hat sich bereits in der Vergangenheit einen Namen gemacht, indem er ein exzellentes Hero-Rom entwickelt hat.
Dieses wird auch stetig erweitert und optimiert.
Neben dem Hero-Rom hat MoDaCo auch ein sehr gutes Samsung Galaxy-Rom entworfen.
Weiterhin hat er das Acer Liquid als erster gerootet - auf jeden Fall ein Hoffnungsfunken

11. Also habe ich bald root, und dann kann ich meine Apps2SD speichern, busybox aufrufen, etc pp?
Nicht ganz - erstmal müssen solche Bestandteile entweder in Custom-Roms integriert sein, oder manuell in ein bereits bestehndes System gebracht werden.
Speziell für Apps2SD gibt es von daher leider noch keine automatische Lösung.
Es handelt sich hierbei aber nicht um Dinge der Unmöglichkeit und schon bald werden die ersten How-TOsfür das Milestone bestehen.

12. Wie funktioniert es Apps auf die Speicherkarte zu installieren?
Bei Apps2SD werden Links zwischen /system/app und /system/app-private auf die Speicherkarte angelegt.
Die Speicherkarte muss hierzu mindestens in eine normale FAT32-Partition und in eine EXT2-Partition geteilt werden.

Weiterhin muss die Speicherkarte gewisse Geschwindigkeitsanforderungen erfüllen - es wird von daher eine Class6-SDHC empholen.
Für die EXT-Partition wurden bisher immer 500-600MB empfohlen, was mit Sicherheit mehr als genug ist.

13. Welche Vorteile bietet Apps2SD?
Im Normalfall werden die Apps auf dem internen Speicher installiert.
Dies hat zur Folge, dass man nur eine limitierte Anzahl an Apps installieren kann.

Nutzt man Apps2SD hat man also den Vorteil, dass man sich um einen Faktor x höheren Speicherplatz für Apps schaffen kann, und von daher viel mehr Apps installieren kann.
Somit bleibt der interne Speicher für das System, Cache und ähnliches, während die Apps auf der EXT2/3/4-Partition der SD landen.

14. Was ist mit der Garantie?
Solange das Gerät gerootet ist, habt ihr keinen Anspruch mehr auf die Garantie.
Wenn das Gerät jedoch zur Zeit nicht gerootet ist, kein Custom-Rom, kein Custom-Recovery enthält, sprich komplett unrootet ist,
ist es im Normalfall auch nicht nachweisbar, und die Garantie ist wiederhergestellt.

15. Wie unrootet man?
Bei dem Droid wird momentan untersucht wie man das am Besten bewerkstelligen kann.

Das G1 und das Hero konnten zum Beispiel unrootet werden, indem man eine alte originale Firmware geflasht hat und diese sich mit originalen Updates
auf den neuesten Stand gebracht hat. Hierbei wurde auch das Custom-Recovery wieder durch das originale ersetzt.

Es ist davon auszugehen, dass bald aber sinnvolle Guides dafür bestehen.

16. Warum wird das Milestone nicht wie das Cliq mit RSD_Lite gerootet?
Weil wir leider noch keine boot.img-Datei vom Milestone haben.
Diese kann man erst mit root-Rechten erstellen.
Andere Quellen wären Updates und ähnliches, welche aber noch nicht erschienen sind.

 

[SeraphimSerapis]

Ja wo ist es denn?

Schau mal unter deinen Post - ich musste das doch erstmal schreiben

 

[Kranki]

Busybox einspielen ist ja ziemlich simpel, und Apps2SD sind im Grunde nur zwei Symlinks. Das wird nach dem ersten Rooten nicht lange dauern, bis das verfügbar ist.

 

[SeraphimSerapis]

Busybox einspielen ist ja ziemlich simpel, und Apps2SD sind im Grunde nur zwei Symlinks. Das wird nach dem ersten Rooten nicht lange dauern, bis das verfügbar ist.

Das ist mir auch bewusst Ich wollte damit nur ausdrücken, dass wir nicht sofort, nachdem wir root haben, die wildesten Geschichten auf dem Handy machen können

 

[Kranki]

Das ist mir auch bewusst Ich wollte damit nur ausdrücken, dass wir nicht sofort, nachdem wir root haben, die wildesten Geschichten auf dem Handy machen können

Das dauert sicher noch zwei Tage oder so.

 

[SeraphimSerapis]

Das dauert sicher noch zwei Tage oder so.

Als ich noch angefangen habe mit dem G1 habe ich mir Apps2SD auch selbst gebaut

 

[jamesb]

2. Was genau bedeutet signiert?
Um zu gewährleisten, dass ausschließlich Updates von Motorola geflasht werden, werden diese Roms mit einem einzigartigen Schlüssel verschlüsselt. Das bedeutet für uns, dass wir leider nur Buchstabenmüll sehen, wenn wir die Dateien öffnen.

Nein, an dem Update ist nichts verschluesselt. Verschluesselung und Signierung sind zwei paar Schuhe.

4. Wie wird root auf dem Droid erreicht?
In Android 2.0 gibt es einen Exploit, welcher zulässt, dass Dateien bis zu einer Größe von weniger als 63K nicht korrekt auf ihre Signatur geprüft werden.

Der Code Schnipsel sollte nur auf eine zweite ZIP innerhalb der ersten pruefen, es war also ein Versuch einen anderen Exploit zu verhindern und in diesem Fall sicherlich nicht der Exploit selbst.

5. Hä!?
...
Diese Eigenschaft wird genutzt - es wird ein weiteres Archiv an das echte Update angehängt.
...

Injected, nicht einfach "angehaengt".
Siehe erneut: Software:Root Access - Droid-Devs

Zinx Verituse, ein Nutzer von Alldroid.org hat es geschafft diese Eigenheit zu nutzen, und hat ein Tool dazu geschrieben.
Dieses wird als Volez bezeichnet und hängt die beiden Archive zusammen.
Dieses Tool ist nur mit dem Droid kompatibel, aber er hat angekündigt, auch eins für das Milestone zu entwickeln.

Volez ist recht ueberfluessig, einmal manuell ein passendes Update erstellen welches den bootloader austauscht um unsigned updates zu nehmen ist kein Beinbruch - und eh etwas mit dem selbst spatere ROM Entwickler nicht in Kontakt kommen sollten.

6. Warum lese ich dauernd was über "root ohne Update auf 2.0.1"?
Weil man den Bug auch ausnutzen kann und eine künstlich vergrößerte Datei flashen kann, welche nur den root-Zugriff für Android 2.0 ermöglicht.
Hier gilt zu beachten, dass diese Datei die erste Möglichkeit war, root zu erhalten.

"Kuenstlich vergroessert" ist wohl nicht die richtige Wortwahl.

7. Warum müssen wir dann für die "root ohne Update auf 2.0.1"-Methode auf das Update warten?
Weil leider ein paar signierte Dateien aus dem Update extrahiert werden müssen und in das root-Archiv eingefügt werden müssen, damit das System denkt, es handelt sich um ein Update.

Erneut, es fehlt an einem korrekt signierten Update (verschiedene signing keys droid/milestone). Es ist nicht notwendig irgendetwas aus dem Update zu extrahieren, zumindest nichts was nicht schon im droid update vorhanden gewesen waere. Und die einzelnen Dateien innerhalb des Update sind auch nicht signiert, sondern nur das Paket an sich.

Ein FAQ ist zwar eine nette Sache und mir ist bewusst das es nicht zu technisch sein sollte, aber das waren nun doch zu viele faktische Unzulaenglichkeiten.

 

[k1l]

moin,

ich wurde grade auf diesen thread aufmerksam gemacht im IRC: • View topic - Full, true root....
kann da einer mal reinschauen und sagen ob das auch mit dem Milestone funktionieren würde?
Ich kenne mich damit nicht aus und ich habe mein gerät noch nicht (dhl zu weihnachten ist bissel überfordert)

edit: die italiener fragen auch, ob die deutsche und italienische communitys in dem bereich zusammenarbeiten wollen

 

[SeraphimSerapis]

Ein FAQ ist zwar eine nette Sache und mir ist bewusst das es nicht zu technisch sein sollte, aber das waren nun doch zu viele faktische Unzulaenglichkeiten.

Dieses FAQ richtet sich nicht an Leute, denen der Stoff bewusst ist, sondern an jene, die sich einen groben Überblick verschaffen wollen.

Da ich mit Zinx Verituse gestern etwa 1 Stunde im IRC gechattet habe, und mich über einige Vorgänge informiert habe, kann ich sogar behaupten, dass er selber vieles nicht anders erklärt.

Ob jetzt etwas injected, integriert oder angehängt wird, ist dem End-User zum Beispiel egal.
Weiterhin trifft es "künstlich vergrößert" eigentlich, da hier ein sogenannter Payload in die Datei gebracht wird (<63K) welcher der eigentliche Kern des Updates ist.
Außenrum werden viele 0en (zero-byte entries) gelegt.

Mehr dazu hier: http://www.alldroid.org/viewtopic.php?f=210&t=626

Erneut, es fehlt an einem korrekt signierten Update (verschiedene signing keys droid/milestone). Es ist nicht notwendig irgendetwas aus dem Update zu extrahieren, zumindest nichts was nicht schon im droid update vorhanden gewesen waere. Und die einzelnen Dateien innerhalb des Update sind auch nicht signiert, sondern nur das Paket an sich.

Es wir die update-binary aus dem 2.0.1er Update benötigt, damit man rooten kann.
Das wird öfters wiederholt - deswegen gibt es root auch erst seit dem Erscheinen von 2.0.1
Es geht in diesem Punkt um das rooten ohne Update auf 2.0.1, sprich nicht injecten in das 2.0.1er Update

Ob Volez überflüssig ist oder nicht möchte ich nicht bewerten - solange es keine bessere Möglichkeit gibt (ein wirklich stabiles Recovery), wird Volez interessant bleiben, damit der Endanwender einfacher damit arbeiten kann.

Ich werde versuchen die Kritik dennoch zu übernehmen.

Gerne kannst du mir auch per PN korrigierte Abschnitte senden und ich werde diese dann im FAQ korrigieren.

edit: die italiener fragen auch, ob die deutsche und italienische communitys in dem bereich zusammenarbeiten wollen

ob die methode vom cliq fürs milestone auch funktioniert kann ich nicht sagen, da ja auch eine komplett andere android version vorliegt.

welche italiener?

 

[jamesb]

Ob jetzt etwas injected, integriert oder angehängt wird, ist dem End-User zum Beispiel egal.
Weiterhin trifft es "künstlich vergrößert" eigentlich, da hier ein sogenannter Payload in die Datei gebracht wird (<63K) welcher der eigentliche Kern des Updates ist.
Außenrum werden viele 0en (zero-byte entries) gelegt.

Mehr dazu hier: AllDroid.org - View topic - Crafting your own update.zip payload

Es sollte klar sein das schon auf Grund der Signierung die Aussage falsch sein muss.
Und genau so steht es auch in dem post:
Das mit der Zero non zip ist nur fuers offsetting, und in dem moment wo ein "zip -A update.zip" ausgefuehrt wird ist da nichts mehr mit "unheimlich vielen 0en".
1 min mit nem HEX Editor sollten dir reichen um deine Aussage zu revidieren.

Es wir die update-binary aus dem 2.0.1er Update benötigt, damit man rooten kann.
Das wird öfters wiederholt - deswegen gibt es root auch erst seit dem Erscheinen von 2.0.1
Es geht in diesem Punkt um das rooten ohne Update auf 2.0.1, sprich nicht injecten in das 2.0.1er Update

Nein, zum rooten wird schlicht und ergreifend die Signatur benoetigt damit der bootloader das Update annimmt. Das update-binary stellt nichts anderes zur verfuegung als die notwendigen Operationen, es ist sogar sehr wahrscheinlich fuers droid und das milestone identisch und wuerde sich im weiteren durch eine eigene Loesung austauschen lassen.

Ob Volez überflüssig ist oder nicht möchte ich nicht bewerten - solange es keine bessere Möglichkeit gibt (ein wirklich stabiles Recovery), wird Volez interessant bleiben, damit der Endanwender einfacher damit arbeiten kann.

Ein "Endanwender" wird sich damit gar nicht beschaeftigen muessen. Sobald das Rollout anfaengt wird innerhalb kuerzester Zeit simpler root Zugang von diversen Quellen verfuegbar sein.
Und auch das jetzige Recovery von sholes.info wird sehr schnell angepasst werden, es sind ja schlicht und ergreifend nur 256 Byte die atm fehlen.

Ich werde versuchen die Kritik dennoch zu übernehmen.

Lobenswert, aber besser waere es weniger vorschnell Halbwissen als Faktum darzustellen. Ob das jetzt als fies oder als gut gemeinter Ratschlag angesehen wird sei dem Betrachter ueberlassen.

 

[Thee]

Ich danke auf alle Fälle für die FAQ und freue mich sehr, dass wir hier mit jamesb einen weiteren Profi an Board haben. ;-)

 

[SeraphimSerapis]

Vielleicht kann jamesb noch ein paar Punkte hinzufügen, die ich dann an das Faq hänge.
Ich warte auf PNs

 

[sharky]

[Zip header]
[Zip content]
[Comment (sig still here)]
[6 byte footer]
[Zip header]
[Zip content]
[Comment] (nothing exciting in this one)
[6 byte footer] (this is modified so the comment length is the length of the entire second zip file)

Entweder stimmt das nicht, oder aber der post auf alldroid nicht.

3) the last 256+6 bytes of the payload must be the signature (which is the 256 bytes before the last 6 bytes in the donor) and the footer, which is <16-bit length of comment> 0xff 0xff <16-bit length of signature>

Demnach ist der "zweite" comment, also der des payload identisch mit dem comment des originalen updates (dem spender wie zinx das so schön ausdrück) da dort die signatur enthalten sei, gegen die geprüft wird.

Und ein kleiner schönheitsfehler: Der payload muss nicht kleiner 63k sein, sondern kleiner/gleich 63k oder aber anders ausgedrückt kleiner 64k.

 

[SeraphimSerapis]

Entweder stimmt das nicht, oder aber der post auf alldroid nicht.



Demnach ist der "zweite" comment, also der des payload identisch mit dem comment des originalen updates (dem spender wie zinx das so schön ausdrück) da dort die signatur enthalten sei, gegen die geprüft wird.

Und ein kleiner schönheitsfehler: Der payload muss nicht kleiner 63k sein, sondern kleiner/gleich 63k oder aber anders ausgedrückt kleiner 64k.

Ich werde es nachher, wenn ich zuhause bin ändern.
Was die zip Ascii-Veranschaulichung angeht - die habe ich von Alldroid.org aus dem Thread "how was root archieved?"

 

[jamesb]

Entweder stimmt das nicht, oder aber der post auf alldroid nicht.



Demnach ist der "zweite" comment, also der des payload identisch mit dem comment des originalen updates (dem spender wie zinx das so schön ausdrück) da dort die signatur enthalten sei, gegen die geprüft wird.

Die - sowieso recht vereinfachte - Darstellung als ASCII ist fehlerhaft.

signed-voles-ESD56-from-ESD20.84263456:
.. 5C 07 50 < letzte 3 Bytes der Signatur AC 06<footer_comment_len FF FF<delimiter BE 06<signature_start

donor_zip:
.. 5C 07 50 < letzte 3 Bytes der Signatur 09 65<footer_comment_len + donar_zip_len(le16) FF FF<delimiter 1B 65<signature_start

Gut zu sehen in verfier.c:

67        if (footer[2] != 0xff || footer[3] != 0xff) {
68            fclose(f);
69            return VERIFY_FAILURE;
70        }
71
72        int comment_size = footer[4] + (footer[5] << 8);
73        int signature_start = footer[0] + (footer[1] << 8);
74        LOGI("comment is %d bytes; signature %d bytes from end\n",
75             comment_size, signature_start);


174        if (RSA_verify(pKeys+i, eocd + eocd_size - 6 - RSANUMBYTES,
175                       RSANUMBYTES, sha1)) {

und auch aus volez.cc:

unsigned int footer_sig_len = le16(sig.footer + FOOTER_SIG_OFS) + offset - donor_zip.len;
unsigned int footer_comment_len = le16(sig.footer + FOOTER_COMMENT_OFS) + offset - donor_zip.len;

Wie man hier schon sehen kann stimmt meine Ausfuehrung oben auch nicht 100% weil noch die passendes offsets - durch das neue eocd - beachtet werden muessen.

 

[SeraphimSerapis]

Die - sowieso recht vereinfachte - Darstellung als ASCII ist fehlerhaft.

signed-voles-ESD56-from-ESD20.84263456:
.. 5C 07 50 < letzte 3 Bytes der Signatur AC 06<footer_comment_len FF FF<delimiter BE 06<signature_start

donor_zip:
.. 5C 07 50 < letzte 3 Bytes der Signatur 09 65<footer_comment_len + donar_zip_len(le16) FF FF<delimiter 1B 65<signature_start

Gut zu sehen in verfier.c:

67        if (footer[2] != 0xff || footer[3] != 0xff) {
68            fclose(f);
69            return VERIFY_FAILURE;
70        }
71
72        int comment_size = footer[4] + (footer[5] << 8);
73        int signature_start = footer[0] + (footer[1] << 8);
74        LOGI("comment is %d bytes; signature %d bytes from end\n",
75             comment_size, signature_start);


174        if (RSA_verify(pKeys+i, eocd + eocd_size - 6 - RSANUMBYTES,
175                       RSANUMBYTES, sha1)) {

und auch aus volez.cc:

unsigned int footer_sig_len = le16(sig.footer + FOOTER_SIG_OFS) + offset - donor_zip.len;
unsigned int footer_comment_len = le16(sig.footer + FOOTER_COMMENT_OFS) + offset - donor_zip.len;

Wie man hier schon sehen kann stimmt meine Ausfuehrung oben auch nicht 100% weil noch die passendes offsets - durch das neue eocd - beachtet werden muessen.

wenn wir das in eine verständlichere einfache ascii-grafik packen können, übernehme ich das gerne von dir.
klingt auf jeden fall verständlich

habe schonmal das faq inzwischen in ein paar punkten editiert und auf <64k korrigiert

 

[Edgar_Wibeau]

Na, solange ihr euch nur einigen könnt

Vielen Dank jedenfalls an SeraphimSerapis, jamesb und sharky - und natürlich an alle, die hier mithelfen, aufklären und Verwirrung stiften

 

[SeraphimSerapis]

Ach das kriegen wir schon hin Wie gesagt - es soll ja auch keine 100% Richtigkeit haben, sondern einfach nur eine Art Leitfaden werden (jedenfalls war das meine Intension)