Den Gedanken, meine Daten aufzugeben, obwohl sie direkt vor meiner Nase liegen, empfand ich als ärgerlich, daher habe ich mich einige Tage mit dem Problem auseinandergesetzt und eine Lösung gefunden. Vorab sei aufgezählt, was ich erfolglos versucht habe:
•
Ein Firmware-Image zu finden, dass trotz der noch vorhandenen Benutzerdaten startet. Danach kann man wie gesagt ein Recovery-System installieren oder das Smartphone
rooten und noch ganz andere Sachen anstellen. Doch alle getesteten Images, auch die,
mit denen es bei anderen funktioniert haben soll hingen in einer Boot-Loop fest, meldeten einen Fehler "A5,69,35,00,21" oder ließen den Bildschirm schwarz und starteten gar nicht.
(Ein schwarzer Bildschirm bedeutet übrigens nicht, dass das Smartphone kaputt ist. Der Bootloader ist mit irgendwelchen Versionsnummern nicht einverstanden, aber er startet. Ein einfacher Druck auf die Power-Taste kann genügen und das Smartphone erscheint wieder als USB-Gerät und lässt sich flashen.)
•
Die Firmware-Images in unterschiedlichen Reihenfolgen zu flashen. Totaler Quatsch.
•
Ein Firmware-Image zu finden, das ein besseres oder gleich nur ein Recovery-System enthält. So etwas gibt es zumindest für das
Motorola Defy+ nicht.
•
Die Stock-Recovery-Funktionen zu nutzen, um ein anderes Recovery-System zu installieren. Zwecklos, da die Recovery-Systeme nicht als signierte Firmware-Files vorliegen.
•
Den Cache zu löschen. Das reicht nicht. Und der
Dalvik-Cache liegt dummerweise im selben Speicherbereich wie die Benutzerdaten und lässt sich mit den Stock-Recovery-Funktionen nicht löschen.
(Wie sich später gezeigt hat, genügt es ebenfalls nicht, den Dalvik-Cache zu löschen.)
•
Per Android Debug Bridge (ADB) auf das Gerät zuzugreifen. ADB war entweder deaktiviert oder wurde in der Boot-Schleife nicht gestartet.
•
Den Flash-Speicher des Telefons über USB auszulesen. Die wenigsten Telefone geben ihre Daten auf diese Weise her.
(Ob das Defy+ JTAG-Kontakte hat, ist bislang unbekannt.)
Irgendwann war dann auch der Akku leer, so dass ein "McGyver"-Kabel hermusste: Ein USB-Kabel mit offenem Ende, das als Spannungsversorgung mit dem Akku an die Kontakte geklemmt wird. Das lädt nebenbei auch den Akku auf. Beim Herumfummeln muss man nicht nur wegen Kurzschlüssen und Verpolung aufpassen. Es sollten auch keine abgebrochenen Litzedrähtchen in das Telefon fallen!
Als einzige Idee blieb, eine Original-Firmware so anzupassen, dass sie entweder den Inhalt des Benutzerdatenbereichs ignoriert und startet oder noch vor dem Fehler, der zum ewigen Neustart führt, ein Recovery-System installiert, per ADB Zugang zu den Benutzerdaten verschafft oder diese gleich auf eine Speicherkarte kopiert. Und siehe da:
Wie man bei xda-developers nachlesen kann, ist das möglich, denn man kann eine Firmware in ihre Bestandteile zu zerlegen und partiell neu flashen. Folglich ist es möglich, eigenen Code einzuschleusen.
WIN!
Howto: Daten vom Android-Smartphone retten
Bootloader-Modus
Zunächst versetzt man das Telefon in den Bootloader-Modus, in dem es bereit ist, eine neue Firmware zu empfangen. Das erreicht man beim Defy+, in dem man den Akku herausnimmt, und dann die Power- und die Volume-Up-Taste einige Sekunden gedrückt hält, während man den Akku wieder einlegt.
(gerootete) Stock-Firmware flashen
Nun kann man eine geeignete Firmware übertragen. Das geht unter Windows mit der Motorola-Software
"RSD Lite", unter Linux mit dem Tool
sbf_flash von
[mbm], das es leider nur als Binary und nicht im Sourcecode gibt.
Ich habe mich für die beiden
hier genannten Firmware-Images mit den Namen
DEFYPLUS_U3_4.5.1-134_DFP-231_GR_SIGN_UCADEFYEMARAB1B80AA004.
0R_PDS03C_USAJRDNGIBRRTCEE_P022_A022_Service1FF.sbf und
DEFYPLUS_U3_4.5.1-134_DFP-231_CEE_ROOTED_No_Signed.sbf entschieden, weil mit ihnen angeblich ein Start ohne Wipe möglich ist. Beachten sollte man allerdings, dass diese aufgrund irgendeiner Versionsnummer ein späteres Downgrade schwierig oder sogar unmöglich machen.
Prinzipiell ist es egal, welche Firmware man nutzt, wichtig ist nur, dass es sich um ein
Service-SBF handelt, denn diese Images lassen den Datenbereich unangetastet.
Ich habe den Images kürzere Namen gegeben, nämlich
a.sbf und
b.sbf. Mit
sbf_flash a.sbf schreibt man das Image
a.sbf auf das Smartphone. Hier die Ausgabe von
sbf_flash:
SBF FLASH 1.24 (mbm)
http://opticaldelusion.org
=== a.sbf ===
Index[1]: Unexpected chip 32
Index[2]: Unexpected chip 32
Index[3]: Unexpected chip 32
Index[4]: Unexpected chip 32
Index[5]: Unexpected chip 32
Index[6]: Unexpected chip 32
Index[7]: Unexpected chip 32
Index[8]: Unexpected chip 32
Index[9]: Unexpected chip 32
Index[10]: Unexpected chip 32
Index[11]: Unexpected chip 32
Index[12]: Unexpected chip 32
00: RDL03 0x82000000-0x8204CFFF DA14 AP
01: CG31 0xB0280000-0xB02847FF 5E8F AP
02: CG32 0xC7A00000-0xC7A207FF 4805 AP
03: CG33 0xB2000000-0xB2DC07FF FC1B AP
04: CG34 0xB0700000-0xB07047FF AB80 AP
05: CG35 0xB1000000-0xB17FFFFF 918E AP
06: CG39 0xB3300000-0xC79C07FF 4FF9 AP
07: CG42 0xB0800000-0xB0842FFF 4BB7 AP
08: CG45 0xB0C00000-0xB0F007FF B600 AP
09: CG47 0xB1800000-0xB1FFFFFF 0331 AP
10: CG61 0xB0B00000-0xB0B7FFFF 6A85 AP
11: CG64 0xB0000000-0xB00047FF 85D0 AP
12: CG65 0xB0180000-0xB01847FF 2409 AP
>> waiting for phone: Connected.
>> uploading RDL03: 100.0%
-- OK
>> verifying ramloader
-- OK
>> executing ramloader
-- OK
>> waiting for phone: Connected.
>> sending erase
-- OK
>> uploading CG31: 100.0%
-- OK
>> uploading CG32: 100.0%
-- OK
>> uploading CG33: 100.0%T
-- OK
>> uploading CG34: 100.0%
-- OK
>> uploading CG35: 100.0%
-- OK
>> uploading CG39: 100.0%
-- OK
>> uploading CG42: 100.0%
-- OK
>> uploading CG45: 100.0%
-- OK
>> uploading CG47: 100.0%
-- OK
>> uploading CG61: 100.0%
-- OK
>> uploading CG64: 100.0%
-- OK
>> uploading CG65: 100.0%
-- OK
>> verifying CG31
-- OK
>> verifying CG32
-- OK
>> verifying CG33
-- OK
>> verifying CG34
-- OK
>> verifying CG35
-- OK
>> verifying CG39
-- OK
>> verifying CG42
-- OK
>> verifying CG45
-- OK
>> verifying CG47
-- OK
>> verifying CG61
-- OK
>> verifying CG64
-- OK
>> verifying CG65
-- OK
>> rebooting
Wenn man Glück hat, bootet das System nun. Wenn man wie ich eine Boot-Loop bemerkt, zu Erkennen an der kurzen Unterbrechung und dem Neustart der Animation des Motorola-Logos, nimmt man den Akku raus und wiederholt das ganze direkt mit dem zweiten SBF. Also Bootloader starten, dann
sbf_flash b.sbf durchlaufen lassen.
Da sich diese Firmware nur minimal von der ersten unterscheiden dürfte, wird auch sie wahrscheinlich in einer Bootschleife festhängen. Also einfach nach einer Weile den Akku rausnehmen.
optional: Layout des Flash-Speichers ansehen
Ein SBF-File enthält mehrere Images für die verschiedenen Speicherbereiche im Flash des Smartphones. Welche das sind kann man sich mit
sbf_flash -r anzeigen lassen, wenn das Telefon im Bootloader-Modus angeschlossen ist:
CG64 0xB0000000-0xB001FFFF mbr
CG63 0xB0020000-0xB003FFFF mbmloader
CG30 0xB0080000-0xB00FFFFF mbm
CG55 0xB0100000-0xB017FFFF mbmbackup
CG65 0xB0180000-0xB01FFFFF ebr
CG56 0xB0200000-0xB027FFFF bploader
CG31 0xB0280000-0xB02FFFFF cdt.bin
CG38 0xB0300000-0xB06FFFFF pds
CG34 0xB0700000-0xB077FFFF lbl
CG57 0xB0780000-0xB07FFFFF lbl_backup
CG42 0xB0800000-0xB08FFFFF logo.bin
CG41 0xB0900000-0xB0AFFFFF sp
CG61 0xB0B00000-0xB0B7FFFF devtree
CG62 0xB0B80000-0xB0BFFFFF devtree_backup
CG45 0xB0C00000-0xB0FFFFFF bpsw
CG35 0xB1000000-0xB17FFFFF boot
CG47 0xB1800000-0xB1FFFFFF recovery
CG33 0xB2000000-0xB2DFFFFF cdrom
CG44 0xB2E00000-0xB2E7FFFF misc
CG43 0xB2E80000-0xB2EFFFFF cid
CG53 0xB2F00000-0xB32FFFFF kpanic
CG39 0xB3300000-0xC79FFFFF system
CG32 0xC7A00000-0xC7A7FFFF prek
CG46 0xC7A80000-0xC7AFFFFF pkbackup
CG40 0xC7B00000-0xD42FFFFF cache
CG37 0xD4300000-0xEFFFFFFF userdata
Laut [mbm] werden manche Speicherbereiche
bei jedem Start auf Integrität geprüft, manche nicht. Relativ sicher passiert das auf dem Defy+ leider ausgerechnet beim
boot- und beim
recovery-Bereich. Der
system-Bereich wird jedoch nur einmal geprüft. Ändert sich seine Checksumme nicht, erfolgt keine erneute Prüfung. Ein Dateisystem dieser Größe zu prüfen, würde ohnehin viel zu lange dauern. Außerdem könnte es inzwischen ja auch vom System gewollt modifiziert worden sein. Das Smartphone bemerkt es aber auch nicht, wenn Der
system-Bereich neu geflasht wurde — solange dieser noch dieselbe Checksumme hat.
(Ich vermute, dass das Rooten des Telefons nach genau diesem Prinzip funktioniert. Das erste Image sorgt für eine erfolgreiche Checksummenprüfung. Das zweite Image schleust dann ein, was nötig ist, um Root-Zugriff zubekommen. Zur Datenrettung genügt es wahrscheinlich, nur das erste der beiden genannten SBFs zu flashen, aber das habe ich nicht getestet.)
Firmware auspacken
Mit
sbf_flash lassen sich Firmware-Files in ihre Bestandteile zerlegen:
sbf_flash -x b.sbf. Im Ordner
b-extracted liegen danach Images mit der Endung
.smg und Dateinamen, an denen man erkennen kann, in welche Speicherbereiche sie beim Flashen geschrieben werden:
CG31.smg CG32.smg CG33.smg CG34.smg CG35.smg CG39.smg CG42.smg CG45.smg CG47.smg CG61.smg CG64.smg CG65.smg firmware.hmg RAMDLD.smg
Einige dieser Images enthalten Dateisysteme.
(Laut diesem Forenbeitrag kann man übrigens auch die meisten davon wegwerfen, die verbleibenden ersetzen oder modifizieren und sich so ein eigenes, kleineres SBF zum "drüberflashen" erstellen.)
Systembereich loop-mounten und modifizieren
Nun kann man den Systembereich loop-mounten:
mount -o loop b-extracted/CG39.smg /mnt/
Das Dateisystem sollte ext3 sein. Falls nicht würde ich mal ext4, yaffs2 und squashfs versuchen.
Im Systembereich legt man im Verzeichnis
etc ein Script namens
install-recovery.sh an, das man mit
chmod a+x install-recovery.sh ausführbar macht. Es wird beim Start ausgeführt, und zwar noch bevor das System wegen der verbliebenen Daten neustarten kann.
(Warum das so ist kann man sehen, wenn man sich die init.rc im boot-Bereich CG35.smg ansieht. Da CG35.smg kein Dateisystem ist, sondern den Kernel und eine Ramdisk enthält, benötigt man ein Tool, um den Inhalt der Ramdisk auszupacken, zum Beispiel das selbsterklärende Android Kernel Kitchen.)
Mein Recovery-Script sieht so aus:
#!/system/bin/sh
# rescue-script for android-phones without working rom and no recovery-system except stock.
# put this in etc/install-recovery.sh in your CG39.smg.
# red light to signal the script is in fact running
echo 255 > /sys/class/leds/red/brightness
# let's turn of the animated M
setprop debug.sf.nobootanimation 1
# this is supposed to tell usbd what usb mode to use. doesn't work.
#setprop persist.usb.android_config=mtp,adb
# start usbd. this should make adbd work. it doesn't.
#start usbd
# start the daemon for android debug bridge. doesn't work.
#setprop persist.service.adb.enable 1
#start adbd
# wait two seconds
sleep 2
# vold is supposed to mount the sd automagically. doesn't work.
#start vold
# empty the dalvik-cache. didn't prevent boot loops on my phone. not sure if rm -rf works with motobox.
#rm /data/dalvik-cache/*.dex
# green light - uncomment if you do more complicated/time-consuming things above
#echo 0 > /sys/class/leds/red/brightness
#echo 255 > /sys/class/leds/green/brightness
# make sure the mountpoint exists
mkdir /mnt/sdcard
# try to mount the sd card.
# the sd card's partition is either /dev/block/mmcblk0p1 or /dev/block/mmcblk1p1, depending on your phone model.
#mount /mnt/sdcard
#mount -t auto /dev/block/mmcblk1p1 /mnt/sdcard
#mount -t vfat /dev/block/mmcblk1p1 /mnt/sdcard
#mount -t auto /dev/block/mmcblk0p1 /mnt/sdcard
mount -t vfat /dev/block/mmcblk0p1 /mnt/sdcard
# a 3 second flash will indicate a failure. probably the wrong partition.
if [ $? -ne 0 ]; then
#flash red
while [ 1 ]
do
echo 0 > /sys/class/leds/red/brightness
sleep 1
echo 255 > /sys/class/leds/red/brightness
sleep 1
done
fi
# violet light
echo 0 > /sys/class/leds/green/brightness
echo 255 > /sys/class/leds/red/brightness
echo 255 > /sys/class/leds/blue/brightness
# list the contents of /dev and /data. the latter can be helpful to figure out which folders should be copied in the next step.
#/system/ls -liahR /dev > /mnt/sdcard/dev.txt
#/system/ls -liahR /data > /mnt/sdcard/data.txt
# create a backup folder
mkdir /mnt/sdcard/0databackup
# try to copy everything that makes sense from userdata to a backup-folder on the sd card.
# cp -a didn't work with motobox, -v neither with motobox nor busybox.
/system/cp /data/* /mnt/sdcard/0databackup
# adjust this to your folder structure.
/system/cp -a /data/opprof /mnt/sdcard/0databackup
/system/cp -a /data/data /mnt/sdcard/0databackup
/system/cp -a /data/app /mnt/sdcard/0databackup
/system/cp -a /data/bp_nvm /mnt/sdcard/0databackup
/system/cp -a /data/comm_drv /mnt/sdcard/0databackup
/system/cp -a /data/system /mnt/sdcard/0databackup
/system/cp -a /data/app-private /mnt/sdcard/0databackup
/system/cp -a /data/misc /mnt/sdcard/0databackup
/system/cp -a /data/drm /mnt/sdcard/0databackup
/system/cp -a /data/property /mnt/sdcard/0databackup
# white light to signal the copy operations have finished.
echo 255 > /sys/class/leds/red/brightness
echo 255 > /sys/class/leds/blue/brightness
echo 255 > /sys/class/leds/green/brightness
Die vielen auskommentierten Zeilen sind Ergebnis verschiedener Experimente. Ich lasse sie bewusst stehen. Mit Unterstützung von [mbm] habe ich versucht, durch Setzen von Konfigurationseinstellungen und Starten der richtigen Services eine ADB-Verbindung zum Telefon herzustellen. Doch die Versuche schlugen fehl, das Telefon tauchte während des Bootvorgangs einfach nicht als USB-Gerät auf.
Man kann problemlos
cp und
ls des Systems verwenden, beide sind Links auf das
motobox-Binary, aber mir waren sie wegen fehlender Optionen nicht gut genug. Daher habe ich noch ein zufällig herumliegendes BusyBox-Binary für Android (zum Beispiel aus der fastboot.zip) in den Systembereich kopiert und Symlinks mit den Namen der beiden Werkzeuge darauf angelegt. Wer das nicht will, muss im Script den Pfad bei den Aufrufen von
cp und
ls entfernen.
Systembereich flashen
Nun hängt man das Image mit
umount /mnt wieder aus und flasht es mit
sbf_flash -r --system b-extracted/CG39.smg b.sbf.
sbf_flash ignoriert dabei die anderen Teile der Firmware und schreib nur den
system-Bereich neu.
CG39 system -> b-extracted/CG39.smg
=== b.sbf ===
Index[1]: Unexpected chip 32
(...)
Index[12]: Unexpected chip 32
00: RDL03 0x82000000-0x8204CFFF DA14 AP
(...)
12: CG65 0xB0180000-0xB01847FF 2409 AP
Skipping CG31 0xB0280000-0xB02FFFFF
(...)
Skipping CG65 0xB0180000-0xB01FFFFF
>> Adding CG39 0xB3300000-0xC79FFFFF
>> waiting for phone: Connected.
>> uploading RDL03: 100.0%
-- OK
>> verifying ramloader
-- OK
>> executing ramloader
-- OK
>> waiting for phone: Connected.
>> sending erase
-- OK
>> uploading CG39: 100.0%
>> rebooting
Das Smartphone startet neu und führt das Script aus, was man daran sieht, dass die LED für zwei Sekunden rot aufleuchtet. Außer der LED gibt es vor dem Mounten der SD-Karte keine Möglichkeit, den Zustand des Scripts zu signalisieren oder ein Log-File zu schreiben, an das man hinterher auch herankommt. Ein
rotes Dauerblinken zeigt an, dass das Mounten fehlgeschlagen ist. Das Script muss dann angepasst und der Systembereich neu geflasht werden. Ist die SD-Karte gemountet, kopiert das Script die Benutzerdaten aus ausgewählten Verzeichnissen auf die SD-Karte. Während des Kopiervorgangs, der durchaus sehr langwierig sein kann, leuchtet die LED
violett, am Ende
weiß.
Nun sind die Daten gerettet und man kann das Smartphone gefahrlos wipen und neu aufsetzen.
weitere Links zum Thema
•
Recover deleted content from userdata partition? — Was man tun kann, wenn man per ADB Zugang zum Flash-Speicher hat.
•
Vulnerable recovery for Motorola Milestone - root any known firmware version — Offenbar eine Möglichkeit, nur den Recovery-Bereich zu flashen. Das wäre noch einfacher, geht aber wahrscheinlich nicht beim Defy+.
•
Motorola Defy+ (MB526) auf Android 4.1.2 “Jelly Bean” flashen
•
Motorola Defy+ Blog
•
How to Recover from a bootloop
