- Samsung Galaxy Z Flip5 - ami kint, az van bent
- Hat év támogatást csomagolt fém házba a OnePlus Nord 4
- Yettel topik
- Sony Xperia 1 VII - Látod-e, esteledik
- Samsung Galaxy A56 - megbízható középszerűség
- Samsung Galaxy S25 - végre van kicsi!
- iPhone topik
- Honor 400 Pro - Gép a képben
- Poco X3 NFC - minden, ami kell
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
Hirdetés
-
Mobilarena
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
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. -
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.
-
_Soma77_
tag
válasz
R0GERIUS
#164
üzenetére
csak nem hagy nyugodni ez a header história...
![;]](//cdn.rios.hu/dl/s/v1.gif)
írtam egy kis progit (Eclipse alatt, mingw alatt fordul) amely a leírt [struktúrába] kibontja a header tartalmát.
ráengedve egy hagyományos (ANDORID! magic-es) image-re, szépen hozza az adatokat.
viszont a "nem standard" image-ekre (amilyen a miénk is) nem sok adatot hoz...pl. boot.img
ami aggaszt, hogy az egész struktúra mérete összesen 608 byte (feltételezve, hogy az "unsigned" típus 4 byte-os "unsigned int"-et takar), holott a header 2048 byte (0x0000-0x800-ig terjedő terület az image-ben)...
hol a hiányzó 1440 byte (=180 unsigned int?)
-
_Soma77_
tag
-
_Soma77_
tag
válasz
R0GERIUS
#143
üzenetére
megnéztem a linken szereplő eljárást is, leszedtem a tool-okat, de a "unmkbootimg" nem ette meg a mi képfáljainkat.
az általam korábban használt perl szkriptek egyébként a leírtak alapján dolgoznak (BTW zImage helyett ...-kernel.gz file-okat gyártanak), és az image összerakás (kernel, és cpio-ba becsomagolt ramdisk összefésülése) is teljesen jónak tűnik... kicseréltem a "mkbootimg" toolt is egy frissebbre (ami a linken szerepelt), és átparamétereztem a hívást a leírtak alapján, de ugyan az lett a kimenet, mint korábban... 
nekem úgy tűnik az eredeti image fejléce alapján, hogy ez vmi OSX-es tool-lal generált dolog lehet, mert 1. nem a standard magic android header keletkezik 2. BoardConfig.mk-ból származó dolgok vannak benne (kernel szint?!), tehát ez több, mint egy sima "lapátoljunk össze egy image"-et tool mint az "mkbootimg"...
akinek van ötlete, pls jelezze!
-
_Soma77_
tag
válasz
R0GERIUS
#144
üzenetére
rákeresve a kérdéses olvasható részére a boot.img-nek, eljutottam egy BoardConfig.mk-ig, mintha innen lenne...
BOARD_KERNEL_CMDLINE := init=/init pci=noearly console=logk0 earlyprintk=nologger loglevel=0 kmemleak=off androidboot.bootmedia=sdcard androidboot.hardware=redhookbay $(cmdline_extra) ip=50.0.0.2:50.0.0.1::255.255.255.0::usb0
n vmalloc=172M androidboot.wakesrc=05 androidboot.mode=main -
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.
-
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...).
-
_Soma77_
tag
válasz
R0GERIUS
#139
üzenetére
az a helyzet, hogy a re-pack szkript nem ugyan olyan fejlécű image-et rak össze, mint az eredeti volt.
Örülnék, ha valaki rá tudna nézni egy kicsit közelebbről...
felraktam ide a teljes motyót, minden köztes állománnyal és szkript-tel. [link]
van két pearl szkript (unpack-bootimg.pl és unpack-bootimg2.pl), amelyek gyakorlatilag csak parancssoros hívásban térnek el egymástól...
1) system ("mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel $ARGV[0] --ramdisk ramdisk-repack.cpio.gz -o $ARGV[2]");
2) system ("mkbootimg --base 0x00200000 --pagesize 2048 --kernel $ARGV[0] --ramdisk ramdisk-repack.cpio.gz -o $ARGV[2]");...viszont mindkettő a csomagban lévő mkbootimg-t hívja.
A kimeneti image-ek (new_boot.img és new_boot2.img) csak a parancssorban különböznek (header részben), többi ugyan az...miért is lenne más?
Viszont az eredeti img és az újra-pakolt img több ponton is különbözik, főleg a fejlécben, mivel nem "ANDROID!"-dal kezdődik, hanem "$OS$"-al.
Szerintem kellene találni egy olyan "mkbootimg"-et, ami az eredetivel megegyező image-et gyárt.
Az újrapakolt image-ek elvileg(!) Android kompatibilisek, kérdés, hogy az Op3n Dott megeszi-e???
Ötlet?
-
#75
Orionhilles
senior tag
R0GERIUS
#74
Rákérdeztem, és azt írta, hogy ő nem ismer ilyen módszert...
Azt meg kellene valakinek próbálni, hogy a cwm launcherben lévő cwm.zip-et (ha jól dereng) fel kellene próbálni flashelni gyári recovery alól. Mi történik?
(lehet, hogy nem bírok magammal és én leszek az az egyén...
) -
#70
Orionhilles
senior tag
R0GERIUS
#69
"... És az MBR tölti be"
Ez az említett önjavító metódus, ezek szerint valószínűleg zárt bl, de holnap du megnézem, remélem nem, mert akkor felesleges az eddig bele ölt munka.....
Azon filózok, hogy valamelyik frissítés patcheli a bootloadert, lehet hogy az is zárja le az addig nyitottat? -
#68
Orionhilles
senior tag
R0GERIUS
#67
-
#64
Orionhilles
senior tag
R0GERIUS
#62
Nem, dehogy!
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)."Ez nekem sántít.. Cwm nem lehet aláírva, így nem is értem... Ha flashelem recovery partícióra akkor :
Nyitott bl esetén ott marad.
Zárt bl esetén a gyári felülírja (önjavító metódus) vagy tégla lesz belőle
De recovery partícióra flashelte droidboot alól??? Vagy csak ideiglenes cwm-mel próbálkozott? -
#49
Orionhilles
senior tag
R0GERIUS
#48
-
#38
Orionhilles
senior tag
R0GERIUS
#37
Nem tudom hogy jött ki, mert nem értem hogy mit csinál... 
nem tudom, hogy az aláírás gyártás pl. helyes-e, ill. nem tudom, nekem miért csinál 4k-val rövidebb img-t 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
így nem mindegy, milyen platformon írják a ki-/becsomagoló tool-t... 
ahogy a mellékelt ábra is mutatja 
a legjobb az lenne, ha lenne fogalmunk róla, mi kerül a header-be, és nem csak brute force-olnánk egyet 
n vmalloc=172M androidboot.wakesrc=05 androidboot.mode=main
)
Új hozzászólás Aktív témák
- iPad Pro 12.9" 4.Gen 2020 1TB Space Gray Wifi cellular, Garanciával, üzletből
- Galaxy Tab S10+ 5g és Gyári Smart Folio keyboard Samsung vásárlás
- Apple iPad Pro 12.9 5th gen Wifi 128GB Space gray (A2378)
- Samsung Galaxy Tab S10+ (256 gb) (+ book cover) (Samsung vásárlás)
- MacSzerez.com - iPad Air M1 / 5. generáció / 64GB / Wifi / Pink / Garancia!
- GYÖNYÖRŰ iPhone 12 mini 64GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS2955
- Dell USB-C dokkolók: (K20A) WD19/ WD19S/ WD19DC + 130W, 180W, 240W töltők
- AKCIÓ! Apple Mac Studio M1 MAX 2022 32GB 512GB számítógép garanciával, hibátlan működéssel
- Lenovo ThinkPad T14 Gen1 Ryzen5
- Dell Optiplex 3020 SFF I5 4590
Állásajánlatok
Cég: FOTC
Város: Budapest