- Google Pixel topik
- iPhone topik
- Megérkezett a Google Pixel 7 és 7 Pro
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Egy szenzor, két zoomkamera: újraírta a Huawei a mobilfotózás történetét
- Poco M3 - felújított állomás
- Térerő gondok, tapasztalatok
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Milyen okostelefont vegyek?
- Honor Magic6 Pro - kör közepén számok
-
Mobilarena
Android dual SIM szakmai mélyvíz
Az alábbi témák kitárgyalása kerülendő, mert nem ide tartozik!
Kérdésed a megfelelő topikba tedd fel:
"melyik alkalmazás, ami"
"milyen tokot vegyek"
"piros hátlap hol kapható" "honnan vegyek telefont"
Új hozzászólás Aktív témák
-
-
-
#5751
cappa72
nagyúr
aytukabozs
#5750
válasz
aytukabozs
#5750
üzenetére
A meta mode régebben úgy volt elérhető, hogy akár nem is látszódott a telefonon.
Ahány gyártó és telefon, annyi módon volt "indítható".Amennyiben működött a telefon, és úgy akartál meta mode-ba menni, akkor pl. egy lenovo esetén a hangerő le (vagy fel) + power gombot kellett nyomva tartani, és kiírta, hogy "... is in meta mode"
Azonban volt olyan, amikor kukafon volt, és akkor a flashtool flas-indítása után nem csak simán összedugta az ember a kábellel a gépet a telefonnal, hanem nyomni kellett a hangerő le gombot (talán), és úgy meg lehetett flesselni a tetszhalott telefont, és szerencsé esetben életre kelt (asszem' Lenovo S820-at keltettem ífy életre).
Sajna régebbről volt olyan lehetőség, hogy megnézi az ember, hogy az emmc írható-e.
A régi flashtool-okban volt olyan, hogy write memory. Ott adott címtől lehetett írni, praktikusan egy recovery-vel kisérletezgettem. Persze ehhez tudni kell a korrekt recovery kezdőcímet. Link
Sajna hogy ez mostanság működik-e... passz. Remélem Keeperv85
most is képben van. -
#5748
cappa72
nagyúr
aytukabozs
#5747
válasz
aytukabozs
#5747
üzenetére
Már rég volt ugyan, de mtk esetén meghagyták a meta-mode-ot?
Egy próbát megérne kipróbálni. -
Ha teljes rom-szakaszról van szó, akkor vagy flashtool-lal, vagy szkript-tel mod recovery-ből, vagy ha van root, akkor adb-n keresztül dd parancs segítségével.
-
válasz
Smile8822
#5708
üzenetére
Alapvetően ez a topik "mélyvíz", tehát nem foglalkozik a telefonokról alkotott véleményekkel.
Itt a root, a flash, a readback, a cwm, twrp, rendszervisszaállítás, félhullák felélesztésének kísérletei és hasonlók az alaptéma.
Véleményekről itt kérdezz. -
Ha kijelzőcsere játszik, akkor az az egyik megoldás.
Ha kijelzőcsere nem játszik, és MTK alapú a telefon, akkor a data partíciót lementve és az img-be belenézve megtalálható a contacts.db és mmssms.db adatbázisfájlok.
Elméeltileg az alábbi helyen találhatóak:
Contacts = /data/data/com.android.providers.contacts/databases/contacts.db
SMS = /data/data/com.android.providers.telephony/databases/mmssms.db -
#5653
cappa72
nagyúr
ruszi_tomi
#5652
válasz
ruszi_tomi
#5652
üzenetére
Nem kételkedem benne, hogy van.
Csak azt írtam, hogy MTK alapú telefonok esetén van (illetve jellemzően szokott lenni) egy másik speciális mód. -
#5650
cappa72
nagyúr
ruszi_tomi
#5645
válasz
ruszi_tomi
#5645
üzenetére
Nézd meg, hogy milyen hardverrel van pontosan.
Ehhez nagy segítség az adb és a parancssor.
Adb-n keresztül telepíteni is lehet, és nem kell play áruházIlletve még a recovery-n kívül esetleg van-e factory mode (ez hasonló billentyűkombinációval érhető el, mint a recovery, de míg egy recovery hangerő fel+power, addig ez hangerő le+power - de ez csak példa.) - ez jellemzően MTK alapú gépeknél fordul elő.
Nem javaslom elsőre a mindenféle root megoldást - osztszoroz-zal ellentétben. A king-, kingo-, kengu-, i- és ilyesmi root-ok rút véget érhetnek. Kap az ember ajándékba valami oda nem illő programokat telepítő vackot.
-
Biztos vagy ebben?
MKT-s cuccok esetén ha a recovery alatt no command és zölt dobot van, akkor előfordul, hogy a tényleges recovery "előcsarnokában" van a telefon, és egy ismételt power+hangerő fel gombkombinációt megnyomva belép a tényleges recovery-be, ami már onnantól használhatóvá válik.
Sajna nem minden esetben van így, telefon/gyártófüggő... -
válasz
mikk2000
#5588
üzenetére
Szia!
Igen, azt már korábban is észrevettem hogy a GUI-kat nem komázod, de a világ errefelé halad jó ideje. Egy GUI-s program sem a kisujjából szopja ki egyébként egy partíció méretét
Nincs semmi baj a gui-kal, csak ki tudja, melyik információt mivel osztja, szorozza./system 869.6M 442.5M 427.1M 4096
android 0x0000000040000000 0x00000010 1 /dev/mtd/mtd16 USER
31 16 1048576 mtdblock16Hm... ilyen eltérést még nem láttam.
Az is igaz, hogy mtd/ubifs eszköz talán az a bizonyos nehéz root-os volt nálam egyedül, ilyeneket nem néztem meg.
Szóval ez nekem új, teljes hiányosság részemről. -
válasz
mikk2000
#5586
üzenetére
Nem jól értelmezed.
Így reális az 1GB-os partíción 869MB szabad.
Ettől még a partíció mérete 1GB, a 869 a diskinfo által írt méret amit felejts el.Szóval 1GB-os a system partíció, ez biztos. A diskinfo meg 869-nek látja ezt. Na itt volt az elcsúszás.
Tehát adatok:
diskinfo:
- méret: 869MB
- foglalt: 434MB/proc/partitions
- méret: 1GB
df
- foglaltság: még nem ismert.
Erre koncentrájl mármint a Linux (mert az Android is Linux kernelen alapul) / Android parancsok kimenetére.Tehát egy
dfparancs kimenete pontosabb és korrekt eredményt ad, szemben a diskinfo-val. -
Ha jól láttam, akkor így fogalmazott:
Szóval ő csak 869MB-osnak látja a System partíciót összesen. Hova tűnik a maradék? A gyári updatében a Sytem image 400MB, tehát elvileg ennyi elég kéne legyen neki (na meg mondjuk 100MB tartalék)
A system img itt simg.
A nagy kérdés, hogy amit leírtam két parancs, annak mi a kimenete.
Mert ez lenne a tényleges korrekt összevetés: tuduk mekkora (partitions), tudjuk mennyire foglalt (df).
Minen más addig csak feltételezés.
( Partitions konkrétan 1GB-ot mutat a system-re), a 869 nem t'om honnan jön - ja de... diskinfo. én az ilyen grafikus cuccokat valahogy ilyen esetekben nem szeretem, mert GiB vagy GB nem mindegy...szerk.: Szóval 1GB-os a system partíció, ez biztos. A diskinfo meg 869-nek látja ezt. Na itt volt az elcsúszás.
Tehát adatok:
diskinfo:
- méret: 869MB
- foglalt: 434MB/proc/partitions
- méret: 1GB
df
- foglaltság: még nem ismert.A diskinfonál tényleg látszik, hogy kb 50% kihasználtságú. Ebből a programból csak ezt az infót lehet kiszedni, átparticionáláshoz ebből a programból semmit nem vennék át.
Tehát ha egy 550MB-ospartíción lenne a system, akkor akár rá is férhet biztonsággal.
Sajna az img-t már letörötltem, nem tudom a flesselhető romban mekkora a tényleges img méret.Tehát ha a scatter-t átszámolja, minden partíció marad az eredeti sorszámán, csak a mérete változik, akkor egy fw upgrade átparticionálja a telefont, így a data ~450MB-tal nagyob lesz. Elméletileg.
-
Na de ha 890MB a system, akkor 500MB-os partícióra nem fog ráférni a rendszer.
Amúgy meg ha a scatter-t átírja, majd szerez egy olyan img-t ami nem nagyobb 500MB-nál, akkor firmware upgrade esetné a flastool elvégzi a szükséges műveleteket.
Jaja...ext4-nél egész egyszerű... (csak példa)
dd if=/dev/zero of=~/theFile.img bs=1M count=10240
mkfs.ext4 ~/theFile.imgubifs-re a Linuxot is tanítani kell, láttam ilyen bejegyzéseket, de nem próbáltam egyet sem.
-
válasz
mikk2000
#5580
üzenetére
Nem lesz kisebb, csak kevesebb az információ rajta: nincs tele.
Ha telepítesz egy operációs rendszert számítógépre, akkor sem 100%-ra kihegyezve választod meg a partíció méretét amire telepíted, nem?
Itt is szimplán ez van.
Adott egy partíció, arra rákerül egy operációs rendsze, és marad még hely az adott partíción.Lásd, hogy mi van akkor, ha szinte 99,9%-ig tele van: [link] Nem lehet root-olni egszerű eszközökkel, csak (mondjuk úgy) haladóknak.
A partíciók méretéről a
cat /proc/partitions
ad infót,
ezek foglaltságáról (ami valóban csatolt partíció) pedig adf
kimenete. -
Hát ha valaki úgy szeretné megváltoztatni, hogy nem csak a méreteket, hanem a sorrendet, akkor természetesen ezt a boot-ban is be kell állítani, és a scattert is át kell írni ha flashtool-os csomagot akar létrehozni..
Ilyesmit is csináltam, amikor sd kártyás dual boot kisérletet hajtottam végre.
Igaz, ez szimplán CWM recovery-ből indítható megoldás volt, nem flashtool-os.Ebben az esetben az eredeti partíciókiosztás sorrendje a szokásos:
system
cache
dataám az sd kártyán már megvariáltam, ott a mount már ezt adta ki:
/dev/block/mmcblk1p2 /system ext4 ro,noatime,noauto_da_alloc,commit=1,data=ordered 0 0
/dev/block/mmcblk1p3 /data ext4 rw,nosuid,nodev,noatime,discard,noauto_da_alloc,data=ordered 0 0
/dev/block/mmcblk1p4 /cache ext4 rw,nosuid,nodev,noatime,discard,noauto_da_alloc,data=ordered 0 0
tehátsystem
data
cache
lett a sorrend. -
A rendszer ugye mbr/ebr1/ebr2 típus
Ezek mondják meg, hogy mekkora, és hol van az adott partíció (hex cím szerint).
Ám a boot-ban a mount point csak annyi, hogy mmcblkXY (XY egy szám), tehát a blokkeszköz adott sorszámú partíciója. Tehát méretet nem mond, mert az (ebből a szempontból) mindegy neki.Ha már költöztettél Linux rendszert egyik hdd-ről másikra, vagy másik partícióra (más hely, más méret is akár), akkor feltűnhetett, hogy csak a méret csak annyiban számít, hogy ne legyen kisebb. Ha nem uuid-vel csatoltad a partíciót, hanem klasszikus sdaX módon, akkor az fstabot sem kell átírni, és mégis megy, ha a partíció elnevezése ugyanaz. Persze ha más, akkor meg csak az fstab-ot kell módosítani - illetve esetleg a grub menu.lst fájlját is .
-
Szerintem is jól gondolod, hogy nem a scatter a lényeg.
Pedig az elég lényeges.
Megfelelő scatter nélkül itt nem fog menni sem a módosítás, sem a hibajavítás/felélesztés.Szerintem egy 869 MB-s fájlrendszert ír fel (csomagol ki) az 1 GB-s rendelkezésre álló helyre.
Szerintem is.Ennélfogva, ha megváltoztatod a partició méretét akkor ezt az update-t már nem fogod tudni újra feltenni,
Ha meghaladja ezt a 869MB-ot az esetleg módosított partíció, akkor fel tudja tenni, természetesen ekkor kell az új scatter, amit a módosításkor használt.Sajna mtd típus esetén nem tuom, hogy hogyan lehet/kell a módosításokat elvégezni, de a scatter fájl átírása elengedhetetlen, ha a módosításokat érvénybe szeretné valaki léptetni. Ekkor jön ugyanis képbe a firmware upgrade. Mondom: tmd esetén még nem volt dolgom
Az újabb MTK-k esetén a scatter a mindenható, ha átírod a scatter-t és firmware upgrade-et csinálsz, akkor a partíciókat is átírja az új méretre.
Régebbi MTK alapú telefonoknál, ahol az mbr/ebr1/ebr2 master/extended boot record módozat létezett (és ext4 a fájlrendszer), ott a scatter-en kívül ezeket is módosítani kellett hex editorral, és ha teljes partícióátszabást akart az ember, akkor bizony a scatter-t is módosítani kellett.
Ilyet is csináltam már (jó régen...) - összenyomtam a system-et, a cache-t, és felhútam maximálisra a data-t. -
válasz
RockFonok
#5565
üzenetére
Ó.... az már nem is olyan rossz. Tehát akkor képes úgy csatlakozni, hogy a kijelzőn nem jelenik meg semmi, de számítógépről eléred a belső tárhelyet ("belső SD"-t) ?
Mert ha így van, akkor vélhetően a uboot vagy uboot/boot páros cserével még akár jó is lehet. Azért a boot cserénél még a system is javasolt cserére, de akár e nélkül is bejöhet.
Az uboot a kijelző és kamera "meghajtó" adatai tartalmazza. -
válasz
RockFonok
#5563
üzenetére
Akkor az gyanúsan nem rá való ROM. Lehet, hogy több kiadás létezik/létezett belőle.
Vadászni kell hozzá egy olyan romot (típusazonosat!!!) ami felmegy és működik.
Ez sajna türelemjáték.Arra viszont vigyázni kell, hogy a preloader az tényleg rá való legyen. Mert ha nem, akkor tényleg véget lehet vetni neki.
(sőt volt olyan is, amikor több romból összeválogatva az egyes partíciókat sikerült életet lehelni egy klón galayx mini-be; igen galayx mini volt, nem elírás.)
-
válasz
RockFonok
#5561
üzenetére
A needrom-on kell körülnézni.
Természetesen pontos típus és módozat alapján.
Ha ott találsz flastool-os romot, akkor azzal érdemes - mivel most kármentés folyik, ezért mindegy, hogy "vírusos" vagy sem, ROM cserén ráérsz gondolkodni, ha már újra képes működni a telefon.
(szerintem) -
válasz
RockFonok
#5559
üzenetére
Igazából a flashtool használata értekezést érdemes elolvasni először. Bár az újabb flashtool már másképp néz ki, ettől az elv még u.a
Ha meg szeretnénk találni a módot a felélesztésre, akkor a hibaüzenetek elég beszédesek tudnak lenni.
Szerinted szervizbe meg tudnák csinálni?
Kb mennyiért csinálnak ilyent?
Ez irányú tapasztalatom nincs.Van egy régi Samsung Galaxy Pocket Neo S5310 telefonom, arra egyből felment az eredeti ROM
csakhogy az teljesen más platform, más szoftverekkel/eszközökkel, metódussal. -
válasz
RockFonok
#5552
üzenetére
Tyűha...
Pontos tipust kell tudni, és egy gyári romot kellene felszuszakolni az életre keltéséhez.
Hogy miért nem kel életre?
Mert a kiadások között lehettek (tuti voltak) hardverváltozások, amikhez külön vannak rom-részek.
Ilyenek lehetnek eltérőek pl.
preloader (minden élet keztete az MTKs telefonoknál)
boot.img (tényleges rendszermag)
recovery.img
uboot (képernyő és kamerameghajtó mikrokernel)
system.imgszóval néhány eltérés, amely alapvetően meghatározza a telefon működését.
-
válasz
mikk2000
#5541
üzenetére
Szivesen, örülök, hogy sikerült!
Az NVRAM warning viszont eltűnt teljesen a WIFI kapcsolatokból.
Lehet, hogy az a frissítő szoftver tartalmazott valami hibajavítást is....Kösz még egyszer, folytatás munka után! Esetleg nagyjából(!) leírhatnád, hogy tulajdonképpen hogy varázsoltál a boot imagéből insecure boot-ot.
Szóval az úgy volt (hogy jött szembe a cápa... ja nem... az egy másik sztori), a boot és recovery partíciók mentés után kibonthatók, módosíthatók, és összecsomagolhatók.A recovery-hez hasonlóan a boot esetén is módosítást kell végezni, az sbin könyvtárban a secure adbd-t egy insecure adbd-re kell cserélni (amit már egy másik insecure boot-ból kivesz az ember), illetve a default.prop-ban az átállításokat meg kell tenni (itt is jó támpont egy már meglévő insecure boot).
Mondanám, hogy copy/paste, de inkább azt mondom, hogy esetenként át kell nézni.
Az adbd isecure az másolható, a default.prop nem. (Pédául amiből a módosítást csináltam ott a default.prop ext4-es bejegyzést tartalmazott, a tiéd viszont ubifs.) -
válasz
mikk2000
#5539
üzenetére
ööö ezt most nem értem... nem kell a SuperSU?
De, kell. Ez az, amelyik kontrollálja a hozzáféréseket.
Onnantól pedig ami root jogot akar szerezni, az szembetalálja magát azzal, hogy neked kell eldönteni: adod neki, vagy nem adod. A superSu-ban be tudod állítani, hogy kérdés nélkül engeded, rákérdezéssel engede, vagy tiltod az adott app-ot, kaphat-e root jogot.szerk:
Elsőre úgy néz ki működik, a root checker basic, miután engedélyeztem a SuperSU-val, azt írja ki a root sikeres.
Én a terminal emulator-nak hiszek.
Elindítod telepítés után, és a már jól ismertsu
parancs után ha ott van a#
akkor oké.Mivel azonban adb-n már láttad a
#-t, a root jog biztosított.
-
válasz
mikk2000
#5531
üzenetére
na akkor insecure kernel v2
-
-
válasz
mikk2000
#5528
üzenetére
Miért is akartál másik scatter-t használni, mint az eredeti?
A PMT change az a partition management table rövidítése. Ha változtattál a scatter-ben a partíciók (bármelyik) méretén, akkor ez az üzenet teljesen jogos.Amúgy másképp is fel lehet tenni a boot-ot.
adb reboot bootloader
fastboot flash boot beex-rainbow-insecure-boot.img
fastboot rebootLegközelebbi boot után pedig ennyi dolgod van ismét:
adb shell
Ha erre a prompt mögött megjelenik a # jel (a $ helyén) akkor adb oldalról tudod használni a root jogot.
Ha ez megvan, akkor már csak 1 lépés van vissza a fix root kialakításához.Ennek a kis aprócska programnak a lefuttatása.
Legyen bekapcsolva a tab, legyen összekötve a számítógéppel, mert adb-n keresztül dolgozik majd.
Lefuttatod, újraindul, kész.
Innentől szabadon garázdálkodhatsz.
Akár a link2sd programot is tudod használni innentől. Én annak idején használtam.
Ha netán mégsem működne, akkor szólj, van még a tarsolyban néhány ötlet.A recovery az más tészta, de elméletileg az sem kizárt. xda-n talán lehet találni még Carliv touch recovery-t ubifs támogatással.
-
válasz
mikk2000
#5526
üzenetére
Ha binárisan összehasonlítok két fájlt mondjuk total commanderrel, az kicsit értelmesebb infót ad, mint egy sima checksumos ellenőrzés
Nem vagyok biztos benne - így kipróbálnám a helyedben.
Jobban bíznék pl. a diff parancsban (Windows eseténfcparancs, ha jól láttam)ha két 1GB-os fájlod van, checksumos ellenőrzésre azt látod hogy nem egyezik, viszont ha összehasonlítod binárisan, akkor lehet hogy kiderül az, hogy csak egy byte-ban tér el, ami azért hasznosabb információ
Mivel nem ismerem a Total commander ezen részét , így nem tudok róla nyilatkozni.
A diff parancs ellenben megmondja hogy hol a különbség.
Példa (win)C:\Users\cappa>fc a.exe b.exe
Comparing files a.exe and B.EXE
00000000: 61 62
00000001: 20 0D
00000002: 0D 0A
00000003: 0A 11
FC: B.EXE longer than a.exeNa az nvram esetén már találkoztam ilyen folyamatosan változó wifi mac címmel: a gyártó elfelejtette feltölteni az nvram-ot, és üresen hagyta. Nem viccből mondom, tényleg üres volt. Erre utal az NVRAM warning...
De felrakok két azonos, de tartalmilag mégis kissé eltérő mentést a SYSTEM-ről, és ha gondolod nézz rá.
Kiváncsi vagyok, megpróbálok majd ránézni. -
-
válasz
mikk2000
#5523
üzenetére
Na, időközben mégiscsak mentegettem, méghozzá 2x
Alapesetben úgy kell menteni, hogy a proc/partitions által megadott hossz és a mentés mérete azonos legyen.
Két img mentése során ha nem kapcsoltad be a tabot és azonos módon történt a mentés, úgy ellenörzőösszeges összehasonlítást használj (md5, sha).
-
válasz
mikk2000
#5517
üzenetére
Látom azért sok kérdés merült fel benned. Ez jó.
Data partíciót azt nem feltétlen kell menteni, az csak a felhasználói adatokat tartalmazza (ez törlődik factory reset esetén). De meg lehet próbálni lementeni adott kezdőcím és a dumchar_info-ból kapott mérettel (aminek egyeznie kell a partitions mérettel. Mivel a gyári rom tartalmaz egy userdata.img-t, ezt felesleges menteni. Ez gyakorlatilag egy üres data partíció, simg típusú image fájlban.
A boot, recovery esetén a partícióméret nagyobb, mint a tényleges boot méret, ez mindenképp jó, mert így "ráfér" egy esetleges módosított boot is.
Igen, a felesleges részt FF-fel tölti fel.Én a mentés esetén mindent lementek – data és bmtpool kivételével. A preloader és az nvram két különösen érzékeny partíció.
A preloader ráadásul megint egy furmányos dolog, mert amit lementesz, azt nem lehet 1:1-ben visszarakni, az elején van egy feljéc rész, azt le kell vágni (hex editorral...)
Az nvram pedig olyan adatokat tartalmaz, mint imei szám, tehát telefononként egyedi.Ami a system métereltérést okozhatja az az, hogy a system partíció mérete az meghatározott, amit rá akar(sz) tenni, az pedig vagy ugyanakkora (img esetén), vagy kisebb (simg esetén)
Flashtool-lal mindenképp az egész partíciót kell menteni.
(Leginkább ext4-es partíciók esetén kellemes, hogy azonnal bele lehet nézni... Linuxon legalábbis)Este megpróbálom majd megnézni alinkelt fájlokat, addig a mentést érdemes megcsinálni úgy, hogy a mentett fájl mérete megegyezzen a beírt partíciómérettel (talán page only mód). Ha az megvan, akkor már egészen jó a helyzet.
Alapvetően szerintem a root megoldható lesz, ha másnem így: [link]
Erre ráment pár órám.
-
Szia!
Ez igazából nem mélyvíz téma, kérlek fáradj át a "Android dual sim telefonok" témába.
-
válasz
mikk2000
#5513
üzenetére
Nó problémó, mondja a Terminátorban a kiskölyök.
Szóval a mentés során alinear_start_addr: 0x7800000
legyen a kezdőcím, a méret meg apartition_size: 0x800000De a fontosabb a boot.img lenne most elsőre.
linear_start_addr: 0x6800000
partition_size: 0x800000
összevethető lenne az általad letöltött rom-ban lévő boot.img-vel.
Hasznos volna. -
válasz
mikk2000
#5511
üzenetére
Na ez egész jónak tűnik. Komplett gyári romra hasonlít.
A scatter a legfontosabb most neked a mentéshez.
Így már tudsz csinálni flashtool mentést.(közben összeraktam egy insecure kernelt is; de majd csak akkor osztom meg, ha már túl vagy a mentésen)
(szerk.: a windows esetén sajnos én hadilábon állok az oprendszerrel, mert alapesetben az otthoni gépen nem az fut, ezért is nem tudtam, hogy rendszergazdaként kell futtatni a terminált.)
szerk.2.: remélem nincs rajta bootloader zár...
Illetve asszem' a framaroot nevű root-oló program nem ad semmi szemetet. Sokáig használtam.
-
Ha jól értem akkor egy recovery vagy boot.img mentésből tudnál csinálni egy rootolt recoveryt vagy boot-ot?
Inkább azt mondanám, hogy a mentett boot.img-ből egy insecure boot-ot, amit fastboot-tal flesselve már elérhető adb-n a root. Aztán azt system szinten véglegesíteni (/system/su).Recovery már más tészta, ott kellene találni egy ubifs támogatású működő recovery-t, amit meg át lehetne portolni a tab-ra. Akár az eredeti boot, recovery img-kből.
-
-
válasz
mikk2000
#5495
üzenetére
Hát nem jó hírek...
Nagy kár, hogy a user2root nem aktív.
Az is kár, hogy nincs fizikai gomb a tab-on. factory mód kilőve.De azért nézd meg még azt is, hogy működik-e az
adb reboot bootloader
ha igen, és újraindul fastboot módba, akkor ott egyfastboot reboot
parancs után simán újra kell indulnia a tabnak normál módon.
Csak akkor csináld, ha az adb.exe mellett van fastboot.exe is!
De! Ha a rendszer nem támogatja a fastboot módot, akkor a tab lemerülésig nem lesz újraindítható.
Viszont ha igen, akkor a partíciók mentése után (még nem vagyunk nagyon közel) egy boot módosítást követően (úgynevezett insecure kernellel) lesz adb-n kereszül lehetőség az új boot.img tabra flesselésére (ez miatt kell a fastboot). És ha az már megvan, akkor adb-n keresztül már elérhető lesz a root jog. Onnan meg nyitottak a lehetőségek - merthogy valahol még talán le van mentve nekem egy root véglegesítő exe fájl, amit még kelzsoca csinált vagy 4 éve. -
válasz
mikk2000
#5489
üzenetére
Eddig legalább azt tudjuk, hogy van adb elérés, ez jó.
A shiriko is írta, a cat parancsokat lekérheted root nélkül is, működni fog.
Ami még kérdés, hogy esetleg van-e factory mode a gépen.
Ez hasonló a recovery mode-hoz, csak többet enged.
Ehhez ki kell kapcsolni a tabot, és a hangerő le + power gombbal bekapcsolni.
Ilyesmi szokott lenni:
Ha ez volna, akkor megint ki kell próbálni, hogy ebben a módban van-e adb elérés.
szerk.:
ha itt lenne esetleg root elérés, akkor meg egész jó helyen volnánk. -
válasz
mikk2000
#5487
üzenetére
Nos, végigolvasva a kezdeteket, úgy tűnik, hogy megoldás mindenképp van, legalábbis a mentésre és root-ra.
Természetesen sok függ, hogy mit enged a tablet szoftvere.
Az első lépés, hogy az usb hibakeresést bekapcsolod, és a számítógépen ha van adb, akkor parancssorban kiadod az
adb devices
parancsot.Ha a kapcsolat létrejön, akkor kírja, hogy milyen eszközt talált.
Ha van eszköz, akkor
adb shell
a következő parancs, majdsu -
Ha asu -parancsra kapsz egy#-t, akkor nagyjából meg is érkeztünk.Mentésre pedig biztosan lesz megoldás, csak elég sok az opció.
parancssorosan biztos le tudod kérni a partíciókiosztást.adb shell cat /proc/dumchar_info
adb shell cat /proc/partitions
valamelyikével.
Ebből lehet kreálni scatter-t is. -
adb-n a reboot recovery-nek nem kell root.
A teljes kikapcs után a bill. kombó kellene, hogy működjön.
Azonban itt van egy kis lehetőség az eltérésre:
- hangerő fel + power
- hangerő fel + hangerő le + power
- ugyanez a fenti kettő akkor, ha a töltés biztosított - magyarán töltőn van a telefonÉs csak akkor működik, ha tényleg a saját recovery-je van rajta. Akár egy kernelkülönbség a recovery-ben meggátol(hat)ja ennek betöltését.
-
válasz
borocsik
#5351
üzenetére
Nagyon régen egy valamilyen Ascend (talán) esetén találkoztam azzal a szomoró ténnyel, hogy a Huawei átírta a kapcsolati információkat, és az általános MTK SP flashtool nem volt használható sem mentésre, sem semmire. A windows-os huawei programot meg nem töltöttem le, nem próbáltam ki.
Lehet, hogy nálad is ez a helyzet.
De talán más majd megerősít. -
válasz
Boonen007
#5342
üzenetére
A needrom is tartalmaz valamit , de a leírásban ott is a chinaphonearena-ra hivatkozik.
De veszteni valód ezek után nem sok van. -
válasz
Boonen007
#5339
üzenetére
Hát preloaderitisz lehet (bocs...). Szóval a preloader szálhatott el.
Ilyenkor jön ez a hiba. Egy másik működőről lehetne leszedni egyet, vagy megnézni, hogy a needrom-on van-e másik gyári rom, hátha azzal elindul.
Ha lenne egy másik preloader, akkor is val'szeg úgy kellene megpróbálni a flash-t, hogy a gépre dugás előtt és alatt folylamatosan nyomva tartod a hangerő fel gombot, hátha még meta mode-ba bebillen a rádugáskor, és elindulhat a flash.
Nehéz ügy.
A kisebb és vagy akár nagyobb márkák esetén is előfordul, hogy a preloader változik a hardverkiépítés változása miatt, erről pedig nem kap a földi halandó infót, csak ilyenkor szembesül vele... -
-
Ha van usb debug bekapcsolva, akkor számítógéppel összekötve, vagy akár wifi-n usb debug kapcsolatot létrehozva, root meglétével vissza lehet állítani az előző állapotot - elméletileg. De ha nem boot-ol be, akkor más baj is lehet (főleg, ha ver > 4.4 - mondjuk ezekhez már nem értek)
-
Ha jól láttam, akkor ez 8121-es Mediatek proc.
Ha nem készült mentés, akkor érdekes lesz a helyreállítás, mert vélhetően nem azonos a hardvere azzal, amit feltettél rá.
Ez előfordul, hogy menet közben változik a hardverösszeállítás. Ilyenbe belefutottunk már párszor.
A boot és uboot (lk.bin) a jellemzően "ludas" ebben.
Szóval firmware csere javasolt, akár egy régebbi, vagy egy újabb verzióra. Sajna nem lehet megmondani, hogy neked régebbi, vagy újabb kell.
Elsőre csak a boot-ot cserélném le.Azért egy mentés most sem árthat.
-
#5258
cappa72
nagyúr
aprokaroka87
#5257
válasz
aprokaroka87
#5257
üzenetére
Legfeljebb otthon, ha a needrom-os link tényleg él, és jó hozzá.
(nem tudtam ellenőrizni), de támpontnak talán okés. -
Ha régen használatos volt, akkor 2-3 órát hagyd a töltőn, hátha kijelzés nélkül is töltődik valamennyit.
Ha aztán sincs reakció, akkor érdemes úgy rádugni a gépre, hogy nyomod a hangerő fel gombot folyamatosan.
Hátha... ha ekkor mond valamit a számítógép, és "új hardver" hangot hallasz, akkor az már legalább valami. Ettől persze még lehet agyhalott... -
Ha volt mentés:
nvram visszarakásaHa nem volt mentés, de volt format, akkor [link].
Én biztos most is csinálnék egy nvram bin region mentést, hogy meg lehessen nézni: üres, vagy nem. Csak eztán döntenék arról, hogy hogyan tovább.
(Mentésekről az összefoglalóban olvashatsz)
-
#5233
cappa72
nagyúr
aytukabozs
#5232
válasz
aytukabozs
#5232
üzenetére
Állítólag létezik deep-flash kábel, esetleg azzal megérhet egy próbát. Már akkor, ha nem csak egy reklámfogás ez a mélyvillanós kábel.
-
Sajna sehol nem találok rootolós zip-et.(A cikk(ek) se hozzák).
xda-n ott van, tuti biztos.
Se előtte,se rögtön utána nincs rajta recovery.
Hogyan próbáltál oda belépni?
Csináltál-e mentést? -> ha nem, akkor most azonnal... segítségedre lesz az összefoglaló elolvasása (flashtool-os mentés pl.)pl. futó rendszer alól, usb hibakeresés bekapcsolása után számítógéprőle egy
adb reboot recovery-re mi jelenik meg? -
Ha az LG Gpad7-ről van szó, akkor a megfelelő fórumtémába való szerintem.
Ha nem az LG-ről van szó, akkor pontosabb típus leírása esetén nagyobb eséllyel tudnak itt segíteni. -
Ahogy olvastam, az alábbi a követendő:
1, Flashtool-lal feltenni a kizárólag hozzá készült mod recovery-t.
2, Flash után azonnal a mod recovery-be kell lépni, és lefuttatni a root-oló zip-et (amit előzőleg már a telefonodra felmásoltál - javallott a fizikai sd kártyára).
3, reboot
4, örül.
Ez az elmélet.
Ha mégsem így menne, akkor érdemes leírni, hogy te mit, hogyan, milyen lépések sorozatával tettél meg. Részletesen.***
Nem tudom hogyan haladt az MTK a fastboot parancsokkal, régebben a boot-ot sem lehetett flesselni fastboot módban, aztán megjelent ennek a támogatása, de a recovery-t továbbra sem lehetett.
Hogy aztán azóta ez módosult-e... ki lehetne próbálni.adb reboot bootloader
fastboot flash recovery twrp.img
fastboot reboot
parancsokkal.
Legfeljebb nem sikerül. -
#5081
cappa72
nagyúr
davidvarga
#5080
válasz
davidvarga
#5080
üzenetére
Ha valamelyik partíció/blokkeszköz-szakasz nem menthető flashtool-lal (nem ideértve a bmtpool-t, illetve újabbaknál flashinfo meg hasonlók), akkor ott akár emmc (nand flash) hiba is lehet.
-
#5076
cappa72
nagyúr
davidvarga
#5075
válasz
davidvarga
#5075
üzenetére
Hát... akkor nem sok esély van, ha a bl zárt. De azért a 6572 esetén nagyon kevés lehetett az olyan.
Ha linkeled felhőbe a boot és recovery img-ket, akkor este megpróbálok ránézni (nem ígéret, mert ma szültésnap van idehaza). -
#5069
cappa72
nagyúr
davidvarga
#5067
válasz
davidvarga
#5067
üzenetére
Azóta kiderült, hogy csak (elméletileg) a recovery került fel.
Így más a helyzet.
Most már van akkor mentés a jelenlegi rendszerről, ha jól értem.
Ekkor inkább azt csinálnám, hogy egy PhilZ recovery autogenerátort próbálnék. Mint említettem, lehet, hogy a boot jó, de a recovery nem.
Vagy ha a patch-elt boot is flesselésre került, akkor insecure kernel került fel rá.Én elsőre biztosan ezt tenném, nem mást.
szerk.: A recovery-ből és a meglévő boot-ból mindkettőt szétbontva és átböngészve lehetne bootot csinálni, ám akkor még azt feltételeztem, hogy gyári a recovery. Viszont az MTKDT által készített recovery-ben a default.prop eléggé lerövidített szok' lenni, és abból nehéz visszavadászni ("visszagyártani") az eredeti boot-ban lévő default.prop-ot (meg a többit).
Ezért javaslom a fentebb említett lehetséges megoldást.
Előbb mindenképp belenéznék a jelenlegi boot/recovery párosba (ezt mondom most úgy, hogy tudom: nem lesz rá időm mostanság... ) -
#5059
cappa72
nagyúr
davidvarga
#5058
válasz
davidvarga
#5058
üzenetére
Javaslom a Flashtool readback mentést (ld. összefoglalóban a link).
Az kikapcsolt telefon mellett menti az emmc tartalmat.A flesseléskor sajnos nem mindegy, melyik verziójú flashtool-t használod... Érdekes, hogy van olyan, amelyik némely esetben átlép a pmt hibán. (Na ettől a kijelentéstől Keeperv85 majd ki fogja tépni a haját)
Ez egy régebbi flashtool, más felülettel, de MT6572 esetén én leginkább ezt használtam (akkoriban nem volt még Linux változata a Flashtool-nak).
Hozzá kell tennem, hogy nem feltétlenül kell ezt használni, csak lehetőség. -
válasz
Keeperv85
#5048
üzenetére
Na még arra gondoltam, hogy ha 4.4 volt rajta, és az MTKDT-s recovery került csak cserére, akkor megvan az eredeti boot, és a recovery zavar be. (JY G4S esetéből kiindulva, mint lehetőségkeresés...)
Ekkor egy mentés után bele lehetne nézni a boot.img-be, hogy miféle azonosító van a ramdisk-ben. Vagy akár rögtön abból készíteni egy másik, 4.4-hez portolt recovery-t. Esetleg a jelenlegi MTKDT-s recovery kerneléből is lehetne egy 4.4 támogatott mod recovery-t készíteni.De sajna valóban túl sok a feltételezés.
-
#5043
cappa72
nagyúr
davidvarga
#5041
válasz
davidvarga
#5041
üzenetére
Tyűha...
mt6572 v. 8312
Azokon még talán 4.2-es droid van, akkoriban még nem volt jellemző a bl (bootloader) zárás.
Ha a recovery elindul, és valóban CWM-ről vanszó (mert a gyárti recovery a 3e jelölésű, a CWM pediglen már módosított recovery), akkor az elég érdekes, hogy nem látja az SD kártyát.
Elsőre fussunk neki onnan, hogy melyik recovery van rajta. 3e vagy valamilyen módosított?A recovery-ből lehet csinálni boot.img-t, viszonylag jó eséllyel ezekhez a régi professzoros telefonokhoz.
Amúgy én biztosan lementeném a mostani állapotot, függetlenül attól, hogy most nem indul (akár a hibakereséshez...)
Factory reset volt már amúgy?
-
válasz
dethroner
#5009
üzenetére
A userdata-t nem kell mentened, ha nem akarod. (közbe' írtam privátot). Az úgyis csak a saját adataidat tartalmazza - ha pl. egy factory reset után kapásból lemented a userdata-t (be sem kapcsolva telefont(, akkor töküres sok gigás fájlt kapsz.
Nézd meg még acata /proc/partitons
kimenetét is.
A flesselendő usrdata pedig egy üres simg. -
-
-
Nézd meg, hogy az emulált storage és a data mérete azonos-e.
Bár nem leeco, hanem sáomi, de itt ilyet találtam
dfkimenetre:
/data 24.0G 21.9G 2.1G 4096
/storage 1.4G 0.0K 1.4G 4096
/storage/emulated 24.0G 21.9G 2.1G 4096
Ha egyezik, akkor (szerintem) jó.
(együtt használja a belső sd és a data a data partíciót) -
Ha factory reset után eltűnik az imei, akkor nem lett jó a művelet a mauimeta3g-vel.
Bizony az x2-nél van ilyen, hogy megmarad a második imei. (passz, nem sikerült rájönni..., pedig megformáztam párszor )Ha jól gondolom jelenleg a következő helyen tárolja a rendszer ezeket?
/data/nvram/md/NVRAM/NVD_IMEI/MP0B_001
Annyiban gondolod jól, hogy ide generálja le a rendszer induláskor (ha nem lenne. Ha van, akkor nem generálja le. Ez a magyarázata, hogy FR után huss, repül ez imei, mint a kék norvég ha nincs odaszügezve, FR nélkül pedig szépen megmarad).
Maga az alapinformáció pedig az nvram partíció - az BT, a WIFI, az imei és a többiek mind ide vannak bebütykölve.
az mddb könyvtában van a modem database file.
És itt vannak még a protect partíciók is, amiknek szintén megfelelőknek kell lenni.Induláskor (factory reset után):
Ha a boot és az mddb nem illeszkedik egymáshoz, --> nincs imei (még akkor sem, ha nem sérült a többi feltétel).
Ha bármelyik protect nem jó --> nincs imei.
Ha az nvram üres --> nincs imei
Ha a secro nem jó --> nincs imei -
Ha van beépített
freeparancs, akkor azzal kérdd le.
pl. adb-n keresztül így:cappapa@cappapa-Latitude-E6410 ~ $ adb shell free
total used free shared buffers
Mem: 2999050240 2703712256 295337984 15536128 2686976
-/+ buffers/cache: 2701025280 298024960
Swap: 1073737728 310190080 763547648Vagy terminál emulátorból az
adb shellnélkül, szimplánfree
Ha nincs a free parancs, és van root, akkor a busybox (by stericsson) telepítése után lesz.
Látható a total esetn, mekkora a tényleges RAM.
Ezt persze szeretik 1024 helyett 1000-rel osztani, így jobb az átváltási arány a meghirdetett mértehez. -
válasz
Graphics
#4850
üzenetére
Általában tele van szutyokkal (mindenféle bloatware, clean master, super booster és társai)
2 héttel ezetőtt csináltam meg egyet.1, twrp mentés (nvramot is!)
2, insecure kernel fel (van otthon, majd igyexem linket küldeni).
3, adb-n keresztül (remount után) kipucolni a systemből a klínmásztert és a hasonló hülyeségeket (meg a data-ból is. ha ott is van maradéka)
4, twrp-ből supersu zip fel, újraindít, örül.
Nekem így sikerült. -
válasz
Makifeju
#4811
üzenetére
Azért mindenekelőtt lekérném mindkét telefon
cat /proc/partitionskimenetét, meg acat /proc/partinfo(régebbi mtk alapúak esetén a /proc/dumchar_info kimenetet), hogy a partíciókiosztás valóban azonos-e.A preloader bütkyökésére egy kis infó.
-
-
Ide feltettem az általam módosított inf-et (mert most már hazaértem)
Ezeket adtam hozzá, amit az eszközkezelőből lestem ki.
%DESCRIPTION%=DriverInstall, USB\VID_17EF&PID_74ED&REV_????&MI_02
%DESCRIPTION%=DriverInstall, USB\VID_17EF&PID_7439&REV_????
Aztán elindult. -
tipp:
Na és ekkor belenéztem az inf fájlba.
Látám, hogy az eszközazonosítók valának benne.
A csatlakoztatott meta módú telefon eszközazonosítóját beírva az inf fájlba, és újra betallózva azt, siekerült működésre bírni a Vibe X2 és MauiMeta3G kombót!
Ezek után már lehetett olvasni a tartalmakat.
most is képben van.
Az is igaz, hogy mtd/ubifs eszköz talán az a bizonyos nehéz root-os volt nálam egyedül, ilyeneket nem néztem meg.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest