Force close, minden folyamatosan leállt...

Köszi az infókat

Force Close, mikor vmi alkalmazás lefagy és önkéntelenül bezáródik.

ha nem roviditve lett volna akkor tudtam volna mi az :-)

nekem swap meg esetleg zram tamogatas kene.. az meg kernel forras nelkul nem fog menni

...kicsit folytattam a mókolást az image kicsomagolóval.
most ott tartok, hogy gyakorlatilag az orosz xImgTool-hoz hasonló darabolt kimenetet tudtam produkálni, remélhetőleg helyes darabokat kaptunk. A darabok hosszának összege megegyezik az eredeti image hosszával.

Kedves Kernel Guruk! Lenne egy kérdésem a boot-stub az mi?
annyit már tudok, hogy egy 0x1000 byte hosszú valami, ami nem tudom, hogy a kernel szerves részét szokta-e képeni. Magyarán a kenellel együtt dump-olandó a zImage file-ba, vagy sem?

#define OFFS_HEADER 0x0000
#define OFFS_SIGNATURE 0x0200
#define OFFS_CMD_LINE 0x03E0
#define OFFS_UNKNOWN1 0x07E0 // ???
#define OFFS_BOOTSTUB 0x13E0
#define OFFS_KERNEL 0x23E0

...és kernel után a ramdisk becsomagolva file végéig. A teljes image hossza 512-vel osztható kell, hogy legyen, ezért a vége ki van töltve 0xFF-fel, hogy kijöjjön a jó hossz.

0x7E0 offset-től van egy számomra ismeretlen terület (3072 byte), hátha tudok róla valamit...annyit sikerült dekódolni, hogy a 2. byte (32 bit) a ramdisk hosszát adja vissza 512 byte-os blokkhosszra igazítva. A többi talány.Esetleg vmi ötlet? első 32 bit minden image-ben 0x5D00? és a többi adat is uaz, kivéve a ramdisk hosszt.

Unknown.Data[0] = 0x5d0000 (6094848)
Unknown.Data[1] = 0x38c000 (3719168) RamDisk Size aligned to 512 block size
Unknown.Data[2] = 0x0 (0)
Unknown.Data[3] = 0xff (255)
Unknown.Data[4] = 0x2bd02bd (45941437)
Unknown.Data[5] = 0x12bd12bd (314380989)
Unknown.Data[6] = 0x0 (0)
Unknown.Data[7] = 0x0 (0)

A kicsomagolt image-ek itt elérhetőek. [link]

Kicsomagoló progi forrása is bent van. Én mingw-vel fordítottam. Ha valaki érez késztetést, szabadon továbbfejlesztheti.

@Adamus1117: esetleg rá tudnál nézni, ha lesz egy kis időd?

Az összerakáshoz kelleni fog egy aláíró algoritmus. Kedves Kernel Guruk! Itt szabványos az eljárás, hogy SHA256 hash-t kell használni, vagy ez is platform / kernel függő? Mert ha kernel függő, akkor meg vagyunk lőve, forrás nélkül zsákutca... ha nem kernel függő, akkor érdemes lehet egy kis időt fordítani az aláírás gyártás reprodukálására. Ötlet?

[ Szerkesztve ]

sajna totál különböző a kettő (bedobtam comparátorba )

Szia!

Anno tlac írt kicsomagolót, azt hiszem Fent van nálam a githubon vagy bitbuketen, de előkeresem, ha nem...

Ártani nem árt, hátha használható nálunk is.

Köszi :kicsomagolni már tudunk, az teljesen jól működik, összerakni nem tudunk, mert nem tudunk aláírást csinálni. A te általad említett tool becsomagolni is tud?

[ Szerkesztve ]

Nekem fingom nincs mi az a boot sub, de a benne található stringek alapján talán ebből keletkezett: [link]

[ Szerkesztve ]

köszi

Tudomásom szerint nincsen aláírás a GXI kernelben, amihez készült. Mi a Motorola SMI (RazR I) alapot használtuk anno, de az is csak vágja az adott tartalmat a megadott helyeken és ezek alapján rakta össze is a tartalmat.

Ha alá van írva a kerneletek,azt viszont az életben nem játsszátok ki. Akkor ugyanis az a védelem van rajta, ami anno a Xolo x800-ban. Soha sem tudták feltörni még a szakma legnagyobb tekintélyei sem...

mivel root mar van, a vedelem nem teljes..

vegso megoldas lehetne az h a mar meglevo kernel bootol elso korben es az alatt futna egy patchelt boot loader ami kilo minden processt betolti az uj kernelt es raadja a vezerlest..

en nem talaltam ilyen megoldast keszen, de elmeletileg lehetsegesnek tunik.. kerdes h lesz-e valaki aki lekodolja

Nem lehetséges. Ahhoz, hogy a kernellel újra töltesd a bootloadert a kernel felől kellene kexec támogatás. Ehhez előbb kell egy olyan kernel, ami legalább boot képesre fordítható, mivel a gyáriban első dolguk ezt kilőni. Itt jön képbe, hogy oda-vissza megy a védelem, ugyanis a custom kerneled nem eszi meg a zárt bootloader. Ráadásul a bootloadert lehetetlen ebből a készülékből (is) kinyerni bármi formában, mivel a klasszikus értelemben nem is létezik. Nincs sem recovery, sem bootloader tárhelye. Egyetlen szuperblokkban van minden, aminek ráadásul a szekvenciája sem egyértelmű. A recovery, amit láthatsz, vagy akár a CWM recovery is csak emulált. Nem megy pl. alatta az adb, mivel folyamatosan bootloader módban van a készülék. Ezen felül a boot folyamat elején az Atom úgy indul, mint egy átlagos asztali PC, úgy bootol, mint egy Linux, de a boot folyamat kb 35%nál átvált Android kódútra...

A root nem jelent semmit. Egyszerű expolittal újra lehet csatolni írhatóra a systemet.

pedig nagyon úgy tűnik, hogy ez egy aláírt kernel.

mindegyik image (boot, recovery, fastboot) aláírás-blokkja különböző, pár byte-sorozatot leszámítva.

bal oldalon fastboot.img, jobb oldalon recovery.img SIG blokkja látható.

brahiból megguglizva az ominózis egyezést "30 CA 92 31 9C DE 23 11 45 EF 15 98", egyetlen egy találatot kapunk, az pedig "orosz barátaink" már ismert 4pda-s honlapja, amiről az xImgTool is származik

az alábbi linken [link] (#362-es hsz) pont ugyan ebbe a sztoriba futottak bele a srácok. Azt írják, hogy a byte-sorozat előtti 32 byte a SHA256 hash, míg az utána lévő szakasz maga az aláírás.

kulcs nélkül (ami ugye bármi és bármilyen hosszú lehet) visszafejteni ezt lehetetlen...

szóval eddig jutottunk, és itt van vége.

[ Szerkesztve ]

Érdekes de nálam cwm alatt tökéletesen megy az adb.
Sőt igazából betöltött rendszer alatt nem igazán működik, csak cwm alatt.

Van CWM? Akkor viszont nem zárt a bootloader, sőt, a CWM helyére akármilyen kernelt lehet tölteni. Maga a CWM csomag nyilván nincs aláírva tehát és erre nincs is szükség...

Kinyerni még egyszerű, feldolgozni viszont nem tudod dokumentáció nélkül...

tethered cwm van...
usbn memoriaba masolodik csak es 1x el lehet inditani.
flashelni nem lehet

Az nem gond, mivel ha az fut, akkor bármi futhat helyette... no de... miért is kéne bárminek futni helyette, ha nincs kernel forrás?? Nem értem miért lenne cél egy másik kernel, ha van működő CWM...