Hirdetés
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- eBay-es kütyük kis pénzért
- Luck Dragon: Asszociációs játék. :)
- bb0t: Ikea PAX gardrób és a pokol logisztikája
- gban: Ingyen kellene, de tegnapra
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- D@reeo: Pi-hole és a Telekom Sagemcom F@st 5670 DNS beállítása
- Brogyi: CTEK akkumulátor töltő és másolatai
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
-
LOGOUT
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
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Elektromos autók - motorok
- Kormányok / autós szimulátorok topikja
- Samsung Galaxy A55 - új év, régi stratégia
- BestBuy topik
- Ford topik
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Bemutatkozott a Poco X7 és X7 Pro
- OLED monitor topic
- PlayStation 5
- További aktív témák...
- iPad Pro M2 11" hibátlan dobozos 2026.11.22. iStyle jótállás
- Apple Pencil 1. generáció / Apple Pencil 2. generáció / Apple Pencil Pro OEM és gyári dobozos !
- iPad Smart Keyboard iPad Pro M4 12,9 hibátlan!
- Panasonic Toughpad FZ M1 - MK3 - I5-7Y57 - Ütésálló tablet - 7"-os - Több darab
- Getac ZX70 - Ütésálló tablet- Androidos - GPS /4G - Több darab érkezik - Új ára 580.000Ft
- GYÖNYÖRŰ iPhone 13 mini 128GB Starlight -1 ÉV GARANCIA -Kártyafüggetlen, MS3891, 100% Akkumulátor
- Azonnali készpénzes INTEL CPU AMD VGA számítógép felvásárlás személyesen / postával korrekt áron
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5060 Ti 16GB GAMER PC termékbeszámítással
- CSX 2x2GB (4GB) DDR 800 MHz kit
- BESZÁMÍTÁS! Gigabyte H610M i3 12100F 16GB DDR4 512GB SSD RX 5600XT 6GB Zalman S2 Corsair 650W
Állásajánlatok
Cég: ATW Internet Kft.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest