-
Fototrend
Ezt a fórumot azért hoztuk létre,hogy ne zavarjuk azon felhasználókat, akik még csak most ismerkednek a tablettel, vagy akár az Android rendszerrel.
Új hozzászólás Aktív témák
-
R0GERIUS
tag
válasz Orionhilles #38 üzenetére
Akkor ezek szerint "találd ki magad" nevű játékot kell játszani az oem parancsokért, mert nem találtam olyat amivel kilistázható lenne az összes.
[ Szerkesztve ]
-
R0GERIUS
tag
Egy kis érdekesség:
3 trigger valamelyike szerint szokták root-olni az Intel-es eszközöket:
a) oem startftm
b) oem backup_factory
c) oem stop_partitionAz erre vonatkozó XDA-s topic [link] (1. és 2. post) szerint nem csak az "oem stop_partition", hanem az "oem backup_factory" is működik.
Mivel viszont annyira nem vagyok benne a témában, így nem tudom, hogy ez mennyire lényeges... -
R0GERIUS
tag
válasz philips20 #45 üzenetére
Van is ha ez igaz (Google fordító: nyelvfelismerés-angol):
"I suppose the classic problem of the loss of security in the root, then I warn in advance that the image is signed and can not permanently replace the stock using CWM recovery, even not visible (they are hidden in the reserved section of memory and link to them in the MBR)."
(Forrás: [link] ) -
R0GERIUS
tag
válasz Orionhilles #49 üzenetére
A Google fordító legendásan pocsék, én is max. azért néztem át, mert hátha tartanak valahol.
(Viszont leginkább sehol sem tartanak...)
Reméljük bejön. -
R0GERIUS
tag
-
R0GERIUS
tag
válasz Orionhilles #51 üzenetére
Ez esetben, akkor növelni kellene a cache-t?
Akkor a helynövelés szinte ki van zárva.. -
R0GERIUS
tag
válasz Orionhilles #64 üzenetére
Ránéztem a kirakott fájlra, de az 4.6 KB-os, és kitömörítve van egy kiterjesztés nélküli "dump_images" fájl, ami 16 KB-os.
Biztos ez az? Minek kellene itt lennie? -
R0GERIUS
tag
válasz Orionhilles #64 üzenetére
Valamilyen RSA szignózást említ a leírás, így van valami köze.
Lehet, hogy nyers csomag amit a folyamat közben szignóz?
Mindenesetre itt arra gondol (szerintem), hogy hiába írja felül a recovery part. tartalmát, mert az igazi el van rejtve és az MBR tölti be (nem 100%). -
R0GERIUS
tag
válasz Orionhilles #72 üzenetére
... a legtöbb fenti dolog is az korrekt forrásjelölés és fordítás hiányában.
Jobban belegondolva, az MBR-es rész egy baromság, mert a legtöbb UNIX alapú rendszer (és azt hiszem az Android sem kivétel) GPT-t használ...
Még mindig az a kérdés, hogy zárt-e a BL?
Csak ezt majd hogyan lehet ellenőrizni minimális kockázattal...[ Szerkesztve ]
-
R0GERIUS
tag
válasz _Soma77_ #137 üzenetére
Pont a boot.img volt problémás dekompressziónál is.
És volt egy konzol üzenet: "trailing garbage ignored"
Szerintem ezért nem azonos az eredetivel az újratömörített.
Akkor lehet ezt a legkönnyebben igazolni, ha más img-knél (pl.system) ez a probléma nem áll fenn.[ Szerkesztve ]
-
R0GERIUS
tag
-
R0GERIUS
tag
válasz R0GERIUS #143 üzenetére
Na jó; nem bírtam megálni.
A header-rel jelenleg én sem tudok mit kezdeni.
A recovery és a boot meg iszonyatosan nagy hasonlóságot mutat, ami különös...
Talán az egyik a másik backupja?
A fájlokat elnézve nem tartom lehetetlennek.A másik érdekesség az, hogy a header-nek van egy olvasható részlete:
"init=/init pci=noearly earlyprintk=nologger loglevel=0 kmemleak=off androidboot.bootmedia=sdcard androidboot.hardware=redhookbay watchdog.watchdog_thresh=60 androidboot.spid=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx androidboot.serialno=01234567890123456789012345678901 ip=50.0.0.2:50.0.0.1::255.255.255.0::usb0n vmalloc=172M ehci_hcd.use_sph=1"Az újracsomagoltból ez hiányzik.
Ezen kívül külön érdekes ez a két rész:
"androidboot.hardware=redhookbay"
A configban van pár ilyen kiterjesztésű fájl.
"androidboot.bootmedia=sdcard"
Micsoda?!?! (Vad feltételezés: USB módban innen várja a boot helyreállító fájlját?)A harmadik: a klasszikus módszertól eltérően nem készül a kibontáskor zImage, hanem helyette xxx.img-kernel.gz (meg sem említem, hogy mind a recovery, mind a boot kibontása dob egy ilyen fájlt...).
-
R0GERIUS
tag
válasz R0GERIUS #144 üzenetére
Nos ezen értelmes részek még egy érdekes helyre vittek, és sikerült felfedezni valamit, de a befejezést rátok hagyom.
Alapvetően minden hiba/kellemetlenség a képfájlok kibontásában és újracsomagolásában az X86 miatt van.
Úgy néz ki, hogy ezen architektúrára épülő készülékek boot-ja és recovery-je eltér a szokványostól (ARM).
Így a keresési irány: Android x86 képfájlok kezelése.Véletlen bele is futottam XDA-n egy olyan Motorolába aminél hasonló gondoktól szenvedtek a képfájloknál (pontosan az Intel x86 miatt):
[link]
(Lehet, hogy érdemes végignézni, mert sok a hasonlóság: egyedi header, egyes részek (amit kiemeltem az előzőben) ugyanúgy szerepeltek benne...)Nem olvastam végig, de említenek egy hexa szerkesztőn alapuló megoldást:
[link]Idő hiányában nem tudok most ennél jobban belemélyedni; ezt rátok bízom.
[ Szerkesztve ]
-
R0GERIUS
tag
válasz _Soma77_ #149 üzenetére
Nézz rá a #145-re.
Úgy néz ki, hogy az összes x86-osnál nem standard a header, és nem működnek a szabvány módszerek erre nézve.
Ahogy utaltam is rá: sajnos valószínűleg ezen a vonalon kell elindulni...
A hexeditoros módszer jónak tűnt elsőre, de sajna nincs időm kipróbálni.[ Szerkesztve ]
-
R0GERIUS
tag
válasz _Soma77_ #149 üzenetére
Szerintem a fejlécnek nincs köze hozzá, hogy min lett generálva.
A Moto-sok azzal próbálkoztak, hogy a szkriptbe beírták a változó negáltját, de az se egy túl biztos módszer.
A hexá-s nekem biztosabbnak tűnik, hisz mivel egyszer ki tudtuk bontani, így elég könnyen megmodható, hogy meddig tartanak az egyes részek (header, cpio, kernel).
Amúgy ez a '$OS$' jelölés az android helyett az elején inkább indefinit. Sok helyen (szkriptekben) így jelölik, esetlegesen a din. adatot, azaz hogy pl. olvassa ezt az adatot, és nem fix adat.
Bár elég ronda dolog ez egy header-ben.[ Szerkesztve ]
-
R0GERIUS
tag
válasz _Soma77_ #157 üzenetére
Ha találsz hozzá olyan kitömörítőt, akkor fogjuk csak megtudni.
Ehhez a nem működő szkriptet kellene úgy szerkeszteni, hogy ne keresse az "ANDROID" részt.
Ezt elméletileg a szkriptben az ANDROID !ANDROID-ra való cserélésével talán meg is lehetne csinálni...
Érdemes lenne megnézni azt, hogy a legtöbb x86-on, hogyan oldották meg ezt a problémát... -
R0GERIUS
tag
válasz _Soma77_ #175 üzenetére
A header mérete már a standard-ra sem stimmel.
Viszont leginkább azért nem jut semmire, mert ez elméletileg az mkbootimg-nek felel meg, amivel a következő a gond:
"mkbootimg cross-compiled for ARM will run into issues as described in this question."
Azaz az mkbootimg ARM-hez van igazítva, így nem sok mindenben tudunk rá támaszkodni. (Leszámítva a fájlok kinyerését, mert arra alkalmas.)
Főként nem header területén, hiszen esetlegesen a blokk hosszai is eltérhetnek, de ha nem is, akkor is teljesen más a header elrendezése (megkockáztatom: teljesen máshogy dolgozhat).
A blokkhossz számláló tényleg nem stimmel, de ha még jó is lenne, nem sokra megyünk vele x86-os Android alatt.[ Szerkesztve ]
-
R0GERIUS
tag
válasz _Soma77_ #175 üzenetére
IGEEEEN!
Habár nincs megoldva a header probléma, de 100%-ig ugyanolyan repacket sikerült készíteni.
Ha valaki átdobja, hogy miket kell módosítani a recovery.img-ben, illetve a boot.img-ben, akkor megnézném, hogy mennyi az eltérés.
Ha megtartja a header-t és csak a lényeges részeket írja felül, akkor van egy használható img tool.Talált eszköz: [link]
UPDATE: Nálam a kibontott ramdisk az szerintem hibás. Lehet, hogy repack-re lesz majd csak alkalmas?
Mondjuk az is elég lenne... -
R0GERIUS
tag
válasz R0GERIUS #177 üzenetére
UPDATE 2: korai volt a lelkesedés.
Valahogy a két dolgot össze kellene házasítani.
Itt jó a a repack és ott az unpack.
Amúgy a hiba amit dob a ramdiskhez: túl korai archívumvég. Azaz nem jól kezeli a végét a ramdisk-nek és az elejét zImage-nek...
Ha viszont a tool-al oda vissza csinálom akkor 100% ugyanolyan image-t ad, de ha a másik által kibányászott ramdisk-et és kernel képet használom, akkor elég sok eltérés van benne.Ezzel a tool-al kicsomagolt ramdisk 0-38C000-ig tart, míg a rendes ramdisk-nek 38C020-ig, tehát valóban a mérettel van a gond. Valahogy azt kellene korrigálni, és valószínűleg megvan.
[ Szerkesztve ]
-
R0GERIUS
tag
válasz R0GERIUS #178 üzenetére
UPDATE 3: Sajna nem nyersen a méret a hiba.
Átirtam a kódot, így megfelene a méret, de nem stimmel, továbbra sem nyitható meg.
Lehet, hogy maga a blokkok pozíciója más?
Az sok mindent megmagyarázna...UPDATE 4: El van számolva.
Az eredeti szkript, ami értelmes fájlokat nyert ki, az onnan kezdi leválasztani, ahol a fájlban megtalálja ezt: 1F 8B (magic number)
Itt is megvan ez a szám, csak 1000-el elcsúszva...
Át kell paraméterezni a program által kiolvasott blokkokat.[ Szerkesztve ]
-
R0GERIUS
tag
válasz _Soma77_ #209 üzenetére
Pontosítva: képes pack és repack-re, és eredeti képet állít elő.
Viszont korrigálni kell a blokkok számítását (vagy inkább kézileg megadni), mivel a kibontott képek használhatatlanok (1000 hexa egységgel van elcsúszva, csak nem tudom, hogy azt miből vágja le).
Ehhez nekem ki kell találnom, hogy hogyan számítja ki a blokkokat.
Viszont 14-éig felejtős, mert mind 9-én mind 14-én vizsgázom.
Amúgy mi is a felépítés? Header, ramdisk, kernel (sorrendben így)?[ Szerkesztve ]
-
R0GERIUS
tag
Pontosan.
A rendszer emulálja úgy, mintha az külön belső tároló lenne, de valójában nem az.
És mivel a /data része, így az alkalmazások is ide települnek, tehát az is csökkenti a fájlok tárolására használható méretet.
Szóval érdemes külső SD kártyát venni, ha sok fájlt akarsz tárolni rajta (vagy nagyokat: pl. jó minőségű filmek (mkv)), és meghagyni a belsőt az app-oknak.
Új hozzászólás Aktív témák
- Anglia - élmények, tapasztalatok
- Konzolokról KULTURÁLT módon
- BestBuy ruhás topik
- Milyen billentyűzetet vegyek?
- 3D nyomtatás
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Microsoft Excel topic
- Fujifilm X
- További aktív témák...
- Bomba ár! HP Elite X2 1011 G1 - m5 I 8GB I 256GB SSD I 11,6" FHD Touch I CAM I W10 I Gari
- ÉRKEZETT Legújabb Bontatlan Új M2 IPAD PRO 2022 12,9 128GB - 256GB Wi-Fi Azonnal DEÁK TÉRNÉL Átvehe
- ÉRKEZETT Legújabb Bontatlan Új M2 IPAD PRO 2022 11 128GB - 256GB Wi-Fi Azonnal Deák Térnél Átvehető.
- Apple iPad 10th Gen 64GB Wi-Fi, Újszerű, 1 Év Garanciával
- Apple Pencil 1/2 új bontatlan 1 év Apple garancia