Problem beim Rooten mit MTK Droidtool...

rzdz

rzdz

Fortgeschrittenes Mitglied
1
Hallo,
ich habe folgendes Problem beim Rooten mit MTK Droidtool:



Kann mir jemand sagen, was ich falsch mache?
Die beiden Links helfen leider auch nicht weiter (der 1. ist russisch, beim 2. verstehe ich nur Bahnhof...)


Muß vor der Installation vom CWM-Recovery aus MTK-Droid zuerst gerootet werden, oder wie funktioniert das dann?
Wie werden die beiden gepatchten Dateien *boot_patched_.img und *recovery_.img zurück aufs Handy geflasht?
 
Flashen sollte immer mit dem SPFT erfolgen.
Alternativ könnte dein gerät auch fastboot unterstützen
Damit wäre es dann fastboot flash recovery recovery.img bzw. fastboot flash boot boot_patched_.img
 
Was ist denn oben beim MTK-Droidtool schiefgelaufen? (Hätte ich vielleicht die SD-Karte heraus nehmen sollen?) [PS: nein, hat offenbar keinen Einfluß]

Es gibt Anleitungen, daß man "Root" drücken soll, und es dann einfach durchläuft.

Wo wird das SU gesucht?
Auf dem Handy?
Im MTK-Droidtool ist glaube ich in einem Unterordner eine SUSU-Datei vorhanden (kann hier gerade nicht nachsehen).

Was ist mit dieser Anleitung?

N2k1 schrieb:
Flashen sollte immer mit dem SPFT erfolgen.
Wie genau?
N2k1 schrieb:
Alternativ könnte dein gerät auch fastboot unterstützen
Damit wäre es dann fastboot flash recovery recovery.img bzw. fastboot flash boot boot_patched_.img
Einfach ausprobieren nach dieser Anleitung?

Welche Reihenfolge ist die richtige?
Erst Rooten, dann Custom Recovery oder umgekehrt (oder ist das egal?)


Dubiose (?) Tools wie iroot, vroot, towelroot, framaroot... möchte ich lieber nicht benutzen...

Ich lese ständig auch von diesen "Mobileuncle MTK Tools", würde das helfen, oder was ist davon zu halten?


Entweder war ich vor 2 Jahren mit meinem alten Android schlauer, oder es ging alles viel einfacher... :mellow:
 
Zuletzt bearbeitet:
Die Anleitung ist "fast passend" .. RUU und ähnliche Dinge gibt es bei den MTK-Devices nicht.
Ich würde jetzt wie folgt vorgehen:
  • SPFT öffnen
  • Scatter laden
  • Alle Haken aus
  • Das gepatchte Boot-Image oder das gepatchte Recovery auswählen
  • Auf Download klicken
  • Ausgeschaltetes Gerät an den USB-Port hängen
  • Auf das Fenster mit dem grünen Kreis - oder eine Fehlermeldung - warten

Vor und Nachteile (und warum nicht beide Images gleichzeitig?!)

Vorteil Boot.img
- Du hast ein grünes Quadrat im MTK DT - und damit geht dann alles, was versprochen wird
- Diverse recovery-Tools funktionieren nun (MTK TWRP etc.)
Nachteil:
- Root in der ADB Shell ist ein sehr mächtiges Tool - also nur sinnvoll, wenn man weiß, was man tut.

Vorteil Recovery.img
- Du kannst ein Backup erstellen
- Kannst das Telefon durch Installation der SuperSu.zip rooten
Nachteil:
- Kein Root in der Shell - außer durch Eingabe von SU
- Das Recovery ist sehr alt

Flashen per Fastboot:
- Du umgehst das SPFT (manche User mögen es einfach nicht - oder haben Probleme)
- Es funktioniert nicht immer sauber auf unseren Geräten (MTK)
 
  • Danke
Reaktionen: rzdz
Danke für die ausführliche Antwort. :thumbup:

Habe mich vorerst für das Recovery entscheiden:



PMT = partition management table ?
Was kann sich da geändert haben?
Habe das Handy mittlerweile in Betrieb, aber nur ein paar Apps zum Testen installiert und nichts geflasht.

Spielt es eine Rolle, ob die Scatterdatei aus dem Ordner ...\MTKdroidTools\ oder ...dem Unterordner \MTKdroidTools\backups\ALCATEL-ONE-TOUCH-7041D_140804_ForFlashtoolFromReadBack_150616-195358\ genommen wird?
Totalcommander sagt, beide seien binär-identisch, bei Auswahl der letzteren ist die Boot.img aber schon angehakt und rechts steht ein Dateipfad drin (?)
[PS: wird die Scatterdatei aus dem Backups-Unterordner ausgewählt, werden die dort vorhandenen Image-Dateien automatisch in der Tabelle ausgewählt und angekreuzt, sofern die Dateinamen mit denen aus der Scatterdatei übereinstimmen]

ALCATEL-ONE-TOUCH-7041D_140804__recovery_150616-195358.img ist 4618 KB (0x555000) groß,
factory_NONmodified_recovery.img dagegen 6144 KB (0x600000). Könnte es daran liegen?

Was ist zu tun?

BTW: hättest Du eine neuere (passende) Recovery?
 
Zuletzt bearbeitet:
Welche Scatter dabei genommen wird ist egal.
Daß der Fehler bei einer selbst erstellten Scatter-Datei kommt, spricht dafür, daß der Hersteller "nachträglich" Änderungen an der Partition vorgenommen hat.
(Das passiert zum Beispiel, wenn man die Partitionen vom Recovery aus ändert)
Um diesen Fehler zu umgehen, benötigt man alle Partitionen (also auch Cache und Userdata).
Danach einfach von "Download only" auf "Firmware upgrade" stellen.
Ein Recovery darf kleiner sein als die Partition - nur nicht größer
 
  • Danke
Reaktionen: rzdz
OK, danke, werde ich zuhause dann gleich ausprobieren!

Ich dachte die Scatterdatei würde aus dem Gerät ausgelesen, deswegen habe ich jetzt auch nicht ganz verstanden, wo der Hersteller oder wer auch immer da noch was geändert haben könnte.
 
Die Daten der Partitionen sind an verschiedenen Stellen hinterlegt (EBR/PMT)
Die Daten aus dem EBR stehen unter /proc/eMMC (oder so ähnlich)
Diese Daten werden vom MTK DT ausgewertet - und die Scatter entsprechend erstellt.
Stimmt nun die PMT nicht mit diesen Daten überein, dann kommt "PMT changed"
 
Ich habe mal weitergewurstelt...

Die Dateien Cache und Userdata fehlen leider bei meinem bisherigen entpackten Backup.

Mir ist eingefallen, daß in der Scatterdatei Adressen bis knapp unter die 4GB vorkamen, und daß bei meinem Backupversuch Dir ja auch schon eine Datei fehlte.
Also habe ich mir die nochmals aus dem eben frisch "werksresetteten" Gerät ausgelesene Scatterdatei angesehen:


.
.
.
- partition_index: SYS20
partition_name: USRDATA
file_name: data.img
is_download: true
type: YAFFS_IMG
linear_start_addr: 0x65880000
physical_start_addr: 0x64880000
partition_size: 0x82C00000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: UPDATE
reserve: 0x00

- partition_index: SYS21
partition_name: RSV_OTP
file_name: NONE
is_download: false
type: NONE
linear_start_addr: 0xFFFF0200
physical_start_addr: 0xFEFF0200
partition_size: 0x4000000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: INVISIBLE
reserve: 0x00

- partition_index: SYS22
partition_name: BMTPOOL
file_name: NONE
is_download: false
type: NONE
linear_start_addr: 0xFFFF00A8
physical_start_addr: 0xFFFF00A8 (<- fast 4GB !)
partition_size: 0x1500000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: false
is_reserved: true
operation_type: RESERVED
reserve: 0x00



Nach mehreren Versuchen, die Größe der heruntergeladenen Rom_Datei an die vollen 4GB anzunähern (4GB wurden als Endadresse abgelehnt), bin ich durch Berechnung der Endadresse der Userdata-Partition auf = 0xE8480000 gekommen ( = linear_start_addr 0x65880000 + partition_size 0x82C00000 ).
Hoffe diese Methode ist korrekt (?).
Jedenfalls ist damit der Download einer 3,63GB großen ROM_Datei gelungen, die beim Entpacken dann unter anderem auch eine 2,04GB große Data.img-Datei und eine 313KB große cache.img-Datei enthalten hat.

Mit dem neuen Satz an Image-Dateien werde ich jetzt einen neuen Flash-Versuch starten.

Was ist eigentlich mit dem Rest zwischen 0xE8480000 und 0xFFFFFFFF?

Was liegt da (SYS21+SYS22 ?), was ist das,
Wird das für ein vollständiges Backup nicht benötigt (Filename = None)?
Und falls doch, wie komme ich da ran?

Das Flashtool hatte bei meinen Versuchen, möglichst viel der 4GB zu sichern, ständig gemotzt wegen "ungültiger Adressen" oder Boundary-"Irgendwas", so daß ich erstmal zufrieden war, Userdata und Cache wie eben beschrieben sichern und entpacken zu können... [PS: Bilder dazu 2 Beiträge weiter unten]
 
Zuletzt bearbeitet:
Jeder Speicher hat Fehler.. demnach nutzt man nicht alle Bereiche. Warum das in dem Fall gerade zwischen den beiden Bereichen liegt, kann ich nicht sagen.
Aber RSV klingt für mich nach Reserve.
Als Data könntest Du auch ein leeres (oder fremdes) Image flashen - wenn es nicht um Deine Daten geht.
 
rzdz schrieb:
Mit dem neuen Satz an Image-Dateien werde ich jetzt einen neuen Flash-Versuch starten.
Jetzt hakt's hier:



Muß in jeder Zeile die entsprechende Quelldatei angegeben werden? Ist es das?

Übrigens unterscheiden sich die beiden letzten heruntergeladenen ROM_Dateien nicht nur in Größe und Vorhandensein der data.img :



Warum unterscheiden die sich, ich habe direkt nacheinander nur verschiedene Endadressen beim ROM-Auslesen ausprobiert, um zu sehen, ab welcher Größe auch Userdata und Cache mit dabei sind?
 
Zuletzt bearbeitet:
1. Wenn Du nur das Recovery flashen willst, so nutze "Download only" - statt "Firmware upgrade"
Kommt hier jedoch PMT changed, so bleibt nur der Weg über Firmware upgrade - aber nun muß jedes einzelne Image geflasht werden.

2. Wenn das Telefon zwischendurch nicht an war - dann sollten die ausgelesenen Sachen auch absolut identisch sein (erstelle mal die MD5 für beide Verzeichnisse)
 
  • Danke
Reaktionen: rzdz
N2k1 schrieb:
1. Wenn Du nur das Recovery flashen willst, so nutze "Download only" - statt "Firmware upgrade"
Wie Du siehst kommt genau das:
N2k1 schrieb:
Kommt hier jedoch PMT changed, so bleibt nur der Weg über Firmware upgrade - aber nun muß jedes einzelne Image geflasht werden.
"Einzeln" heißt immer nur 1 Haken + Datei aus Backup-Odner zuordnen, dann "Download" Button?
Dann nächste Zeile bis man durch ist?
Alle markieren, alle zuordnen und dann in einem Rutsch "downloaden" geht nicht?

N2k1 schrieb:
2. Wenn das Telefon zwischendurch nicht an war - dann sollten die ausgelesenen Sachen auch absolut identisch sein (erstelle mal die MD5 für beide Verzeichnisse)
Dachte ich auch, aber das Handy war nicht eingeschaltet, und die Unterschiede sind trotzdem da.
Mußte es nach dem neuen Readout-Start mit neuer End-Adresse aber kurz vom USB trennen und wieder anstecken, damit der rote Balken kam ("Download DA 100%").

MD5 kann ja auch nur unterschiedlich sein, da bereits der Binärvergleich der einzelnen Dateien unterschiedlich war (siehe Screenshot oben vom Totalcommander).

Habe eben noch etwas herausgefunden:
Wenn man im Flashtool die Scatterdatei aus dem Ordner auswählt, in die MTK Droidtools die IMG-Dateien geschrieben hat (im Unterordner "Backups"), dann sind alle Partitionen bereits angehakt und auch die neuen Imagedateien bereits unter "Location" eingetragen:



Hier fehlen UBOOT und RECOVERY, da die erwarteten Dateinamen (siehe Scatterdatei) nicht in dem Ordner sind.
Wird eine der Recoverydateien (in dem Fall ALCATEL-ONE-TOUCH-7041D_140804__recovery_150618-231412.img oder factory_NONmodified_recovery.img) zu recovery.img umbenannt, wird diese auch erkannt, die Zeile automatisch angehakt und der Pfad zur Datei automatisch eingetragen.
Das Gleiche trifft für UBOOT zu, mit dem Unterschied, daß dazu die uboot.bin in LK.bin umbenannt werden muß.

Test der Flashbarkeit (Download-Only-Modus):



Firmware-Upgrade-Modus:



Fazit: geht beides nicht!

Was nun? :sad:

(So wie das aussieht, könnte ich nicht mal mein Backup des Auslieferzustands zurück laden, also Vorsicht...)
 
Zuletzt bearbeitet:
rzdz schrieb:
"Einzeln" heißt immer nur 1 Haken + Datei aus Backup-Odner zuordnen, dann "Download" Button?
Dann nächste Zeile bis man durch ist?
Alle markieren, alle zuordnen und dann in einem Rutsch "downloaden" geht nicht?

Nein, alle gleichzeitig - aber eben jedes muß da sein.

Bezüglich des letzten Bildes muß ich im Moment passen, da ich das noch nie hatte - aber ich habe Ora mal angeschrieben. Vielleicht hat er eine Idee.
(Da er mehr unterschiedliche Geräte hat(te), hatte er sicherlich auch schon mehr Fehlermeldungen als ich.)
 
Danke, mir gehen die Ideen auch langsam aus. :(
Besonders was mein Backup angeht, bekomme ich langsam kalte Füße, da ich das ja auch nicht zurück spielen könnte, so wie das jetzt aussieht...
 
Zuletzt bearbeitet:
Habe jetzt in einem russischen Forum gelesen. daß dies wohl ein Fehler des Flash-Tools sei - sofern man einen Fehler der Scatter-Datei ausschließen könne.
 
Könnte das hiermit etwas zu tun haben?
v2.5.2 - Post #757 - XDA Forums

Known unresolved problems v2.5.2:
- doesn't make backup ubifs blocks
- block secro incorrectly saves on some phones with MTD type flash if it is not mounted in the system
- doesn't make scatter in a new format for 6582 and 6572 devices ( in development process)

Eine Scatterdatei wir ja erstellt, außerdem habe ich MTK Droidtools 2.5.3 benutzt...
 
Du hast kein UBIFS, kein MTD Device und auch keinen der genannten SoC - zudem die neuere Version..
Schau mal nach, was in der Datei /proc/eMMC steht.
 
Das Gerät ist als MTP-USB-Gerät anschlossen, zumindest steht das im USB-Menü des Handys (der Punkt USB-Speicher läßt sich nicht aktivieren, ist ausgegraut).

SoC ist der 6582.
Zur Version 2.5.3 habe ich nichts gefunden (bei XDA kann ich nicht posten, da ich nicht weiß, wie ich die sonst die geforderten 10 Posts erreichen kann).

Schau mal nach, was in der Datei /proc/eMMC steht.
Wie komme ich da ran? Über USB sehe ich nur den Tabletspeicher.
 
Zuletzt bearbeitet:
Über die ADB Shell kommst Du da ran.
Im Verzeichnis des MTK DT gibt es ein ADB unter-Verzeichnis.
Dort adb shell oder adb pull /proc/eMMC eingeben.
 

Ähnliche Themen

Downguy
  • Downguy
Antworten
5
Aufrufe
307
Nightly
Nightly
E
Antworten
1
Aufrufe
450
mblaster4711
mblaster4711
T
  • Technikfreund83
Antworten
1
Aufrufe
2.831
Technikfreund83
T
Zurück
Oben Unten