[Anleitung]Acer Iconia Tab B1 rooten

[entonjackson]

Kannst Du eine Prüfroutine einbauen, die die Partitionswerte abgleicht? Und je nach Ausgabe entweder "unseren" Wert - oder den "faulty" Wert für das Zurückschreiben verwendet?

Ich gebe pawitp Recht - brickgefahr ist immens (so lange sich die Partitionsdaten unterscheiden). Jedoch hat noch keiner von den "faultys" es geschafft mit dumchar mal Daten zur Verfügung zu stellen, damit wir deren Offsets sehen können....

Die Prüfroutine besteht ja bereits. Und sie ist auch der Grund, warum das Programm bei vielen hängen bleibt. Ich kann sie natürlich erweitern um einen 2. Wert, aber zuerst müssen wir rausfinden, wie die offsets zu setzen sind.

In meinem Fred findest dumps von faultys... jeder 2. post ist einer...

 

[alba81]

Wow ... gestern war da aber noch nix

Gut, damit können wir arbeiten. Ich berechne mal die Offsets, die Du setzen müsstest mit den neuen Werten, dann kann man ja sehen ob sich jemand bereit erklärt...

 

[entonjackson]

Wow ... gestern war da aber noch nix

Gut, damit können wir arbeiten. Ich berechne mal die Offsets, die Du setzen müsstest mit den neuen Werten, dann kann man ja sehen ob sich jemand bereit erklärt...

Hey! ich will auch wissen wie das geht

 

[alba81]

An dieser Stelle Danke an Frapl:

- MAKE SURE IT HAS THIS EXACT LINE. IF NOT, RECALCULATE THE ADDRESS FOR ALL COMMANDS BELOW
android 0x0000000026500000 0x00000000020e8000 2 /dev/block/mmcblk0p3
- dump system partition to /cache with "dd if=/dev/block/mmcblk0 bs=4096 skip=8424 count=156928 | gzip > /cache/system.img.gz" "bs=4096" sind die Bytes, die auf einmal ausgelesen werden. In HEX Schreibweise somit "0x1000". (mit dem Taschenrechner von Windows im Programmierer Modus einfach umzurechnen)

"skip=8424" ist HEX "0x20E8" der Wert aus der zweiten HEX Zahl "0x00000000020e8000" und zusammen mit dem "bs=4096" (0x1000) also "0x20e8000".

"count=156928" ist HEX "0x26500" der Wert aus der ersten HEX Zahl "0x0000000026500000" und zusammen mit dem "bs=4096" (0x1000) also "0x26500000".

Ist die Ausgabe "android 0x0000000026500000 0x00000000020e8000 2 /dev/block/mmcblk0p3" also anders als angegeben könnte man "count" und "skip" neu berechnen.

 

[entonjackson]

also muss nur der count wert geändert werden und zwar in 89600, da 0x0000000015e00000 => 0x15e00 => 89600 dec

Heißt, der neue Befehl würde lauten:
dd if=/dev/block/mmcblk0 bs=4096 skip=8424 count=89600 | gzip > /cache/system.img.gz

 

[alba81]

Ich hätte jetzt folgende dd:

dd if=/dev/block/mmcblk0 bs=4096 skip=8960 count=134784 | gzip > /cache/system.img.gz

Der ursprüngliche Beitrag von 11:45 Uhr wurde um 11:49 Uhr ergänzt:

also muss nur der count wert geändert werden und zwar in 89600, da 0x0000000015e00000 => 0x15e00 => 89600 dec

Heißt, der neue Befehl würde lauten:
dd if=/dev/block/mmcblk0 bs=4096 skip=8424 count=89600 | gzip > /cache/system.img.gz

Bist du sicher? Es unterscheiden sich ja sowohl skip als auch count von unseren Werten - ich denke es müssten beide angepasst werden.

 

[entonjackson]

Ich hätte jetzt folgende dd:

dd if=/dev/block/mmcblk0 bs=4096 skip=8960 count=134784 | gzip > /cache/system.img.gz

Der ursprüngliche Beitrag von 11:45 Uhr wurde um 11:49 Uhr ergänzt:



Bist du sicher? Es unterscheiden sich ja sowohl skip als auch count von unseren Werten - ich denke es müssten beide angepasst werden.

Keine Ahnung, wie hast du den skip und count wert jetzt berechnet?

 

[alba81]

Sorry, hatte einen Denkfehler. Dein Befehl ist richtig berechnet, kam nur mit dem skip und count durcheinander.

 

[entonjackson]

100% dass es passt? Ich will nicht der böse nachher sein ;-)
programmiert ist es in 2 Minuten...

 

[alba81]

Dem oben genannten Rechenweg zufolge - ja. Ich komme auf das gleiche Ergebnis.

Pawitp schreibt ja auch in seinem Ur-Tut, daß wenn sich die Werte unterscheiden man diese eben einfach nachjustieren kann.

Allerdings bin ich in Sachen Offset kein Profi, würde mich dir anschließen - und nicht für Bricks verantwortlich sein wollen. Hätte ich einen 15e B1 würde ich es ja riskieren, aber das ist ja nicht der Fall...

Vielleicht kann uns Frapl (oder sonst jemand mit entsprechender Sachkunde) grünes Licht geben? Alternativ mal bei den devs nachhören, was bullbrand sagt...

 

[entonjackson]

hab den pawitp gefragt, wegen dem befehl. er hat gemeint ohne risiko kriegt man es folgendermaßen raus obs tut oder nicht.

man pulled das system image. entzippt es und versucht es zu mounten. und wenn dann ein fehler kommt, tut es nicht!

hab es einen ausprobieren lassen. und der befehl tut nicht.

hab jetzt den pawitp nochmal gefragt, wie das sein kann. der meint, die dumchar_info zeigt das wohl falsch an:

It could mean that dumchar is wrong, since the actual value used for the system partition may be from the partition table not dumchar.

weißt du wie man an die parition table ran kommt?

 

[alba81]

Bei meinen rudimentären Linux-Kenntnissen kann ich auch nur auf Wikipedia verweisen - jedoch ohne Gewähr, daß es sich auch so umsetzen lässt ... bin noch auf der Arbeit, kanns nicht prüfen:

Partitionstabelle sichern und wiederherstellen

Würde dies im Umkehrschluss bedeuten, daß u.U. gar nicht die Partition selbst, sondern nur die Information in der dumchar falsch ist, und damit auch erklärbar werden, wie jemand trotz falscher Daten sein Dump ausführen und mit dem urpsrünglichen dd Wert zurückschreiben konnte - habe ich doch so richtig verstanden, oder?

Sollte dies zutreffen könnte man ja dann den "faultys" helfen und die dumchar korrigieren, so daß sie die OTAs einspielen können??

 

[entonjackson]

Bei meinen rudimentären Linux-Kenntnissen kann ich auch nur auf Wikipedia verweisen - jedoch ohne Gewähr, daß es sich auch so umsetzen lässt ... bin noch auf der Arbeit, kanns nicht prüfen:

Partitionstabelle sichern und wiederherstellen

Würde dies im Umkehrschluss bedeuten, daß u.U. gar nicht die Partition selbst, sondern nur die Information in der dumchar falsch ist, und damit auch erklärbar werden, wie jemand trotz falscher Daten sein Dump ausführen und mit dem urpsrünglichen dd Wert zurückschreiben konnte - habe ich doch so richtig verstanden, oder?

jap.
ich werds auch testen, wenn ich daheim bin.

hört sich für mich alles nach nem riesen pfusch von acer an... könnte wetten, dass ist auch der grund, warum die updates nicht tun.

 

[Jackal]

Wenn ihr das hinkriegt, seid ihr wirklich die Helden.

Der Stand bei Acer nach 3 Wochen Fehlersuche:
We are still actively pursuing a solution to this error message. We hope to have a resolution soon. I will keep you posted as I have additional information.

 

[alba81]

Das ist ja noch nicht alles ... wie hier (und auch in anderen Foren, z.B. 4pda.ru) berichtet wurde sind auch Testgeräte ausgeliefert worden, die keinesfalls für die Öffentlichkeit gedacht sind. Leider lese ich immer zu spät, nachdem die Leute die Geräte zurück gegeben haben.

Zudem ... ich lese an verschiedenen Stellen, daß das B1 auch als 16GB-Version angeboten werden soll bzw. sogar verfügbar sein soll. Was mich ja tierisch interessieren würde wäre der emmc-Baustein bei den 15e-Versionen. Nicht, daß es verkappte 16er sind, die nur "falsch" partitioniert wurden...

Edit:

Siehe screenshot hier (zum Thema Testgeräte):

http://4pda.ru/forum/index.php?s=&showtopic=418516&view=findpost&p=21590293

 

[Jackal]

Nicht, daß es verkappte 16er sind, die nur "falsch" partitioniert wurden...

http://4pda.ru/forum/index.php?s=&showtopic=418516&view=findpost&p=21590293

Wenn das stimmt, wären wir, mit dem defekten B1, ja sogar die Nutznießer.
Natürlich nur, wenn ihr Experten das hinbekommt.
Könnt dann schonmal eure Paypal-Daten angeben...

Auf jeden Fall warte ich jetzt noch mit dem Umtausch meines "defekten" B1!

 

[alba81]

jap.
ich werds auch testen, wenn ich daheim bin.

Ich kann die dumchar_info öffnen und finde die besagten Angaben wieder. Jedoch komme ich in /proc natürlich nur mit bestehendem Root rein.

Mein Ansatz:
Bevor wir riskante Schreibversuche in unsichere Dateisysteme vornehmen - wie wäre es eine gefakte dumchar_info zu erstellen, für diese Dein Toolkit dahingehend abzuändern und sie nach erfolgtem Telnet-Aufbau durch die Hintertür nach /proc zu schieben?

Sollte die OTA Routine sich auf diese Information beziehen hätten wir den Fehler behoben, oder?

Parallel müssten wir noch verifizieren, ob in deinem Fred der besagte User es tatsächlich geschafft hat - wie ich vermute auf Linux "from scratch" - trotz fehlerhaftem Eintrag die System.img.gz erfolgreich einspielen zu können. Wäre dies der Fall müsste nur noch geklärt werden wie wir auf deinem gerooteten B1 die Partitionsdaten vom Datenträger lesen können, z.B. per fdisk. Ich bekomme es am Terminal am B1 nicht hin, glaube aber das es an der fehlenden Busybox liegen könnte ... richtig?

@ Jackal: Das war jetzt natürlich eine extrem weit hergeholte Mutmaßung meinerseits Herausfinden können wir es nur, wenn einer der Betroffenen sein Tab öffnet und den entsprechenden Chip lokalisiert. Ich kann natürlich niemanden dazu überreden..... ;-)

Kann dazu aber sagen, daß es mit einer normalen Plastikkarte sehr einfach und ohne Spuren zu bewerkstelligen ist. Habs selbst schon mal gemacht

 

[entonjackson]

Ich kann die dumchar_info öffnen und finde die besagten Angaben wieder. Jedoch komme ich in /proc natürlich nur mit bestehendem Root rein.

Mein Ansatz:
Bevor wir riskante Schreibversuche in unsichere Dateisysteme vornehmen - wie wäre es eine gefakte dumchar_info zu erstellen, für diese Dein Toolkit dahingehend abzuändern und sie nach erfolgtem Telnet-Aufbau durch die Hintertür nach /proc zu schieben?

Sollte die OTA Routine sich auf diese Information beziehen hätten wir den Fehler behoben, oder?

Parallel müssten wir noch verifizieren, ob in deinem Fred der besagte User es tatsächlich geschafft hat - wie ich vermute auf Linux "from scratch" - trotz fehlerhaftem Eintrag die System.img.gz erfolgreich einspielen zu können. Wäre dies der Fall müsste nur noch geklärt werden wie wir auf deinem gerooteten B1 die Partitionsdaten vom Datenträger lesen können, z.B. per fdisk. Ich bekomme es am Terminal am B1 nicht hin, glaube aber das es an der fehlenden Busybox liegen könnte ... richtig?

@ Jackal: Das war jetzt natürlich eine extrem weit hergeholte Mutmaßung meinerseits Herausfinden können wir es nur, wenn einer der Betroffenen sein Tab öffnet und den entsprechenden Chip lokalisiert. Ich kann natürlich niemanden dazu überreden..... ;-)

Kann dazu aber sagen, daß es mit einer normalen Plastikkarte sehr einfach und ohne Spuren zu bewerkstelligen ist. Habs selbst schon mal gemacht

ja ich dachte auch schon darüber nach die "defekte" dumchar_info mit ner richtigen zu ersetzen, aber zuerst müssen wir sicher stellen, dass die "defekten" b1 nichts weiter als "gute" b1 sind mit falscher dumchar_info file.

ich hab mal

shell@android:/ $ cat /proc/emmc

gemacht. dabei kam das raus:

partno: start_sect nr_sects partition_name
emmc_p1: 00000020 00000002 "ebr1"
emmc_p2: 0000ac40 00002800 "sec_ro"
emmc_p3: 00010740 00132000 "android"
emmc_p4: 00142f40 00100000 "cache"
emmc_p5: 00243740 001fd800 "usrdata"
emmc_p6: 00441740 00a431c0 "fat"

bringt uns das was?

 

[Jackal]

Bin noch auf der Arbeit.
Wenn ich um halb elf zu Hause bin ziehe ich mir nen 6er-Träger rein und dann gehts los.
Müsste nur noch wissen wonach ich gucken soll.
Ich denke, auch wenns leichte Blessuren gibt, kann ich trotzdem noch umtauschen wegen der fehlenden Update-Möglichkeit...

Gesendet von meinem GT-I9300 mit Tapatalk 2

 

[alba81]

ja ich dachte auch schon darüber nach die "defekte" dumchar_info mit ner richtigen zu ersetzen, aber zuerst müssen wir sicher stellen, dass die "defekten" b1 nichts weiter als "gute" b1 sind mit falscher dumchar_info file.

ich hab mal

shell@android:/ $ cat /proc/emmc

gemacht. dabei kam das raus:



bringt uns das was?

Damit rufst du ja auch nur die emmc Datei aus dem Verzeichnis /proc/ auf - ist das gleiche wie mit dumchar_info.

Das OTA stört sich ja am FAT Eintrag:

17: fat 238e8000: 888e8000

In meiner dumchar habe ich:

0x0000000148638000 0x00000000882e8000

Nehme an, das dieser Wert entsprechend in die dumchar der faultys rein müsste.

Bin noch auf der Arbeit.
Wenn ich um halb elf zu Hause bin ziehe ich mir nen 6er-Träger rein und dann gehts los.
Müsste nur noch wissen wonach ich gucken soll.
Ich denke, auch wenns leichte Blessuren gibt, kann ich trotzdem noch umtauschen wegen der fehlenden Update-Möglichkeit...

Gesendet von meinem GT-I9300 mit Tapatalk 2

Es ist ein Kingston Baustein. Im oben verlinkten Thread von 4pda.ru geht es um eines der Testgeräte, der user hat es auch geöffnet, und gibt kingston ke4cn3k6a als Speicherbaustein an. Seltsamerweise schreibt er dort, daß es ein 16gb-baustein ist, obwohl es laut Beschreibung ein 8gb-tab ist. Wenn ich nach ke4cn3k6a suche komme ich auf die Herstellerseite, wo eindeutig 8gb angegeben werden.