Problem beim Rooten mit MTK Droidtool...

[rzdz]

1. Rooten per OCR

OK, ist durchgelaufen:



Nach Neustert des Handys:



(EDIT: hatte vergessen SuperSU vorher zu deinstallieren, daher jetzt den Beitrag etwas bereinigt)

 

[videojo]

versuche es mal mit diesem tool
Super-Sume – Android-Apps auf Google Play

 

[rzdz]

Dieses Tool ist für Kingroot, ich habe Kingoroot verwendet...

--------------------------------------------------------------------------------------------------------------------------------------

Ich habe jetzt SuperSU ganz normal deinstalliert und einen Werksreset mit Neustart gemacht.
SuperSU ist weg, die KingoRoot App auch (k.A. was die überhaupt tut).

KingoUser ist noch da, meckert nach wie vor wegen Update...

Habe Kingoroot vom PC nochmals neu rooten lassen. Jetzt ohne Gemecker.
Der KingoUser fehlte noch auf der App-Seite, nach Neustart des Handys ist er aber wieder da.

Beim Neustart des Handys sowie beim Start des KingoUsers kommt kurz eine kleine Einblendung "Download failed", möglicherweise ein Auto-Update des KingoUsers (?), was wegen fehlender SIM und deaktiviertem WLAN ins Leere läuft.
Die installierte Version wird mit 1.7 angezeigt, meckert auch sonst nicht mehr.

MTK Droidtools zeigt das Handy unten in der Statusleiste gelb an, also schon mal "teilgerootet".

RootCheckerBasic (v.5.0.5) zeigte das hier: Sorry, this device does not have proper root access.
RootCheckerBasic (v.5.5.1) allerdings: Congratulations! Root access is properly installed...

--------------------------------------------------------------------------------------------------------------------------------------

Schritt 2: Custom recovery per ADB Befehl aufspielen

Habe im ADB-Fenster von MTK Droidtools Folgendes eingegeben:

adb shell dd if=/sdcard/recovery_patched.img of=/dev/recovery

Antwort:
/dev/recovery: cannot open for write: Permission denied

So hat es aber funktioniert:

D:\...\MtkDroidTools>adb shell
shell@YARISXL:/ $ su
su
root@YARISXL:/ # dd if=/sdcard/recovery_patched.img of=/dev/recovery
dd if=/sdcard/recovery_patched.img of=/dev/recovery
10920+0 records in
10920+0 records out
5591040 bytes transferred in 0.454 secs (12315066 bytes/sec)
root@YARISXL:/ #

Wobei recovery_patched.img der Dateiname der CWM-Recovery in der Root der SD-Karte ist.

Neustart in Recovery zeigt ClockWorkMod v.5.5.0.4 for Alcatel One Touch an.!

Jippie!

--------------------------------------------------------------------------------------------------------------------------------------

Schritt 3: Sicherung

Ist dieses CWM-Backup vollständig?



Es sind zusammen nur ca. 650MB... (?)

 

[N2k1]

Gratulation!
Nun ein Backup!
Danach machen wir alles platt ;-)

 

[rzdz]

Backup siehe oben...

 

[N2k1]

Nein, ich meine eines per CWM.

 

[rzdz]

Das ist doch der Ordner auf der SD-Karte im Handy (über USB am PC), den CWM erstellt hat:



Schau auf den Pfad, dann siehst Du es (das Datum stimmt nicht, wegen Werksreset).

 

[N2k1]

Ups, dann hatte ich das übersehen..
Na dann nun einfach "formal except preloader"
Danach Scatter bearbeiten und bei NVRAM aus is_download: false einfach is_download: true machen.

 

[rzdz]

Kann das CWM-Backup denn mit 650MB vollständig sein (im Flashtool waren es ca. 3,6GB)?

Im SPFlashtool dann alles formatieren außer Preloader?
Macht mir Bauchschmerz, weil da in der Scatterdatei doch immer noch falsche Type drinsteht...

 

[N2k1]

Wieso steht in der Scatter was falsches drin?
Wenn in dem Fenster Ext4 steht, steht es auch in der Scatte.
Ich denke, da hast Du welche gemischt.
Mach sei einfach nochmal.
Das neue Backup wird ohne Custpack und vor allem ohne (interne) SD-Karte sein

 

[rzdz]

Ich habe nichts gemischt. Mehrfach die Programmordner kopiert oder neu entpackt, alles was neues Datum hatte gelöscht, Scatterdatei neu erstellen lassen, "Backups"-Ordner neu erstellen lassen.
Ergebnis: die Scatterdateien waren alle binär identisch.
Die Backups-Ordner waren nicht ganz identisch (u.a. weil die ROM-Dateien aus denen sie erzeugt wurden, wegen unterscheidlicher Endadressen unterschiedlich groß waren, siehe anderer Thread, und weil bei den gepatchten Dateien binäre Unterschiede bestanden, wie z.B. im CWM das Erstellungsdatum).

Gestern habe ich nochmal von Null mit dem Backup begonnen, und trotzdem immer "falsche" Scatterdateien erhalten, siehe Deine Anmerkung:

Stop!
Da ist etwas faul
type: YAFFS_IMG
Das sollte ext4 sein!

Wieso steht in der Scatter was falsches drin?
Wenn in dem Fenster Ext4 steht, steht es auch in der Scatte.

Wieso wüßte ich auch gerne, aber es ist hier definitiv der Fall!

Kann man eine Scatterdatei nicht von Hand erzeugen? Oder mit einem anderen Tool?

Oder einfach alle (notwendigen) Partitionen so per ADB überflashen, wie ich es mit der Custom Recovery oben getan habe?
Genügt nicht die von MTKDroidtools gepatchte Boot-Partition und evtl. das, was KingoRoot alles versaut haben könnte?

Ora könnte vielleicht nochmal etwas dazu sagen...?

 

[rzdz]

Zur Größe des Backups: Data und System sind bei CWM komprimiert.
Die 3,6GB meines MTKDroidtool-Backups lassen sich auf ca. 870MB zippen, die Frage ist also, was ist in dem CWM-Backup nicht enthalten...

 

[N2k1]

Nicht enthalten wird Custpack2 sein (denke ich), da die recovery.fstab nicht darauf gerichtet ist.

Nachdem Dein Gerät gerootet ist, stoße das Backup doch einfach im MTK DT an, dann hast Du alles komplett.
Das dann nur nooch für das SPFT aufbereiten lassen (vom MTK DT).

 

[rzdz]

Nicht enthalten wird Custpack2 sein (denke ich), da die recovery.fstab nicht darauf gerichtet ist.

Nachdem Dein Gerät gerootet ist, stoße das Backup doch einfach im MTK DT an, dann hast Du alles komplett.
Das dann nur nooch für das SPFT aufbereiten lassen (vom MTK DT).

Der Backup-Button ist in MTK DT inaktiv. Der Rootbutton läßt sich drücken, führt aber zu 2 Fehlermeldungen (je nachdem, ob man "bestehende SU erhalten?" mit ja oder nein beantwortet):



Habe hier einen Hinweis gefunden, daß bei Alcatel scheinbar die Partitionen anders sind:

ALSO, MAKE SURE YOUR DON'T TRY THAT ON AN ALCATEL (OR SIMILAR) DEVICE, INDICATOR HERE IS A CUSTPACK PARTITION IN SCATTERFILE. those devices have mt65xx, but have a totally different partition strukture. You can try this tutorial, BUT IF YOU BRICK YOUR DEVICE; I CANNOT HELP YOU OUT!!!

 

[N2k1]

Backup geht nur, wenn Du Root-Zugriff (grünes Quadrat) hast.
Dazu entweder den Root-Knopf drücken - oder alternativ Chainfires adb insecure von XDA installieren.. [2014.11.10][ROOT] adbd Insecure v2.00 | Android Development and Hacking | XDA Forums
Du könntest auch - wie mit dem Recovery das gepatchte Boot-Image einspielen.

Daß wir ein alternatives Partitions-Layout haben, wissen wir doch.
Das stammt übrigens von ClockWorkMod (CWM / CM)
Das MTK DT nimmt die dumchar oder eMMC und erstellt daraus das Scatter-File.
Wenn hier ext4 angegeben ist, schreibt das MTK DT auch ext4 - und nicht YAFFS (das ist ein anderes Datei-System, welches heute nicht mehr benutzt wird)
Alternativ kann ich Dir - sofern Du das Boot- und Recovery-Image hier anhängst, ein passendes Recovery erstellen.

 

[rzdz]

Backup geht nur, wenn Du Root-Zugriff (grünes Quadrat) hast.

Dachte ich mir schon.

Dazu entweder den Root-Knopf drücken -

Die darauf folgende Fehlermeldung sieht Du oben im Screenshot.

... oder alternativ Chainfires adb insecure von XDA installieren.. [2014.11.10][ROOT] adbd Insecure v2.00 | Android Development and Hacking | XDA Forums

Danke, werde ich mir ansehen.

Du könntest auch - wie mit dem Recovery das gepatchte Boot-Image einspielen.

Das erscheint mir im Moment die sympathischste Lösung zu sein.
Die Befehle wären dann folgende?

>adb Shell
$ su
# dd if=/sdcard/boot_patched.img of=/dev/boot

Warum hat das eigentlich beim Recovery ohne Scatterfile funktioniert?
Könnte ich dann nicht alle benötigten Sicherungsdateien so rücksichern?

Das MTK DT nimmt die dumchar oder eMMC und erstellt daraus das Scatter-File.

Dann müßte man doch die damit ausgelesenen Werte auch in die Scatterdatei übertragen können, oder nicht (mein Vorschlag x Beiträge weiter oben) (?)

Wenn hier ext4 angegeben ist, schreibt das MTK DT auch ext4 - und nicht YAFFS (das ist ein anderes Datei-System, welches heute nicht mehr benutzt wird)

Ja, das wäre logisch. Ist in diesem Fall aber nicht so...

Alternativ kann ich Dir - sofern Du das Boot- und Recovery-Image hier anhängst, ein passendes Recovery erstellen.

OK, hänge ich dran.

 

[N2k1]

Nur grad eine kurze Antwort - die Images sehe ich mir später an.
Sichere mal bitte die /proc/dumchar_info.
Lade diese dann zusammen mit der Scatter-Datei hier hoch.
Zum Übertragen des Boot-Images: Ich glaube es heißt nicht /dev/boot (einfach mal nachsehen .. /dev/boot.img oder /dev/boot.image oder sowas)
Wenn Das Gerät fastboot unterstützt, kannst Du es per fastboot flash boot boot.img flashen (versuch mal adb reboot bootloader (eventuell auch boot-loader))

Nun zu der Frage, warum man es nicht einfach so einspielen kann: Nun, das System und noch wichtiger die Data-Partition ist ja "in Benutzung".
Das bringt Probleme.
Im recovery - sofern ADB unterstützt wird - kannst Du aber über die dumchar an alles drankommen.
adb shell
dd if=/emmc@adnroid of=/sdcard/system.img (Partitions-Namen entsprechend anpassen .. ich hatte mal ein ADB Tool geschrieben, muß es mal suchen - dort wurden alle in der /proc/dumchar_info genannten Parttionen gesichert. Das war zwar für Linux, könnte ich aber anpassen.)

 

[rzdz]

Sichere mal bitte die /proc/dumchar_info.
Lade diese dann zusammen mit der Scatter-Datei hier hoch.

Hatte ich schon gepostet...
Problem beim Rooten mit MTK Droidtool... | Seite 3 - Android-Hilfe.de

Wenn Das Gerät fastboot unterstützt, kannst Du es per fastboot flash boot boot.img flashen (versuch mal adb reboot bootloader (eventuell auch boot-loader))

Habe eben fastboot.exe in den ADB-Ordner von Droidtools ergänzt, da im Moment auf meinem Win7- PC kein ADB und Fastboot installiert sind.

 

[N2k1]

Wird Fastboot vom Gerät unterstützt?

 

[rzdz]

Wie kann ich das feststellen?