[Tool] update.zip als komplettes ROM Update nutzen

  • 48 Antworten
  • Neuester Beitrag
Diskutiere [Tool] update.zip als komplettes ROM Update nutzen im Root / Hacking / Modding für Motorola Defy im Bereich Motorola Defy Forum.
Sqoerk

Sqoerk

Erfahrenes Mitglied
Hallo Motorola-Bootloader-Geschädigte :lol:

bei den XDAs ist ein interessanter Thread aufgekommen. Dort hat jemand (eugene373) ein signiertes update.zip erstellt, mit dem man ein komplett neues ROM ohne SBF flashen kann. In der ZIP-Datei ist folgendes drin:

  • system mit allen Dateien
  • boot.img
  • device_tree.bin
  • ein kernel-flash-Script
  • ein update-Script
  • ein "vor"-update-Script
Desweiteren hat er ein Marketapp rausgebracht, das eine solche ZIP Datei einspielen kann. Hierbei handelt es sich wieder um eine Bootstrap-Methode, so wie beim Clockwork-Mod.

Diese entwicklung klingt recht interessant, da man aus einem lauffähigen System heraus ein komplett neues System aufspielen kann.

Ich habe es aus Zeitmangel leider noch nicht probieren können, wird am WE kommen.

Hier der link zum Thread: [ROM](Working Update.zip) -> Defy Update.zip Cookie Cutter Rom - xda-developers

Und schonmal was er geschrieben hat:
Defy Froyo 3.4.2 Cookie Cutter Rom


Q. How Do I use the Update.zip?
A. Go to Market & Download Defy SD-Recovery & Install..
1. Next place the Update.zip on the /sdcard via PC
2. Turn on MoTo Phone Portal ( SD-Recovery is SD Based so you need to Turn Off USB Mass Storage )
3. ADB Debugging does not have to be Turned Off on my version

Once Booted into the Recovery apply the update.zip
wait a few minutes & it should be done...

Please Reads the notes I left in the Update.zip if you build a Custom Update.zip, this will save you trouble down the road.

What's Flashed?
A. Boot.img
B. dev_tree
C. Moto Blur 3.4.2 Rom ( Yes I know it's not the latest, built off what I had )
D. UNO & TMO-TV Removed
E. Rooted ( SU & Superuser )
F. Busybox Installed to xbin
G. Rest of Rom is stock

Once installed, remove eugene.apk from /system/app ( Old boot strap that need adb turned off before rebooting / defy sd-recovery does not have this issue)

Q. I Edited the update.zip & Now it fails verf. in recovery when trying to flash!
A. example of signapk on signing the edited update
java -Xmx1024m -jar signapk.jar -w testkey.x509.pem testkey.pk8 update1.zip update.zip

Download: Original Post
 
Zuletzt bearbeitet:
Rallyharry

Rallyharry

Lexikon
Hat du schon eine möglichkeit und zeit gehabt das ganze zu testen?
Jan ehrlich gesagt keine ahnung von programmieren aber klingt mal echt interessant

Sent from my defy Android
 
Casius

Casius

Experte
Du hast damit die Möglichkeit, eine Update.zip als komplette Firmware
einzurichten. Dazu kannst du quasi via Script mit Vorlage, Kernel und andere
Zuweisungen bequem einstellen. Über das neue SD-Recovery(Market), das
sieht übrigens 1:1 wie das Cw. aus, kann man die Update.zip dann aufspielen.
Das macht RDS-Light unnötig. Meine Update.zip endete in einem Bootloop und
aus:(. Ich habe die Zip so signiert wie Eugen es vorgegeben hat. Die Update.zip
von Eugen klappt dagegen einwandfrei. Updates.zips mit den Motorecovery
einspielen, will bei mir zumindest „noch“ nicht gelingen. Aber das Prg. Ist ja
noch recht frisch und ich denke, dass da noch einiges(auch How Tos etc)
kommen wird.

Grüße:)

Casius
 
M

M1cha

Stammgast
Hallo,
ist "boot.img" der geschützte Bootloader oder ist damit etwas anderes gemeint?
Denn ich würde daran gerne etwas verändern, habe aber keine Lust mein DEFY (nicht-wiederherstellbar) zu bricken.

Gruß, M1cha
 
Sqoerk

Sqoerk

Erfahrenes Mitglied
Och warum glaubt ihr immer das alles neue euer Telefon zerstören würde? :lol:
Irgendwer muss es ja mal ausprobieren und immer nur die anderen ran lassen ist doch auch blöde:winki:

Es ist der originale Motorola Bootloader...alles andere würde nicht gehen...

Bin seit ner Stunde dran mir nen Update.zip zu basteln, und sollte jetzt soweit sein. Wenn alles gut geht flashe ich mir gleich das Pay 5.1 mit nen selbst erstellten update.

I'll be back :cool:

Edit: Bootloop... das Blöde M will nicht verschwinden :)
Edit 2: Wenn man CG47.smg als boot.img nutzt dann ist der Bootloader mit dem Motorola Recovery überschrieben... sehr cool, weil man beim normalen start immer dort rein kommt :thumbsup::lol:
 
Zuletzt bearbeitet:
Sqoerk

Sqoerk

Erfahrenes Mitglied
Casius schrieb:
Updates.zips mit den Motorecovery
einspielen, will bei mir zumindest „noch“ nicht gelingen.
Dieses wird auch nie gehen, da dafür die Keys von Motorola nötig sind. :angry: Schade eigentlich, ansonsten könnte man immer nen feines Backup auf der SD Karte halten.
 
Sqoerk

Sqoerk

Erfahrenes Mitglied
Der Bootloop entsteht NICHT durch einen fehlerhaften bootloader. Habe noch eine 3.4.3-11 fixed sbf hinterhergeschoben... ohne Erfolg. Also muss es irgendwas anderes im Script sein das fehlschlägt.

Falls jemand eine Idee hat wie ich mir /system anschauen kann bei einem Defy das im Bootloop hängt....bitte melden.
 
Casius

Casius

Experte
Sqoerk schrieb:
Dieses wird auch nie gehen, da dafür die Keys von Motorola nötig sind. :angry: Schade eigentlich, ansonsten könnte man immer nen feines Backup auf der SD Karte halten.
Hmm, Ich meine das so verstanden zu haben, dass das über eine Brücke
klappen soll. Eugen ist jemand der vieles zusammenbasteln kann.
Leider fehlt es einfach an ausreichender Dokumentation. Und 20x
mal Akku raus/rein, neee das muß nicht sein. Schade
das Moto für solche Fälle keinen Resetschalter an das Defy
gebaut hat.:winki:

Sqoerk schrieb:
Der Bootloop entsteht NICHT durch einen fehlerhaften bootloader. Habe noch eine 3.4.3-11 fixed sbf hinterhergeschoben... ohne Erfolg. Also muss es irgendwas anderes im Script sein das fehlschlägt.

Falls jemand eine Idee hat wie ich mir /system anschauen kann bei einem Defy das im Bootloop hängt....bitte melden.
Ich bin so vorgegangen, dass ich die System.img eines passenden Nandbackups
benutzt habe. Ich habe die update.zip von Eugen genommen, extrahiert und
einfach den Systemordner überschrieben. Neu gezippt und nach Vorgabe
signiert. Allerdings keine Chance.
Aber: Nandbackupdateien soll man anscheinend eh nicht nehmen.

Du scheinst ein Kapitel weiter zu sein. Hast du auch die Signierung
richtig durchgeführt? Weil, wenn nicht, blockiert Android wärend des
bootens alle geänderten oder hinzugekommenden Dateien!
Am Ende hängt er dann in der Bootschleife.

das mit dem, von Anfang an auf das System zu zugreifen, würde mit
einem Cynaogen Mod funktionieren. Es muss dafür allerdings der
Debugmodus oder auch ADBmodus von Anfang an aktiv sein!
Und das macht das Defy nicht.Entweder blockiert das der Bootloader
oder man kann das irgendwo einstellen. Es wäre zu schön per ADB
einfach das Handy neuzustarten und im Terminal log cat
einzugeben. Aber den Luxus haben wir leider nicht..:huh:

Grüße:)

Casius


Ps.: Bitte achte auf deine Doppelposts, nicht das
du irgendwann deswegen angesprochen wirst
.
 
Zuletzt bearbeitet:
Sqoerk

Sqoerk

Erfahrenes Mitglied
Ich habe folgendes gemacht (ähnlich wie du):

  • update von eugen als Basis genutzt
  • nandroid von der 3.4.3-11 genommen und system entpackt
  • Pays ROM genommen und die Daten mit denen vom nandroid zusammengeführt
  • /Daten von Pays ROM eingebaut
  • aus dem SBF von der 3.4.3-11 das boot.img und device_tree.bin extrahiert
  • die task.sh aus Pays ROM eingebaut
  • update-script von eugen angepasst damit auch alles zu den Daten von Pay passt (task.sh ausfüren, /daten kopieren, Rechte setzen...)
  • signierung durchgeführt laut eugens Anleitung... aber nicht mit eigenen Keys
bisher noch kein Erfolg :(

Ps.: Bitte achte auf deine Doppelposts, nicht das
du irgendwann deswegen angesprochen wirst
.
Jeps....teilweise ist das blöde ansonsten. Kaum einer liest ein "aktualisierten" post mitten im Thread....denk ich :)
 
Sqoerk

Sqoerk

Erfahrenes Mitglied
Sodele... eben mal nen paar Minuten gehabt:

Es scheinen symlinks zu fehlen. Diese werden durch das Script von eugene erstellt. Normalerweise sind die mit im sbf und nandroid drin ABER nach dem entpacken auf einem Windows PC sind die natürlich futsch. :thumbsup:

Also hat eugene nen Symlink-Erstellungs-Part in seinem Script. Dieses scheint wiederrum nicht "genug" symlinks zu erstellen. Werde heute abend mal eine neue Update.zip machen und probieren. :winki:
 
Casius

Casius

Experte
Sqoerk schrieb:
Sodele... eben mal nen paar Minuten gehabt:

Es scheinen symlinks zu fehlen. Diese werden durch das Script von eugene erstellt. Normalerweise sind die mit im sbf und nandroid drin ABER nach dem entpacken auf einem Windows PC sind die natürlich futsch. :thumbsup:

Also hat eugene nen Symlink-Erstellungs-Part in seinem Script. Dieses scheint wiederrum nicht "genug" symlinks zu erstellen. Werde heute abend mal eine neue Update.zip machen und probieren. :winki:
Jau, sag mal dann bescheid wie du voran gekommen bist!
Ich habe gerade keine Motivation oder Antrieb da
weiter zu experimentieren. Mal gucken wie lange das
andauert. :winki:

Ich friemel gerade etwas mit der Orange 2.2 herum. Mit der ich
derzeit sehr zufrieden bin!:)

Ja, wenn man mit Linux und Windows arbeitet, ist das der Fehler nr.1.
Sobald eine Linuxdatei auf eine Fa16 oder 32 Partition
kopiert wird, sind die Permissions und Attribute auf Standart
gesetzt und man wundert sich, warum denn jetzt wieder ein Fehler
auftritt.:blink:
 
Sqoerk

Sqoerk

Erfahrenes Mitglied
So gerade wieder nen update.zip gemacht, das nicht geht :thumbdn:

hier mal mein update-script, vlt. sieht ja jemand nen gravierenden Fehler. Ich lade auch gerne mal das ZIP-File hoch, wenn jemand interesse daran hat.

Freue mich auf euer Feedback :thumbsup:

Casius schrieb:
Ja, wenn man mit Linux und Windows arbeitet, ist das der Fehler nr.1.
Sobald eine Linuxdatei auf eine Fa16 oder 32 Partition
kopiert wird, sind die Permissions und Attribute auf Standart
gesetzt und man wundert sich, warum denn jetzt wieder ein Fehler
auftritt.:blink:
Ich mag kein Linux auf'n Desktop PC... auf'm Server reicht mir das :)

Edit: update-script entfernt, da ich ein neues hochgeladen habe
 
Zuletzt bearbeitet:
Casius

Casius

Experte
Sqoerk schrieb:
So gerade wieder nen update.zip gemacht, das nicht geht :thumbdn:

hier mal mein update-script, vlt. sieht ja jemand nen gravierenden Fehler. Ich lade auch gerne mal das ZIP-File hoch, wenn jemand interesse daran hat.

Freue mich auf euer Feedback :thumbsup:



Ich mag kein Linux auf'n Desktop PC... auf'm Server reicht mir das :)
Sag mal, das Script hast du schon als utf-8 abgespeichert?
Ansonsten wird das Script falsch eingelesen. Ich hatte mal so ein Problem,
dass ich ein Script auf utf-8 abgespeichert habe, aber es nicht als solches
erkannt wurde. Konvertieren mit den unterschiedlichsten Editoren brachte
keinen Erfolg. Zum schluss habe ich die Datei mit den Rootexp.Editor
eingelesen und gespeichert und siehe da,, ging..
Vielleicht hast du das nicht beachtet, deswegen sag ichs mal sol.:winki:
 
Sqoerk

Sqoerk

Erfahrenes Mitglied
öhm...nö....war ansi...
na dann neuer versuch :) :D

Edit: gerade ma gecheckt...alle Dateien sind im ansi Format...auch die von eugene...also wird es nicht das problem sein :(
 
Zuletzt bearbeitet:
Casius

Casius

Experte
Sqoerk schrieb:
öhm...nö....war ansi...
na dann neuer versuch :) :D
Dann konnte es ja nicht funktionieren.
Also auf zum nächsten Problem:D
 
Sqoerk

Sqoerk

Erfahrenes Mitglied
mit utf-8 codierung lüppet gar nicht :sneaky::winki: Wird sofort nen Fehler in der ZIP-Datei gemeldet

Edit: Sodele...schonmal einen grooooße schritt weiter: zip wurde erfolgreich eingespielt UND ich konnte durchbooten...leider läuft das System total instabiel und ich scheine nichts installieren zu können. Da werde ich wohl nochmals die Permissions überprüfen müssen...

Morgen geht es dann weiter :)

Naja...morgen geht es zwar erst weiter...aber vorher muss das telefon wieder rennen... bäh ... scho wieder flashen :(
 
Zuletzt bearbeitet:
Casius

Casius

Experte
Übrigens, im Recovery gibts die Option Fix Permissions. Für die Fälle,
wenn es schnell gehen soll und du ins Recovery rein kommst.:winki:

Wenn du die ganze updatezip extrahierst und wieder neu packst,
gehen alle perms flöten. Am besten ist es, dass in einer Linux VM
zu machen. Oder du nimmst eine dieser Linux Bootdvds.
Vorausgessetzt ist dann allerdings immer noch ein linux Filesystem.
Aber dafür könnte dann ein USB Stick herhalten......

Sqoerk schrieb:
Das wollt ich machen, aber leider konnte ich werde das Recovery App starten, noch es installieren ohne das es nen Reboot gegeben hat :thumbdn:
nicht gut.. ;(
Dann Linuxbootdvd. Ich kann dir Debian oder Ubuntu als Distrb. empfehlen.
 
Zuletzt bearbeitet:
Sqoerk

Sqoerk

Erfahrenes Mitglied
Casius schrieb:
Übrigens, im Recovery gibts die Option Fix Permissions. Für die Fälle,
wenn es schnell gehen soll und du ins Recovery rein kommst.:winki:
Das wollt ich machen, aber leider konnte ich werde das Recovery App starten, noch es installieren ohne das es nen Reboot gegeben hat :thumbdn:
 
Sqoerk

Sqoerk

Erfahrenes Mitglied
Casius schrieb:
Wenn du die ganze updatezip extrahierst und wieder neu packst, gehen alle perms flöten. Am besten ist es, dass in einer Linux VM
zu machen. Oder du nimmst eine dieser Linux Bootdvds.
Vorausgessetzt ist dann allerdings immer noch ein linux Filesystem.
Aber dafür könnte dann ein USB Stick herhalten......
Die Permissions möchte ich ja gar nicht in der update.zip haben. Dafür ist ja das Update-Script zuständig. Dort gibt es ja folgenden Teil:

Code:
# START: permissions 
ui_print("Setting permissions on system");
set_perm_recursive(0, 0, 0755, 0644, "/system");
set_perm_recursive(0, 2000, 0755, 0755, "/system/bin");
set_perm(0, 1000, 06110, "/system/bin/encryption_test");
set_perm(0, 3003, 02750, "/system/bin/netcfg");
set_perm(0, 3004, 02755, "/system/bin/ping");
set_perm(0, 2000, 06750, "/system/bin/run-as");
set_perm_recursive(1002, 1002, 0755, 0440, "/system/etc/bluetooth");
set_perm(0, 0, 0755, "/system/etc/bluetooth");
set_perm(1000, 1000, 0640, "/system/etc/bluetooth/auto_pairing.conf");
set_perm(3002, 3002, 0444, "/system/etc/bluetooth/blacklist.conf");
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");
set_perm(0, 0, 04755, "/system/xbin/su");
ui_print("Setting permissions on data");
set_perm(1000, 1000, 0771, "/data");
# END: permissions
Den Teil für data muss ich mir nochmals genauer angucken

Übrigens um das ganze etwas zu entspannen beim ausprobieren muss du folgendes machen:

  • Handy an Rechner anschließen
  • in Recoverymodus neustarten
  • adb shell ausprobieren -> wenn es geht dann weiter
  • backup erstellen
  • zip-Datei einspielen
  • über adb-shell checken ob alles "gut aussieht"
  • wenn nicht: backup zurückspielen
  • handy neu starten... und alles ist normal :thumbsup:
Was ich dabei herausgefunden habe war, das "motobox" und "toolbox" unter /system/bin durch nen symlink überschrieben wurde.

daher habe ich die Datein nochmals in die zip gepackt, in nen Ordner Namens patchfiles. Die Struktur in dem Ordner ist die gleiche wie unter /system, nur das halt nur die Dateien drin sind die überschrieben wurden. Nach dem symlinks erstellen wird dann folgendes ausgeführt:

Code:
# START: patch overwritten files 
ui_print("Patching overwritten files");
package_extract_dir("patchfiles", "/system");
# END: patch overwritten files
So im Anhang nochmals ein neues Gesamtscript. Vlt. kann mir ja jemand das "symlink-Problem" erklären....und vlt. sieht ja jemand direkt das "permission-Problem" bei data....obwohl ich schon die Vermutung habe, das dort recursiv gearbeitet werden muss :biggrin:

Edit: Veralteten Anhang gelöscht
 
Zuletzt bearbeitet:
Casius

Casius

Experte
Sqoerk schrieb:
Die Permissions möchte ich ja gar nicht in der update.zip haben. Dafür ist ja das Update-Script zuständig. Dort gibt es ja folgenden Teil:


Code:
# START: patch overwritten files 
ui_print("Patching overwritten files");
package_extract_dir("patchfiles", "/system");
# END: patch overwritten files
So im Anhang nochmals ein neues Gesamtscript. Vlt. kann mir ja jemand das "symlink-Problem" erklären....und vlt. sieht ja jemand direkt das "permission-Problem" bei data....obwohl ich schon die Vermutung habe, das dort recursiv gearbeitet werden muss :biggrin:
Aloha!
Und was macht die Kunst?:winki:
mit der Update.zip hast du recht. Die Symlinks sind eigentlich
nur Verknüpfungen, die sich als Datei ausgeben und zu einem anderen
Zielort führen. Das kenn ich schon seit Gaosp vom I7500.
Sämtliche BINs hatten einen Symlink auf die Busybox.
Wenn da ein Fehler drin ist,, kann es das schon gewesen sein..:blink:
Alle Attribute werden über das Script eingerichtet, das stimmt,
von daher brauch man da nicht so stark beim Zip Be- und Endladen
aufpassen. Wo hatte ich nur mein Kopf?:D

Also wenn ich dich jetzt richtig verstehe, gehst du wie folgt vor:
1 Update.zip extrahieren
2 systemordner aktualisieren
(mit dem eigenen Sytem überschreiben.)
3 boot.img tauschen.
4 komprimieren als update.zip
5 Signieren:
Q. I Edited the update.zip & Now it fails verf. in recovery
when trying to flash! A. example of signapk on signing the
edited update

java -Xmx1024m -jar signapk.jar -w testkey.x509.pem
testkey.pk8 update1.zip update.zip


Deswegen meine ich, dass die Update.zip über das Motorecovery
funktionieren könnte. Eine Signierung für das Clockwork Recovery
ist ja nicht unbedingt notwendig
, da man den signing check ja dort
deaktivieren kann, wenn er das nicht schon standardmässig ist.:blink:

zum Script:
Normal müsstest du doch eigentlich nichts am Script selbst ändern.
Das gleiche Script funktioniert ja auch mit Eugens Update.zip einwandfrei.
Erst mit den Tausch der Dateien treten die Probleme auf. Daher fehlt
irgendwo was... nur was?:huh:

Grüße:)
 
Zuletzt bearbeitet: