Hirdetés

Lenovo Tab M11 TB330XU – MediaTek BROM-szintű helyreállítás, BOOT1/BOOT2 javítás

Írta: Ragua
2026-10-01 19:01

Lenovo Tab M11 TB330XU – teljes helyreállítási esettanulmány

A teljesen fekete kijelzős állapottól az első sikeres gyári Android-indításig
Dokumentált munkafolyamat: 2026. szeptember 22–26.

A dokumentáció háttere / A tablet helyreállítása a ChatGPT folyamatos segítségével történt. A hibakeresés során a felhasználó végezte a fizikai műveleteket, futtatta a parancsokat és közölte a tényleges kimeneteket; a ChatGPT ezek alapján segített a következő diagnosztikai lépések megtervezésében, a kockázatok értékelésében, a fájlok és partíciók összehasonlításában, valamint az ellenőrző parancsok összeállításában. Ez a dokumentáció ugyanezen, több napon át rögzített műszaki munkafolyamat alapján készült. Nem utólag kitalált általános javítási recept, hanem egy konkrét készülék konkrét helyreállításának részletes esettanulmánya.

1. A kiindulási helyzet: egy látszólag teljesen halott tablet

Hirdetés

A javítás kezdetén a Lenovo Tab M11 TB330XU olyan állapotban volt, amely felhasználói szemmel könnyen teljes hardverhibának tűnhetett. A kijelző fekete maradt, nem jelent meg Lenovo-logó, töltési animáció, recovery vagy fastboot képernyő, és a szokásos gombkombinációk sem adtak használható vizuális visszajelzést. A készülék tehát nem egyszerű bootloopban volt: kívülről nézve gyakorlatilag semmit nem csinált.
A hibát közvetlenül megelőzően bootloader-nyitási és különböző image-ek flashelésével kapcsolatos próbálkozás történt. A rendelkezésre álló információ szerint az egyik írási folyamat 100%-ig lefutott, utána azonban a tablet már nem indult el. A korábbi műveletekről nem állt rendelkezésre olyan teljes mentés vagy részletes napló, amelyből egyetlen pillantással meg lehetett volna mondani, pontosan melyik fizikai terület változott meg.
Ez meghatározta a javítás stratégiáját. Nem lehetett egyszerűen azt mondani, hogy „írjuk vissza a boot.img-t”, mert nem tudtuk, hogy a hiba a normál Android-partíciókban, a korai bootláncban, az AVB-láncban, a preloaderben vagy akár a tároló hardveres boot régióiban van-e. Ugyanilyen veszélyes lett volna egy teljes, ellenőrizetlen „format all + download” művelet, mert a készülék egyedi NV- és kalibrációs területeit is elveszíthettük volna.
Az első cél ezért nem a javítás, hanem az életjel megtalálása lett: meg kellett állapítani, hogy a MediaTek SoC legalacsonyabb szintű Boot ROM-ja elérhető-e még.

2. Az első napok valódi feladata: életjelet találni USB-n

A gyakorlatban ez azt jelentette, hogy egy-egy próbálkozás nem néhány másodperces „bedugom és működik” teszt volt. A tabletet le kellett választani, a megfelelő hangerőgombokat lenyomni, újracsatlakoztatni, közben figyelni a Windows hangját és azt, hogy a PnP-listában milyen rövid ideig jelenik meg az eszköz. Ha az időzítés nem volt megfelelő, a készülék eltűnt, és az egész ciklust elölről kellett kezdeni.
Az első egyszeri siker ezért inkább bizonyíték volt, mint megoldás. Azt bizonyította, hogy létezik egy működő belépési útvonal. A következő feladat ennek a véletlenszerűnek tűnő állapotnak a reprodukálása lett. Ez a különbség kívülről kevésbé látványos, mégis itt ment el a munka jelentős része: a javítást csak akkor lehetett biztonságosan folytatni, ha nem egyetlen szerencsés csatlakozásra építünk.
A fekete kijelző ebben a szakaszban végig megmaradt. Vagyis minden döntést a PC oldaláról kapott apró jelek alapján kellett meghozni. A Windows csatlakozási hangja, egy pillanatra felbukkanó VID/PID, az MTKClient egyetlen új sora vagy éppen a handshake megszakadásának helye vált diagnosztikai információvá.
Mivel a kijelző semmilyen információt nem adott, a Windows USB-eseményei váltak a „kijelzőnkké”. A tablet csatlakoztatásakor figyeltük a Windows csatlakozási és leválasztási hangjait, az Eszközkezelőt, valamint parancssorból a pillanatnyilag jelen lévő PnP-eszközöket. A probléma az volt, hogy a készülék csak nagyon rövid időre jelentkezett fel, majd eltűnt. Ezért könnyen úgy tűnhetett, mintha egyáltalán nem történne semmi.
pnputil /enum-devices /connected /ids pnputil /enum-devices /connected /ids | Select-String -Context 5,5 "MediaTek" pnputil /enum-devices /connected /ids | Select-String -Context 5,5 "VID_0E8D"
A különböző gombkombinációk közül a hangerő fel és hangerő le együttes nyomva tartása bizonyult a legfontosabbnak. A gombokat nyomva tartva, majd az USB-kábelt csatlakoztatva időnként megjelent egy új eszköz; kezdetben sokszor csak „Ismeretlen eszköz” formájában. Ez még messze nem volt használható BROM-kapcsolat, de döntő jel volt: a tablet elektronikája reagált az USB-re, tehát nem egy teljesen élettelen alaplappal álltunk szemben.
Ezen a ponton a javítás egyik legidőigényesebb része kezdődött. Az egyszer-egyszer felvillanó eszközállapotot meg kellett tanulni tudatosan előidézni. Nem az volt a helyzet, hogy megtaláltuk a megfelelő gombkombinációt, és onnantól minden csatlakozás sikerült. Ellenkezőleg: ugyanazzal a mozdulatsorral az egyik próbán semmi nem történt, a másikon megjelent egy eszköz, a harmadikon az MTKClient elkezdett kommunikálni, majd rögtön megszakadt.
Fontos a kapcsolat minősége / A BROM-hozzáférés a folyamat elején kifejezetten instabil volt. A későbbi, már tudatosan ismételt próbák során is előfordult, hogy körülbelül tíz csatlakoztatásból csak négy jutott el használható sessionig. Ezért a javítás során minden sikeres session értékes volt: amikor a tároló ténylegesen elérhetővé vált, igyekeztünk egy menetben minél több szükséges mentést elkészíteni.

3. MTKClient: az első kézfogások és a folyamatos handshake-hibák

A handshake-hibákból az is látszott, hogy nem érdemes egyetlen sikertelen futás után másik firmware-rel vagy agresszívebb írási módszerrel próbálkozni. Ugyanaz a készülék néhány percen belül képes volt teljesen eltérő mélységig eljutni. Emiatt a hibakeresésben előbb a kapcsolat felépülésének állapotait kellett szétválasztani.
Amikor végre megjelent a HW code 0x707 és a BROM mode detected sor, az már nem egyszerű Windows-eszközfelismerés volt. Ekkor maga a SoC Boot ROM válaszolt a MediaTek protokollra. Ez egyben azt is jelentette, hogy a korábbi flash nem tudta „kitörölni” a BROM-ot: az a chipbe égetett kód része, és éppen ez adott lehetőséget a helyreállításra.
A BROM-siker után sem engedtük el a gombkombináció és csatlakoztatási sorrend dokumentálását. Minden későbbi mentés és írás azon múlt, hogy új sessiont tudunk-e nyitni. A javítás alatt ezért a fizikai csatlakoztatás ugyanúgy a folyamat része volt, mint a PowerShell-parancsok.
A MediaTek platform miatt az MTKClient lett a fő diagnosztikai eszköz. A környezetet Python és Git segítségével építettük fel, majd a hivatalos projektből dolgoztunk. A korai próbálkozások leggyakoribb eredménye azonban nem sikeres kapcsolat, hanem újra és újra ugyanaz a handshake-hiba volt.
Port - Handshake failed after retries Preloader - [LIB]: Status: Handshake failed, retrying... Port - Hint: Power off the phone before connecting. For brom mode, press and hold vol up, vol dwn, or all hw buttons and connect usb.
Ez a hiba első látásra kevés információt ad, de a helyzet szempontjából fontos különbséget jelentett. A PC már érzékelt valamilyen MediaTek-kommunikációt, csak a protokoll nem jutott el a stabil kézfogásig. Vagyis már nem a „van-e egyáltalán életjel?” kérdésen dolgoztunk, hanem azon, hogy a rövid ideig megjelenő alacsony szintű kapcsolatot hogyan lehet elkapni és megtartani.
Sok próbálkozás után egyszer sikerült továbbjutni. Az MTKClient már nem pusztán újrapróbálkozott, hanem kiolvasta a hardverazonosítókat, és egyértelműen jelezte a BROM módot.
Preloader - CPU: MT6768/MT6769 (Helio P65/G85 k68v1) Preloader - HW code: 0x707 Preloader - Target config: 0xe7 Preloader - SBC enabled: True Preloader - SLA enabled: True Preloader - DAA enabled: True Preloader - Mem read auth: True Preloader - Mem write auth: True Preloader - Cmd 0xC8 blocked: True Preloader - BROM mode detected. Preloader - HW subcode: 0x8a00 Preloader - HW Ver: 0xca00
Ez volt az első igazi áttörés. A fekete kijelzős tablet SoC-ja válaszolt, a Boot ROM futott, és az MTKClient képes volt azonosítani a platformot. Ugyanakkor ez még nem jelentette azt, hogy innentől stabil hozzáférésünk volt. A következő próbán ugyanúgy visszaeshettünk handshake-hibába. A javítás első két napjának jelentős része éppen ebből a hullámzó állapotból állt: egy sikeres eredmény után meg kellett érteni, hogyan lehet ugyanoda ismét eljutni.

4. BROM után még csak a következő akadály következett: biztonság, DA és DRAM

A Kamakiri sikerét könnyű lett volna összekeverni a teljes hozzáféréssel, pedig ekkor még csak a következő ajtóig jutottunk. A payload futott, a DA első szakasza szinkronizált, de az eMMC tényleges kezeléséhez a programnak működő DRAM-ra volt szüksége. A „Sending emi data...” utáni hiba ezért mindig ugyanazon logikai határvonalat jelezte.
Az EMI-adatok szerepe a gyakorlatban itt vált kézzelfoghatóvá. A megfelelő memória-inicializálási információ nélkül a DA nem tudott stabil munkaterületet létrehozni, így hiába volt sikeres a BROM exploit, még nem lehetett biztonságosan partíciókat olvasni vagy írni.
Ez a felismerés azért is fontos volt, mert elválasztotta egymástól a biztonsági megkerülés és a hardver inicializálásának problémáját. A védelem megkerülése már működött; a következő akadály nem újabb „lock”, hanem a készülékhez illő memória-konfiguráció volt.
A BROM-log egy másik fontos dolgot is megmutatott: a készüléken több MediaTek-védelmi mechanizmus aktív volt. SBC, SLA és DAA engedélyezett állapotban jelent meg, és a memóriaolvasás/-írás is autorizációhoz kötöttnek látszott. Az MTKClient BROM módban a Kamakiri exploit útvonalát használta, és sikerült payloadot küldenie.
DaHandler - Device is protected. DaHandler - Device is in BROM-Mode. Bypassing security. Exploitation - Kamakiri Run Exploitation - Done sending payload... PLTools - Successfully sent payload: ...\mt6768_payload.bin DAXFlash - Successfully uploaded stage 1, jumping .. Preloader - Jumping to 0x200000: ok. DAXFlash - Successfully received DA sync DAXFlash - Sending emi data ...
Ezen a ponton már jóval mélyebben jártunk, mint egy egyszerű USB-felismerésnél. A BROM elfogadta a payloadot, a DA első szakasza elindult, majd a folyamat a DRAM inicializálásánál akadt el.
DAXFlash - DRAM setup failed: unpack requires a buffer of 12 bytes. Use mtk.py with --preloader preloader.bin !
A hibaüzenet irányt adott: a Download Agent a memória inicializálásához a megfelelő preloader/EMI információra támaszkodik. Ezért innentől nem volt elég annyit tudni, hogy TB330XU a modell; pontos, hozzá illő gyári firmware-csomagra és azon belül a megfelelő preloaderre volt szükség.

5. A V14 gyári firmware azonosítása és a scatter első döntő nyoma

A helyreállítási referenciának a TB330XU ROW V14 csomagját használtuk:
TB330XU_ROW_OPEN_USER_V14.218_T_ZUI_15.1.116_ST_240206
A csomagban lévő scatter fájl vizsgálata nem puszta formaság volt. A scatter mutatta meg, hogy a készülék egyes image-ei fizikailag melyik eMMC-területre tartoznak. A preloader bejegyzésénél egy különösen fontos részlet jelent meg:
partition_name: preloader file_name: preloader_barley_row_lte.bin region: EMMC_BOOT1_BOOT2 physical_start_addr: 0x0 partition_size: 0x80000
Ez a sor később az egész hibakeresés egyik kulcsa lett. A preloader nem a normál Android GPT-ben található boot_a partícióval azonos helyen van. A scatter kifejezetten az eMMC hardveres BOOT1/BOOT2 régiójára hivatkozott. Vagyis már ekkor látható volt, hogy a „boot” szó két teljesen különböző dolgot takarhat: az Android boot_a/boot_b partíciót és az eMMC saját BOOT1/BOOT2 hardveres területét.
A gyári preloader neve — preloader_barley_row_lte.bin — később a készülék saját boot régiójában is felismerhetővé vált, ami további kapaszkodót adott.

6. Az első teljes DA/DRAM/eMMC siker: áttörés, de még nem stabil állapot

A GPT első sikeres megjelenése pszichológiailag is nagy fordulat volt: addig a tablet belsejéről főként a BROM által közölt hardveradatokból következtettünk, innentől viszont már láthatóvá vált a tényleges partíciós térkép. Meg lehetett különböztetni a normál USER-area partíciókat, fel lehetett mérni a méreteket, és elkezdődhetett a mentési terv.
Ugyanakkor tudatosan nem tekintettük ezt végleges állapotnak. Ha egy újracsatlakozás után ismét a DRAM setup hibánál állt meg a folyamat, akkor az előző siker nem adott garanciát a következő műveletre. Ezért minden olyan alkalommal, amikor a GPT-ig eljutottunk, úgy kezeltük a sessiont, mintha nem tudnánk, mikor lesz a következő.
Később a felhasználói próbákból nagyjából tízből négy sikeres csatlakozás rajzolódott ki. Ez már sokkal jobb volt a kezdeti, szinte véletlenszerű sikerhez képest, de továbbra sem olyan stabilitás, amely mellett felelőtlenül lehetett volna hosszú írásokat indítani ellenőrzés nélkül.
A V14 preloader megadásával egy próbán végre átjutottunk azon a ponton, ahol korábban az EMI/DRAM inicializálás elbukott. A logban megjelent a várva várt „DRAM setup passed”, majd az eMMC azonosítása és végül a GPT-tábla.
DAXFlash - DRAM setup passed. DAXFlash - Sending emi data succeeded. DAXFlash - EMMC CID: d601034133413536321188c287209ac1 DAXFlash - Successfully uploaded stage 2 GPT Table: ... Total disk size: 0x0000001ccf000000
Ez volt az első alkalom, amikor a fekete kijelzős készülék belső tárhelyét már valódi partíciós szinten láttuk. A siker azonban félrevezető lehetett volna, ha azt feltételezzük, hogy a problémát megoldottuk. A következő csatlakozásokon ugyanaz a folyamat ismét el tudott akadni az EMI/DRAM szakaszban.
A következő órákban ezért nem a ROM visszaírása lett az elsődleges feladat, hanem a hozzáférés reprodukálhatóságának javítása. Ugyanazokat a gombkombinációkat, USB-csatlakoztatási sorrendet, preloader paramétert és parancsokat ismételtük, közben figyelve, melyik fázisig jut el a kapcsolat. A gyakorlatban külön kellett választani azt, hogy a Windows látja-e az eszközt, sikerül-e a BROM handshake, lefut-e az exploit, elindul-e a DA, átmegy-e az EMI/DRAM init, és végül elérhetővé válik-e az eMMC. Egyetlen „device detected” üzenet még korántsem jelentette az egész lánc sikerét.

7. Miért néztünk bele magába az MTKClient forráskódjába?

A diagnosztika egy ponton túl már nem volt megoldható kizárólag a konzolüzenetek olvasásával. Előfordult például, hogy a log „No preloader given” jellegű állapotot sugallt akkor is, amikor a parancssorban preloader paraméter szerepelt. Mivel a DRAM inicializálás pont ezen múlt, fontos lett megérteni, hogy az MTKClient különböző kódágai hogyan adják tovább a preloadert és melyik DA-példány használja.
Ezért a program forrását is átnéztük. A cél nem az volt, hogy saját MTKClientet írjunk, hanem hogy ne adjunk ki veszélyes írási parancsot addig, amíg nem értjük, hogy az adott parancs valójában melyik fizikai régiót és milyen módszerrel éri el. Ez a hozzáállás később a BOOT2 mentésnél konkrét hibát is megfogott.

8. Az USB-kábel kérdése: mellékszálból fontos kontrollteszt

A kábelcsere azért volt jó kontroll, mert nem változtatott sem a firmware-en, sem a preloaderen, sem az MTKClient kódján. Ha ugyanaz a szoftveres eljárás egy másik kábellel lényegesen megbízhatóbban fut, akkor a fizikai adatkapcsolat szerepe nem hagyható figyelmen kívül.
Az eredmény után sem írtuk át a teljes hibamodellt arra, hogy „rossz volt a kábel”. A tablet eredeti fekete állapotát a kábel nem okozhatta, hiszen a belső bootfolyamat USB nélkül is hibás volt. A kábel inkább azt magyarázta, miért volt a javításhoz szükséges alacsony szintű kapcsolat a kelleténél még kiszámíthatatlanabb.
Ez jól mutatja, hogy egy összetett helyreállításban több hiba vagy nehezítő körülmény egyszerre is jelen lehet: volt egy valódi bootlánc-probléma, miközben a diagnosztikai kommunikációt egy külön fizikai instabilitás is nehezíthette.
A kapcsolat kiszámíthatatlansága miatt felmerült az USB-kábel szerepe is. Ez elsőre banálisnak hangozhat, de BROM/DA kommunikációnál rövid, időzítésérzékeny adatváltás zajlik. Egy olyan kábel, amely normál fájlmásolásnál még elfogadhatónak tűnik, okozhat rövid hibát vagy újracsatlakozást éppen a kritikus inicializálási szakaszban.
A kábelcsere nem lett automatikusan „a megoldásnak” kikiáltva, mert a korábbi hibák sokszor ugyanazon az EMI ponton jelentkeztek. Viszont kontrollként új kábellel újrapróbáltuk a problémás folyamatokat. Az új kábellel a korábban bizonytalan DA/GPT hozzáférés elsőre végigment, majd több olvasási és írási művelet is sikerült. Ez erősen arra utalt, hogy a kommunikációs instabilitásnak fizikai összetevője is lehetett.
Fontos különbség: ez a kapcsolat stabilitását javította, de nem magyarázta meg önmagában, hogy miért maradt fekete a tablet. A kábel tehát a javítási folyamat egyik akadályát csökkentette; a készülék tartalmi bootproblémája ettől még megmaradt.

9. Mentés mindenekelőtt: a készülék saját állapotának megőrzése

A mentések nemcsak azért kellettek, hogy szükség esetén vissza lehessen állni. Összehasonlítási alapot is adtak. Egy gyári image és a készülékről kiolvasott fájl méretének, hashének vagy bináris tartalmának összevetése sokszor többet mondott, mint a fájlnév.
Különösen fontosak voltak az NV- és eszközspecifikus területek. Ezeket nem akartuk egy másik csomag általános tartalmával felülírni. A javítás célja a bootképesség visszaállítása volt, nem az, hogy a tablet saját kalibrációs vagy azonosító adatait szükségtelenül megváltoztassuk.
A mentési fegyelem később a BOOT1/BOOT2-nél fizetődött ki igazán. Mivel megvolt a teljes eredeti 4 MiB-os régió, a candidate image-et nem a semmiből kellett felépíteni, hanem a készülék saját struktúráját lehetett célzottan módosítani.
Amint sikerült használható eMMC-sessiont létrehozni, nem kezdtük el azonnal felülírni a készüléket. Mivel nem volt korábbi teljes backup, a saját tartalom lett az egyetlen visszaút. Ezért először a kritikus partíciók és egyedi területek mentése következett.
A mentési körbe bekerültek a bootlánc és AVB fontos elemei — boot_a, lk_a, dtbo_a, vendor_boot, init_boot, vbmeta és társai —, valamint az eszközspecifikus nvcfg, nvdata, nvram, persist, protect1, protect2, proinfo és seccfg területek. A super partíciót is külön kezeltük, mert ez tartalmazza a modern Android dinamikus system/vendor/product logikai partícióit.
A stratégia egyszerű volt: ahol csak lehetett, írás előtt olvasás; fontos írás után pedig readback vagy hash-ellenőrzés. A kapcsolat bizonytalansága miatt egy sikeres session alatt több kis mentést is egymás után készítettünk, hogy ne kelljen minden fájlért újra végigküzdeni a BROM → DA → DRAM láncot.

10. A készülék saját preloadere: az első konkrét tartalmi eltérés

Sikerült a készülék saját preloaderét is kimenteni. A fájlt összehasonlítottuk a V14 firmware gyári preloaderével. Már a méretük sem egyezett, és természetesen a SHA-256 hash is különbözött.
Fájl | Méret | SHA-256
• preloader_device.bin | 328 540 B | 4B76417034845CCCE4AC152FFDE0591F428B3F784CF8FFE22248E7A6E9CA60F7
• V14 preloader_barley_row_lte.bin | 323 740 B | FCAC9C52E257F8DAF08EB4970E08C00E4B011F07F777C8ADF252489DD6B82822
Ebből még nem lehetett azt mondani, hogy a készülék preloadere biztosan sérült. Elképzelhető lett volna más build, más verzió vagy más dumpolási környezet is. Viszont a helyreállításhoz használt V14 rendszer és a készülékben lévő korai bootkód között már volt egy kézzelfogható eltérés, amit érdemes volt tovább vizsgálni.
A következő logikus kérdés az lett: mi található valójában a teljes eMMC BOOT1 és BOOT2 hardveres régiókban? Ehhez azonban a klasszikus DA útvonal bizonytalansága miatt más módszerre volt szükség.

11. Stage2: kerülőút a teljes BOOT1/BOOT2 kiolvasásához

A Stage2 használata azért volt fontos, mert a normál DA útvonal instabilitása addig minden hosszabb művelet fölött ott lebegett. A cél itt kifejezetten az volt, hogy a hardveres boot régiókhoz olyan olvasási utat találjunk, amely nem ugyanazon a problémás ponton bukik el.
A 4 MiB-os BOOT1 sikeres kiolvasása után már nem kellett találgatni, hogy a rövid preloader dump hogyan helyezkedik el a teljes eMMC boot régióban. A teljes képben lehetett offseteket keresni, szignatúrákat azonosítani, és később olyan candidate-et készíteni, amely a régió többi részét érintetlenül hagyja.
Ettől a ponttól a javítás egyre kevésbé hasonlított hagyományos ROM-flashelésre. Inkább bináris forenzikus munkává vált: teljes régiók, offsetek, szignatúrák, hash-ek és különböző olvasási módszerek eredményei kerültek egymás mellé.
Az MTKClient Stage2 funkcióját kezdtük vizsgálni, mert ezzel a problémás klasszikus EMI/DRAM útvonal egy része megkerülhető volt. A stage payload ellenőrzésével voltak problémák, de verification nélkül a stage1 és stage2 betöltése sikerült.
Main - Successfully uploaded stage 1, sending stage 2 Main - Done sending stage2, size 0x4000. Main - Done jumping stage2 at 00201000 Main - Successfully loaded stage2
Ezután a BOOT1 teljes, 4 MiB-os tartalmát ki tudtuk olvasni:
python stage2.py preloader --start 0 --length 0x400000 --filename "C:\Users\Ragua\Desktop\TB330XU_backup\emmc_boot1.bin" Stage2 - Reading preloader... Progress: 100.0% (0x2000/0x2000) Done
A mentés mérete 4 194 304 bájt lett, SHA-256 értéke pedig:
E3DA72F409362A8603E3BC6D492483F9A888B5F2BD40F5EA4A58D89C4318A554
Ezzel először volt a kezünkben nem csupán egy kinyert preloader-részlet, hanem a teljes hardveres BOOT1 régió. Ez fontos különbség volt, mert így a környező struktúrát és az offseteket is vizsgálni lehetett.

12. Egy veszélyes eszközhiba felismerése: a stage2.py BOOT2 ága

A kódhiba felismerése különösen jó példa arra, miért nem kezeltük a használt szoftvert tévedhetetlen fekete dobozként. Ha a BOOT2 teljes mentését az explicit-length ággal változtatás nélkül futtatjuk, könnyen olyan fájlt kaphattunk volna, amely valójában a BOOT1-ből származik.
Mivel később a BOOT1 és BOOT2 ténylegesen azonosnak bizonyult, egy ilyen hiba ráadásul rejtve maradhatott volna: a végeredmény hihetőnek tűnik, miközben a mérés módszere hibás. Ezért volt fontos előbb a parttype viselkedést ellenőrizni, majd csak utána levonni következtetést a két régió azonosságáról.
A javított scriptet külön fájlban tartottuk. Ez lehetővé tette, hogy az eredeti eszköz változatlan maradjon, és pontosan visszakövethető legyen, melyik módosítás szolgálta a teljes BOOT2 olvasást.
A BOOT2 mentése előtt nem futtattuk vakon ugyanazt a parancsot más névvel. A stage2.py forráskódjának ellenőrzésekor kiderült, hogy a boot2() függvény két külön kódágában nem ugyanaz a parttype szerepel.
def boot2(self, start, length, filename): ... if sectors == 0: self.readflash(type_=2, start=0, length=0x40000, ...) else: self.readflash(type_=1, start=start, length=length, ...)
Ez azt jelentette, hogy explicit hosszúság megadásakor a program type_=1-et használhatott volna, vagyis jó eséllyel ismét BOOT1-et olvasunk úgy, hogy közben BOOT2-nek hisszük. Egy ilyen tévedés diagnosztikai szempontból különösen veszélyes: két azonosnak látszó dump alapján tévesen arra következtethettünk volna, hogy a két hardveres régió azonos.
Ezért először csak a biztos type_=2 ágat teszteltük kisebb olvasással, majd a script egy külön másolatában célzottan kijavítottuk az explicit hosszúságú BOOT2-ágat. Az eredeti fájlt érintetlenül hagytuk. Csak ezután készült el a teljes 4 MiB-os BOOT2 mentés.
A későbbi összehasonlítás végül valóban azt mutatta, hogy a teljes BOOT1 és BOOT2 bitazonos. A különbség azonban az volt, hogy ezt már helyesen címzett, külön-külön elvégzett olvasások bizonyították, nem egy potenciálisan hibás scriptből származó feltételezés.

13. Mi volt a BOOT1/BOOT2-ben? A korai bootkörnyezet boncolása

A teljes boot régiókban szignatúrákat és olvasható karakterláncokat kerestünk. A BOOT1-ben az MTK_BLOADER_INFO struktúra környékén közvetlenül megjelent a preloader neve.
00050010 ... 4D 54 4B 5F 00050020 42 4C 4F 41 44 45 52 5F 49 4E 46 4F 5F 76 34 30 MTK_BLOADER_INFO_v40 00050030 ... 70 72 65 6C 6F 61 64 65 72 preloader 00050040 5F 62 61 72 6C 65 79 5F 72 6F 77 5F 6C 74 65 2E _barley_row_lte. 00050050 62 69 6E ... bin
A vizsgálat megmutatta, hogy a boot régiók nem üresek és nem véletlenszerű szeméttel vannak tele. Strukturált MediaTek bootloader-környezetet tartalmaztak. Mindkét régióban ugyanazon a helyen megtalálható volt a készülékből kimentett, V14 gyári fájltól eltérő preloader-tartalom.
Ez fontos finomítás a „BOOT1/BOOT2 sérült” megfogalmazáshoz. A mentések nem klasszikus fizikai flashhibára utaltak. A BOOT1 és BOOT2 egymással konzisztens volt, és értelmes bootstruktúrát tartalmazott. A probléma inkább az lehetett, hogy ez a korai bootkód nem illett ahhoz a V14 rendszerhez, amelyet a USER-area helyreállításánál használtunk.

14. Előbb a normál Android-rendszert tettük rendbe

Ez a szakasz kívülről kevésbé látványos volt, mert minden sikeres írás után ugyanaz a fekete kijelző fogadott. Mégis szükséges volt: a későbbi BOOT1/BOOT2 teszt csak akkor értelmezhető, ha a mögötte lévő normál rendszer már egy ismert V14 állapothoz közelít.
Ha közvetlenül a hardveres boot régiókat javítjuk, miközben a boot_a, vbmeta, super vagy más kritikus komponens továbbra is korábbi, sérült vagy inkompatibilis állapotban van, akkor egy sikertelen bootból nem lehetett volna megmondani, melyik réteg a hibás. A fokozatos USER-area helyreállítás tehát a diagnózis tisztítását is szolgálta.
Minden olyan lépés, amely után a tablet továbbra is fekete maradt, szűkítette a hibateret. Ezért a „nem történt semmi” itt nem eredménytelen próbálkozást jelentett, hanem negatív teszteredményt.
Mielőtt a nagyobb kockázatú hardveres BOOT1/BOOT2 íráshoz nyúltunk volna, a normál eMMC USER-area több fontos komponensét fokozatosan V14 állapotra hoztuk. Ez tudatos sorrend volt: a GPT-partíciók írása jobban ismert és könnyebben visszaellenőrizhető, mint a hardveres boot régióké.
A helyreállítás során érintettük és/vagy ellenőriztük az AVB metaelemeket, a bootlánc kiegészítő partícióit, az A/B oldalak releváns elemeit, a boot, lk, dtbo, vendor_boot, init_boot családot, valamint a modem- és firmware-komponenseket. A nagy super partíció is visszakerült a V14 csomag szerinti állapotba.
python mtk.py w vbmeta_a,vbmeta_system_a,vbmeta_vendor_a ... python mtk.py w md1img_a,spmfw_a,scp_a,sspm_a,gz_a,dtbo_a,tee_a ... python mtk.py w super "$env:USERPROFILE\Desktop\TB330XU_backup\super_V14_raw.img"
A super írása különösen hosszú és nagy volumenű művelet volt, mert ezen belül található a modern Android dinamikus system/vendor/product tartalma. A logo, Lenovo-specifikus területek és userdata is a helyreállítási folyamat része lett.
A lényeg azonban az eredmény volt: a jelentős USER-area helyreállítás után a tablet továbbra is fekete maradt. Ez diagnosztikailag legalább olyan értékes információ volt, mint egy sikeres boot lett volna. Azt mutatta, hogy önmagában a normál Android-partíciók rendbetétele nem elég.

15. A gyanú egyre inkább a GPT-n kívüli BOOT1/BOOT2 felé terelődött

Ekkorra több, egymást erősítő tény állt rendelkezésre. A SoC BROM-ja működött. A V14 preloader segítségével a DA képes volt az eMMC-t elérni. A normál USER-area sok kritikus eleme V14-re került, de kijelzős boot nem jelent meg. A scatter szerint a preloader fizikailag EMMC_BOOT1_BOOT2 területen van. A készülék saját preloader-tartalma pedig eltért a V14 gyári fájltól.
Ez már nem általános találgatás volt, hanem tesztelhető hipotézis: lehet, hogy a korábbi flashelés után a USER-area és a hardveres boot régiók nem ugyanahhoz a firmware-állapothoz tartoznak. Ha a BROM után betöltődő preloader nem kompatibilis a későbbi bootlánccal, akkor a készülék már jóval azelőtt elakadhat, hogy a boot_a vagy a system egyáltalán szerephez jutna.
A hipotézis mellett szólt az is, hogy a BOOT1 és BOOT2 egymással azonos, strukturált tartalmú volt, tehát nem egyszerűen egyetlen régió véletlenszerű korrupciójáról beszéltünk. A helyreállítás célja ezért nem az lett, hogy „nullázzuk” vagy formázzuk ezeket a régiókat, hanem hogy a meglévő szerkezetet megőrizve a V14 preloaderrel konzisztens állapotot készítsünk.

16. V14 candidate image-ek: kontrollált javítás a teljes régió felülírása helyett

A candidate-ek elkészítésekor külön figyelmet kapott az a tény, hogy a készülékből kimentett preloader hosszabb volt a V14 fájlnál. Ha csak az új, rövidebb fájlt írjuk rá a régi helyére, a korábbi tartalom vége a régióban maradhatott volna. Ezért a releváns maradványterület nullázása szándékos része volt az offline előkészítésnek.
Mielőtt bármilyen írás történt, magukat a candidate fájlokat is ellenőriztük. Nemcsak a végső SHA-256 érték számított, hanem az is, hogy a V14 preloader a kívánt offseten ténylegesen megtalálható-e, és hogy a módosítás nem érinti-e a régió szükségtelen részeit.
Ezzel az írási kockázatot két részre bontottuk: először teljesen offline, a PC-n bizonyítottuk, hogy a létrehozott image olyan, amilyennek szántuk; csak ezután kellett azt bizonyítani, hogy az MTKClient a megfelelő fizikai helyre írja.
A gyári preloader mindössze 323 740 bájtos volt, miközben egy teljes eMMC boot régió 4 MiB. Ebből következett, hogy veszélyes lenne a rövid preloader fájlt egyszerűen teljes 4 MiB-os image-ként kezelni. Offline candidate image-eket készítettünk a készülék saját, teljes BOOT1 és BOOT2 mentéseiből.
A candidate készítésénél a V14 gyári preloader a megállapított helyre került, a régi, hosszabb preloader után esetlegesen megmaradó releváns tail területet nulláztuk, a boot régió többi részét pedig megtartottuk. Így nem egy teljesen mesterséges 4 MiB-os fájlt írtunk, hanem a készülék saját struktúrájából kiinduló, célzottan módosított képet.
Candidate | Méret | SHA-256
• emmc_boot1_V14_candidate.bin | 4 194 304 B | A0745DCBBB806FB59B65DA6F649A522868D4F3A13A852845664FB1D0E80E2D5B
• emmc_boot2_V14_candidate.bin | 4 194 304 B | A0745DCBBB806FB59B65DA6F649A522868D4F3A13A852845664FB1D0E80E2D5B
Az offline ellenőrzés szerint mindkét candidate-ben a V14 preloader pontosan a kívánt helyen szerepelt, a régi hosszabb rész maradványterülete nullázva volt, és a két candidate egymással is azonos lett.

17. Írás előtt még egyszer bizonyítottuk a fizikai címzést

A BOOT1/BOOT2 írás olyan művelet, amelynél egy rossz parttype vagy offset újabb brick-et okozhat. Ezért a korábbi Stage2 mentésre nem hagyatkoztunk önmagában. Az MTKClient normál raw olvasási parancsával külön ellenőriztük, hogy a --parttype boot1 és a 0x0–0x400000 tartomány valóban ugyanazt a teljes 4 MiB-os régiót adja vissza.
python mtk.py ro 0x0 0x400000 "$env:USERPROFILE\Desktop\TB330XU_backup\boot1_ro_test.bin" --parttype boot1
Az új raw olvasást SHA-256-tal és byte-for-byte összehasonlítással vetettük össze a korábbi emmc_boot1.bin mentéssel. Az egyezés igazolta a címzést. Ez volt az a pont, amikor már nemcsak elméletileg hittük, hogy jó helyre fogunk írni, hanem ugyanarról a helyről két külön módszerrel azonos adatot kaptunk.

18. A döntő nap: először csak BOOT1

A BOOT1 írás előtti óvatosság nem volt túlzás. Ezen a ponton már több nap munkája, számos mentés és egy működő BROM-visszaút állt mögöttünk; egy hibás raw írással ezt az állapotot is rosszabbá lehetett volna tenni.
Az írás után ezért a következő művelet nem reboot, hanem readback volt. A cél az volt, hogy a készülék viselkedésének megfigyelése előtt magát a tárolási műveletet bizonyítsuk. Ha a readback eltér, akkor nincs értelme a booteredményből következtetni.
A byte-for-byte egyezés után először lehetett nagy bizonyossággal kijelenteni, hogy a BOOT1 fizikai régiója pontosan a tervezett V14 candidate-et tartalmazza. Ez adta meg a szakmai alapot a BOOT2 módosításához.
A tényleges helyreállítást szándékosan két lépcsőre bontottuk. Nem írtuk egyszerre a BOOT1-et és a BOOT2-t. Először kizárólag a BOOT1 kapta meg a V14 candidate image-et, miközben a BOOT2 változatlan maradt. Ennek célja az volt, hogy ha az írás vagy a címzés hibás, legalább az egyik eredeti boot régió megmaradjon.
python mtk.py wo 0x0 0x400000 ` "$env:USERPROFILE\Desktop\TB330XU_backup\emmc_boot1_V14_candidate.bin" ` --parttype boot1
Az írás után nem indítottuk azonnal a következő lépést. Új sessionben a teljes 4 MiB-os BOOT1-et visszaolvastuk.
python mtk.py ro 0x0 0x400000 ` "$env:USERPROFILE\Desktop\TB330XU_backup\boot1_after_V14.bin" ` --parttype boot1
A readback teljesen sikerült, majd offline összehasonlítás következett. Az eredmény nem „nagyjából egyezett”, hanem bitre pontos volt:
BYTE-FOR-BYTE MATCH: True Expected SHA256: A0745DCBBB806FB59B65DA6F649A522868D4F3A13A852845664FB1D0E80E2D5B
Ez volt az egyik legfontosabb biztonsági ellenőrzés az egész javításban. Bizonyította, hogy az MTKClient a kívánt 4 MiB-os BOOT1 régióba írta a candidate-et, és a tároló visszaolvasva pontosan azt tartalmazta, amit terveztünk.

19. BOOT2: az a lépés, amely után először felgyulladt a kijelző

A recovery megjelenése azért volt drámai fordulat, mert addig a javítás minden visszajelzése a számítógép képernyőjén jelent meg. A tablet saját kijelzője napok óta semmilyen állapotot nem mutatott. Most először maga a készülék jelezte, hogy a korai bootlánc már végigjutott a kijelző inicializálásáig és a recovery betöltéséig.
Ezzel egyben megváltozott a hibakeresés szintje is. Már nem az volt a kérdés, hogy a BROM eléri-e az eMMC-t, hanem az, hogy a helyreállított rendszer milyen felhasználói állapotból tud normál Androidot indítani. A hardveres boot régiók javítása tehát nemcsak egy hashben látszott, hanem közvetlen funkcionális eredményt adott.
A tervezett BOOT2 readback elmaradása ebben a konkrét pillanatban nem azért történt, mert figyelmen kívül hagytuk volna az ellenőrzést, hanem mert a készülék a csatlakoztatási próbán már továbbbootolt a recoverybe. A BOOT1-nél elvégzett teljes readback és a recovery megjelenése együtt adta a szükséges bizalmat a továbblépéshez.
Csak a BOOT1 sikeres, bitpontos visszaellenőrzése után következett a BOOT2. Ugyanazt a V14 candidate image-et írtuk a második hardveres boot régióba.
python mtk.py wo 0x0 0x400000 ` "$env:USERPROFILE\Desktop\TB330XU_backup\emmc_boot2_V14_candidate.bin" ` --parttype boot2
A következő terv az lett volna, hogy a BOOT2-ről is készítünk teljes readbacket, ugyanúgy, ahogy a BOOT1-nél. A valóság azonban megelőzte az ellenőrző tervet. A következő csatlakoztatáskor a Windows csatlakozási hangja többször fel-le váltott, majd történt valami, ami addig egyetlen alkalommal sem: a tablet kijelzője bekapcsolt.
Nem normál Android fogadott, hanem Android Recovery. Ez még nem jelentette azt, hogy minden rendben van, de a több napos teljes feketeség után óriási diagnosztikai fordulat volt. A készülék már eljutott egy magasabb bootfázisig, inicializálta a kijelzőt, és használható recovery környezetet indított.
Miért különösen erős bizonyíték ez? / A normál USER-area jelentős részét korábban már V14-re állítottuk, és a tablet akkor még fekete maradt. A kijelzős recovery közvetlenül azután jelent meg, hogy a két hardveres BOOT régió is V14-kompatibilis preloader-környezetet kapott. Ez nem matematikai bizonyítás arra, hogy kizárólag a BOOT1/BOOT2 volt hibás, de a teljes eseménysor legerősebb oksági jele.

20. Recoveryből a gyári Androidig

A recovery jelenléte még egy utolsó fontos különbséget tett láthatóvá: a bootlánc már működött, de a userdata és a helyreállított rendszer állapota nem feltétlenül volt konzisztens. A korábbi flashelések és a több komponensből álló V14 visszaállítás után ez várható helyzet volt.
A factory data reset ezért nem „hátha segít” jellegű próbálkozás volt. Az adatok megőrzése nem volt cél, és a reset tiszta felhasználói adatpartíciót adott a már helyreállított rendszernek. Ezután következett az a boot, amely végleg elválasztotta a diagnosztikai fázist a sikeres helyreállítástól.
Amikor megjelent a normál Lenovo rendszer, az több egymástól független korábbi eredményt igazolt egyszerre: működött a kijelző és a hardver, a korai MediaTek bootlánc, az Android bootkomponensek, a V14 super tartalma és az újonnan inicializált userdata.
A recovery megjelenése után már nem alacsony szintű BROM-eszközként kellett kezelni a tabletet. A rendszer „Try again” és „Factory data reset” lehetőséget kínált. Mivel a készüléken lévő felhasználói adatok megőrzése nem volt követelmény, a factory reset elfogadható és logikus következő lépés volt.
A törlés lefutott, majd a tablet újraindult. Ezúttal már nem fekete kijelző, nem rövid USB-enumeráció és nem BROM-log következett, hanem a Lenovo gyári Android rendszere. 2026. szeptember 26-án, nagyjából négy napnyi diagnosztika, sikertelen csatlakozások, mentések, összehasonlítások és célzott helyreállítás után megtörtént az első normál boot.
„Lefutott, és betöltött a rendszer normálisan! :)”

21. Mi okozhatta a fekete kijelzős állapotot?

A teljes munkafolyamat alapján a legfontosabb hibakomponens a korai bootkörnyezet és azon belül az eMMC BOOT1/BOOT2 régiók preloader-tartalma volt. Ezt azonban érdemes pontosan megfogalmazni. A mentett BOOT1/BOOT2 nem volt üres, nem látszott véletlenszerűen szétesett adatnak, és a két régió egymással bitazonos volt. Vagyis a „BOOT1/BOOT2 sérült” hétköznapi megfogalmazás mögött nem bizonyított fizikai eMMC-hiba állt.
A bizonyított tény az, hogy a két boot régióban lévő preloader eltért a helyreállításhoz használt V14 gyári preloaderétől. Közben a USER-area rendszerét fokozatosan V14 állapotra hoztuk. Ez olyan inkonzisztens bootláncot hozhatott létre vagy tarthatott fenn, amelyben a BROM még működött, de az utána következő korai bootkód nem jutott el odáig, hogy képet adjon vagy elindítsa a normál rendszert.
A legerősebb eseménysor a következő: a BROM már a legelején elérhető volt; a normál Android-partíciók jelentős V14-helyreállítása után a kijelző továbbra is fekete maradt; a BOOT1 V14 candidate írása bitre pontosan sikerült; a BOOT2 V14 candidate írása után pedig közvetlenül Android Recovery jelent meg. Factory reset után a V14 gyári rendszer elindult.
Ezért szakmailag pontosabb azt mondani, hogy a helyreállítás szempontjából a döntő probléma a BOOT1/BOOT2-ben lévő preloader és a helyreállított V14 rendszer közötti tartalmi/verziós inkonzisztencia volt. Nem zárható ki, hogy a korábbi flashelés a USER-area több komponensét is érintette; sőt, azért kellett azokat is helyreállítani. A BOOT1/BOOT2 azonban az a komponens volt, amelynek rendezése nélkül a korábbi lépések után sem jelent meg kijelzős boot.

22. Mit tanított ez a javítás?

A fekete kijelző nem egyenlő a hardverhalállal. MediaTek eszköznél a SoC-ba égetett BROM akkor is működhet, amikor a preloader vagy az Android teljesen használhatatlan. Az USB-enumeráció ezért létfontosságú diagnosztikai jel.
A kapcsolat felépülése több külön fázisból áll. Windows-eszközfelismerés, BROM handshake, exploit, DA stage 1, EMI/DRAM init, DA stage 2 és eMMC/GPT hozzáférés külön-külön is elbukhat. Egyetlen sikeres „device detected” nem jelenti, hogy már írható a tárhely.
A reprodukálhatóság önálló probléma lehet. Ebben az esetben az első BROM/DA sikert hosszú ideig nem tudtuk megbízhatóan megismételni. A gombidőzítés, USB-kapcsolat, kábel és preloader-paraméter egyaránt számított.
Az Android boot_a és az eMMC BOOT1 nem ugyanaz. A név hasonlósága megtévesztő. A boot_a GPT-partíció; a BOOT1/BOOT2 az eMMC külön hardveres régiója. A preloader itt, a GPT-n kívül is lehet.
Mentés nélkül nem érdemes nagy kockázatú írást kezdeni. A saját preloader, a teljes BOOT1/BOOT2 és az egyedi NV-területek mentése tette lehetővé, hogy minden lépésnél legyen összehasonlítási és visszaállítási alap.
A használt eszköz forráskódját is érdemes ellenőrizni. A stage2.py BOOT2 explicit-length ágában talált type_=1 viselkedés konkrét példája annak, hogy egy diagnosztikai eszköz sem tévedhetetlen.
A readback nem luxus. A BOOT1 candidate írása után a teljes 4 MiB-os visszaolvasás és byte-for-byte egyezés adta meg azt a bizonyosságot, amely után a BOOT2-höz is hozzá mertünk nyúlni.

23. A helyreállítás összefoglaló idővonala

Időszak | Fő esemény
• 2026. szeptember 22. | A tablet teljesen fekete. USB-események és gombkombinációk vizsgálata; az első MediaTek/BROM életjelek keresése.
• 2026. szeptember 22–23. | Ismételt handshake-hibák, alkalmi BROM-siker; Kamakiri payload és DA stage 1 elérés, majd DRAM/EMI elakadás.
• 2026. szeptember 23–24. | V14 firmware és preloader azonosítása; első teljes DRAM/eMMC/GPT siker, de a kapcsolat továbbra is kiszámíthatatlan. MTKClient-kód és USB-kapcsolat vizsgálata.
• 2026. szeptember 24–25. | Kritikus partíciók és egyedi területek mentése. Saját preloader kinyerése, BOOT1/BOOT2 teljes mentésének kidolgozása Stage2-vel.
• 2026. szeptember 25. | A stage2.py BOOT2 kódágának hibája felismerve és biztonságosan megkerülve. BOOT1/BOOT2 tartalomelemzés; V14-től eltérő preloader azonosítása.
• 2026. szeptember 25–26. | USER-area V14 komponenseinek fokozatos visszaállítása és ellenőrzése. A tablet még mindig fekete, ezért a gyanú a hardveres boot régiókra koncentrálódik.
• 2026. szeptember 26. | V14 BOOT1/BOOT2 candidate-ek elkészítése. Raw címzés külön bizonyítása. BOOT1 írás + teljes readback + byte-for-byte egyezés.
• 2026. szeptember 26. | BOOT2 írás után a kijelző először életre kel, Android Recovery indul. Factory data reset után a gyári Android normálisan betölt.

24. Kritikus fájlok és ellenőrző hash-ek

25. Záró megállapítás

A TB330XU helyreállítása azért volt különösen tanulságos, mert nem egyetlen látványos flash-parancs oldotta meg. A tényleges munka nagy része a fekete képernyő mögött zajlott: először meg kellett találni az alig észrevehető USB-életjelet, majd az egyszer sikerült BROM-kapcsolatot újra és újra előidézni, átjutni a biztonsági és DA-rétegen, megérteni az EMI/DRAM hibát, menteni a készülék saját állapotát, és végül elkülöníteni egymástól a normál Android-partíciókat és az eMMC hardveres boot régióit.
A fordulat akkor következett be, amikor a javítás már nem általános „ROM-flashelésként”, hanem egy bootlánc rétegenkénti vizsgálataként folyt. A USER-area helyreállítása után is fekete készülék, a V14-től eltérő BOOT1/BOOT2 preloader, majd a candidate-ek kontrollált írása és a BOOT2 után megjelenő recovery együtt adja azt a történetet, amelyből a hiba valódi helye visszakövethető.
A végeredmény: a teljesen fekete, látszólag élettelen Lenovo Tab M11 ismét eljutott a gyári recoveryig, majd factory reset után normálisan betöltötte a Lenovo Android rendszert. A javítás során készült mentések, hash-ek és readbackek miatt a siker nem pusztán szerencsés próbálkozásként, hanem dokumentált és műszakilag ellenőrzött helyreállításként értékelhető.

26. Műveleti parancsjegyzék – mit mire használtunk?

Ez a fejezet nem a beszélgetés időrendi másolata, hanem a helyreállítás során ténylegesen használt parancstípusok műszaki összefoglalója. Célja, hogy hónapokkal később is gyorsan visszakereshető legyen, melyik eszközt milyen feladatra használtuk, és az adott parancs eredményéből mire következtettünk.

Windows USB/PnP megfigyelés

pnputil /enum-devices /connected /ids pnputil /enum-devices /connected /ids | Select-String -Context 5,5 "MediaTek" pnputil /enum-devices /connected /ids | Select-String -Context 5,5 "VID_0E8D"
A fekete kijelzős állapotban ezzel kerestük a rövid időre feljelentkező MediaTek USB-eszközt. Ez nem flashelt semmit; kizárólag azt segített eldönteni, hogy a tablet egyáltalán enumerál-e a PC felé.

MTKClient normál BROM/DA műveletek

python mtk.py ... # a tényleges művelettől függően r / w / ro / wo / printgpt stb. # a V14 preloader megadásával, amikor a DRAM inicializáláshoz szükséges volt
A normál MTKClient útvonalon történt a GPT és a USER-area partíciók jelentős részének olvasása/írása. A kritikus pont az volt, hogy a BROM handshake után a DA-nak az EMI/DRAM inicializáláson is át kellett jutnia.

USER-area partíciók mentése

python mtk.py r dtbo_a ...\dtbo_a_current.bin python mtk.py r boot_a ...\boot_a_current.bin python mtk.py r lk_a ...\lk_a_current.bin python mtk.py r vendor_boot_a ...\vendor_boot_a_current.bin python mtk.py r init_boot_a ...\init_boot_a_current.bin python mtk.py r super ...\super_current.bin
A készülék aktuális állapotának megőrzésére és a gyári V14 fájlokkal történő későbbi összehasonlításra szolgáltak. A tényleges mentési kör ennél szélesebb volt; külön NV- és AVB-területek is készültek.

Stage2 betöltése

python mtk.py stage --stage2 "...\payloads\stage2.bin" --filename "...\payloads\generic_stage1_payload.bin"
A klasszikus DA/EMI útvonal bizonytalansága mellett ezzel hoztunk létre olyan Stage2 környezetet, amelyből a hardveres boot régiók teljes tartalma olvashatóvá vált.

BOOT1 teljes mentése Stage2-vel

python stage2.py preloader --start 0 --length 0x400000 --filename "C:\Users\Ragua\Desktop\TB330XU_backup\emmc_boot1.bin"
A teljes 4 MiB-os eMMC BOOT1 régió mentése. Ez lett a későbbi bináris elemzés és a V14 candidate egyik kiindulási alapja.

BOOT2 teljes mentése

A BOOT2-höz a stage2.py explicit-length ágát külön ellenőriztük, mert a forrásban type_=1 szerepelt ott, ahol type_=2 volt szükséges. A javított kód külön másolatban futott.
A lényeg nem egyetlen parancssor, hanem az, hogy a BOOT2 teljes dumpja csak a parttype logika ellenőrzése után készült. Így az eredmény valóban külön BOOT2-olvasásból származott.

BOOT1 raw címzés kontrollolvasása

python mtk.py ro 0x0 0x400000 "$env:USERPROFILE\Desktop\TB330XU_backup\boot1_ro_test.bin" --parttype boot1
Ezzel bizonyítottuk, hogy az MTKClient raw boot1 címzése ugyanazt a teljes 4 MiB-os régiót adja, mint a korábbi Stage2 mentés. Ez volt a közvetlen előfeltétele a raw írásnak.

BOOT1 V14 candidate írása és readbackje

python mtk.py wo 0x0 0x400000 "$env:USERPROFILE\Desktop\TB330XU_backup\emmc_boot1_V14_candidate.bin" --parttype boot1 python mtk.py ro 0x0 0x400000 "$env:USERPROFILE\Desktop\TB330XU_backup\boot1_after_V14.bin" --parttype boot1
Az első parancs írta a BOOT1-et; a második a teljes régiót visszaolvasta. Az offline összehasonlítás BYTE-FOR-BYTE MATCH: True eredményt adott.

BOOT2 V14 candidate írása

python mtk.py wo 0x0 0x400000 "$env:USERPROFILE\Desktop\TB330XU_backup\emmc_boot2_V14_candidate.bin" --parttype boot2
A BOOT1 sikeres readbackje után következett. A következő csatlakoztatásnál a tablet Android Recoverybe jutott; ez volt az első kijelzős boot a javítás kezdete óta.

27. Biztonsági és ellenőrzési lánc – mi akadályozta meg, hogy találomra flasheljünk?

Azonosítás írás előtt: A készülék pontos modellje, a V14 ROW firmware, a preloader fájl és a scatter régióbejegyzése külön ellenőrzést kapott. A preloader esetében különösen fontos volt az EMMC_BOOT1_BOOT2 megjelölés.
Saját tartalom mentése: A javítás során nem feltételeztük, hogy a gyári csomag minden egyedi adatot pótol. A kritikus USER-area és NV-területek, valamint a teljes BOOT1/BOOT2 mentése még a nagy kockázatú írások előtt megtörtént.
Külön olvasási módszerek összevetése: A BOOT1-et Stage2-ből és később az MTKClient raw boot1 útvonalán is kiolvastuk. Az egyezés nemcsak a fájlt, hanem a fizikai címzés értelmezését is ellenőrizte.
Eszközforrás ellenőrzése: A stage2.py BOOT2 kódágának vizsgálata megakadályozta, hogy egy potenciálisan rosszul címzett olvasást helyes BOOT2 dumpnak tekintsünk.
Offline candidate-ellenőrzés: A BOOT1/BOOT2 candidate-eket még a PC-n ellenőriztük: méret, V14 preloader elhelyezkedése, nullázandó tail-terület és SHA-256. A készülékre csak ezután kerültek.
Egy régió egyszerre: A BOOT1 és BOOT2 nem egyszerre lett felülírva. Először BOOT1 készült el, majd teljes readback és byte-for-byte ellenőrzés következett. Csak ezután írtuk a BOOT2-t.
Funkcionális ellenőrzés: A recovery megjelenése azt bizonyította, hogy a helyreállítás nem csupán fájlszinten sikerült. A bootlánc ténylegesen eljutott a kijelző inicializálásáig és az Android recovery környezetig.
Tiszta felhasználói állapot: A factory data reset után a helyreállított rendszer új userdata állapotból indult. A normál Lenovo Android bootja lett a javítás végső funkcionális ellenőrzése.

28. Mit érdemes megőrizni a helyreállítás után?

A javítás után a legértékesebb eredmény nemcsak a működő tablet, hanem a létrejött mentéskészlet. A teljes projekt későbbi visszakövethetőségéhez érdemes változatlanul megőrizni az eredeti készülék-dumpokat, a V14 referenciafájlokat, a candidate image-eket és az írás utáni readbackeket. Ezek együtt teszik lehetővé, hogy később egy újabb módosításnál pontosan tudjuk, mi volt a működő kiindulási állapot.
Különösen fontos az eredeti emmc_boot1.bin és emmc_boot2.bin, a V14 candidate-ek, a boot1_after_V14 readback, a készülék saját preloader dumpja, valamint az egyedi NV/seccfg/persist/protect mentések megőrzése. A fájlnevek önmagukban nem elegendők; a dokumentumban rögzített SHA-256 értékek segítenek később ellenőrizni, hogy ugyanarról a változatlan fájlról van-e szó.
A mentéskészletet célszerű legalább két külön fizikai adathordozón tárolni. Egy ilyen, nehezen reprodukálható BROM-helyreállítás után az eredeti dumpok elvesztése azt jelentené, hogy egy későbbi probléma esetén ismét a nulláról kellene felépíteni a diagnosztikát.