- Az USA nem akarja visszafogni Kína növekedését
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Direct One (műholdas és online TV)
- Facebook és Messenger
- Ubiquiti hálózati eszközök
- Windows 11
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- HBO Max & OD topic
- Ember helyett robot kellene az űrbe
- Kínában túl sok az EV, fokozódik az árháború
-
IT café
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
-
_Soma77_
tag
nem tudom, hogy ez a dump_image uezt csinálja-e mint ez [link]
[ Szerkesztve ]
-
_Soma77_
tag
elvileg megvannak az .img-k
-
_Soma77_
tag
ezt meghagyom neked holnapra
levarázsolom az .img-ket és kiosztom őket, aztán próbálgassátok... -
_Soma77_
tag
válasz Orionhilles #87 üzenetére
kicsomagolt dump_images (16k) bemásolva belső memóriára vagy SD-re
Total Commander-rel átmozgatás /data/local-ba (TC root joggal bír)"adb devices" - lecsekkol, hogy látszik-e a tab az ADB interface-en
(ne felejtd el engedélyezni a kérést, tabon USB debug engedélyezve kell legyen - ADB Toggle.apk segíthet)
ADB Shell megnyitás
cd /data/local
root jog kérés: su
root-ként futtatási jog (x) adás: chmod 755 dump_images
majd futtatás: ./dump_images -a
uoda menti az .img-ket (ha nem olyan bénán adod meg a külső sd-t mint én, akkor oda menti - 3. param )
(TC-vel átmozgatás vmi látszó helyre pl. külsőSD/Downloads, vagy ilyesmi, innen leszedhető)ennyi.
mások is megcsinálhatnák, hogy ugyan azokat az img-ket kaptuk-e...
[ Szerkesztve ]
-
_Soma77_
tag
ide feltettem az image-eket [link]
...ha esetleg flash-elni támad kedvetek recovery/fastboot/stb. alól...
[ Szerkesztve ]
-
_Soma77_
tag
ha esetleg vkinek van linux-os gépe, tehetne egy próbát ezzel a módszerrel... [link]
-
_Soma77_
tag
válasz Orionhilles #107 üzenetére
recovery launcher mappa hol van?
-
_Soma77_
tag
válasz Orionhilles #110 üzenetére
"adb sideload revovery.zip" elvileg kiadható parancs de "adb sideload" menüpont recoveryben? azt hol kellene látnom? Sideload nem kezd el telepíteni valamit?
Ahogy mondtam, a hardcore flash-elgetést meghagynám másnak...
[ Szerkesztve ]
-
_Soma77_
tag
-
_Soma77_
tag
találtam egy szkriptet, amivel úgy tűnik, sikerült kicsomagolni a boot.img-t...
[ Szerkesztve ]
-
_Soma77_
tag
válasz Orionhilles #116 üzenetére
gratula Freddycom boot.img-jét még nem bontottam ki, mindjárt megcsinálom, mert bár hosszra uaz, de a tartalma nem az...
kibontás után látható lesz a különbség...
Többi image-et is ki kellene bontani, nem? főleg recovery lehet érdekes....
[ Szerkesztve ]
-
_Soma77_
tag
rápattanok a recovery kibontásnak, hátha....
-
_Soma77_
tag
válasz Orionhilles #132 üzenetére
itt a kibontott recovery [link] szóval mit is kellene vele csinálni?
[ Szerkesztve ]
-
_Soma77_
tag
válasz Orionhilles #134 üzenetére
ok, de még előtte kicsit gyakorlom a re-pack-ot a boot.img-n, hogy meglegyen a rutin, meg hogy lecsekkoljam, tényleg jó-e a re-pack szkript, mielőtt brick-eljük a tabodat...
-
_Soma77_
tag
valamiért a ki- és újracsomagolt img-k nem egyeznek, ezért még nyomoznom kell egy kicsit...kis türelmet kérek!
-
_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?
-
_Soma77_
tag
@Adamus1117: köszi, hogy belenéztél...és köszi a tippeket is...
próbaképpen egy újonnan készített img-et kicsomagoltam majd újra becsomagoltam, és nem lett ugyanaz na erre végképp nem számítottam, lehet, hogy vagy 1. vmit elböktem (bár többször is kipróbáltam) 2. az x86-os "anomália" okozza...
-
_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::usb0n vmalloc=172M androidboot.wakesrc=05 androidboot.mode=main
[ Szerkesztve ]
-
_Soma77_
tag
egy kis olvasnivaló [link]
-
_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!
[ Szerkesztve ]
-
_Soma77_
tag
Lehet, hogy holnap csinálok egy hack-elt repack-ot, aminek a header része (2048 byte) át lesz emelve az eredeti img-ből... amolyan öszvér...
-
_Soma77_
tag
lehet, hogy vakvágány, de....
valaki írta korábban, hogy ez a gép egy Teclast klón. Nem egy Teclast 89 mini véletlenül?
[speckója] elégge hasonló.a baj csak annyi, hogy ez a gép is 16GB-os --- ahogy az Op3n Dott eredeti gépe is.
van hozzá root-olt ROM [link] innen [link]
a partíciós tábla (partition.tbl) is elég hasonló felosztást mutat.
talán érdemes ezt a szálat is nyomozni egy kicsit...
-
_Soma77_
tag
egy kis olvasnivaló...[link]
-
_Soma77_
tag
válasz R0GERIUS #164 üzenetére
itt a header formátum [link]
és ahogy írják, struktúraként kezelni a headert a szám reprezetáció miatt (endian) nem lesz ugyan az ARM-on és x86-on... így nem mindegy, milyen platformon írják a ki-/becsomagoló tool-t... ahogy a mellékelt ábra is mutatja [link][ Szerkesztve ]
-
_Soma77_
tag
válasz R0GERIUS #164 üzenetére
csak nem hagy nyugodni ez a header história...
í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?)
[ Szerkesztve ]
-
_Soma77_
tag
mai házi csapatmunkánk eredményei (köszönet a kollégáknak!!!):
- külső 16GB-s SD kártya Ext4-re formázva
- recovery-be belépve, adb shell-en keresztül dd-vel teljes belső tárhely tartalom image-ként lehúzva (8GB)dd if=/dev/block/mmcblk0 of=/external_sd/soma_backup.img
Ez az image be-mountolható, így látszik a /system stb...
mount /dev/block/mmcblk1p1 /external_sd
- kollégám kitotózta az $OS$ magic-es boot.img szerkezetét:
OSIP header [link]
master boot rekord (MBR)
signature
és végül a partíció tartalmaa szívás az, hogy az image aláírt kell hogy legyen
a jó hír, hogy egy orosz PDA fórumon találtunk egy XImgTool nevű csodatool-t, ami image-eket ki-be csomagol éééés aláír is! [link] jó hír, hogy a ki és visszacsomagolás ugyan olyan $OS$ magic-es képfájlt eredményez!
- találtunk egy másik tool-t is, ami ramdisket is kicsomagolja, ezt még próbálgatni kell (nem próbáltuk ki, hogy aláír-e pl.) [link]
- akinek van Total Commander win alatt, érdemes feltetelíteni az adb-plugin-t, szépen browse-olható vele a tab ADB interface-en kersztül... [link]
Most itt tartunk jelenleg...
[ Szerkesztve ]
-
_Soma77_
tag
válasz Orionhilles #182 üzenetére
link javítva
-
_Soma77_
tag
válasz Orionhilles #189 üzenetére
attól mert zárt, az még nem feltétlenül jelenti azt, hogy nem lehet kinyitni...
általában minden szoftveres mókolás garanciavesztéssel jár, de aki ilyenre adja a fejét, az ezzel alapból tisztában van szóval az a kérdés, ki lehet-e nyitni egyáltalán. -
_Soma77_
tag
válasz Orionhilles #191 üzenetére
reméljük, előbb-utóbb mindennek meglesz a módja vagy már meg is van, csak még nem tudunk róla
[ Szerkesztve ]
-
_Soma77_
tag
valaki kipróbálta már a ki- és visszacsomagolt image-eket felrakni?
-
_Soma77_
tag
Nem a tárhely a gond általánosságban, mert azt külső SD-vel lehet pótolni. Az appok sosem fognak /logs-ba települni (hiába a symlink), csak a data-ba, így a logs területét kell a data-nak odaadni (részben) és ez csak átparticionálással lesz megoldható, máshogy nem nagyon...
-
_Soma77_
tag
válasz Orionhilles #202 üzenetére
...ez azt jelenti, hogy a flash maga sikerült (azaz az összerakott img formailag jó volt?) csak esetleg a módosítás maga nem volt jó? mit módosítottál pontosan?
-
_Soma77_
tag
válasz Orionhilles #205 üzenetére
-
_Soma77_
tag
kicsit utánanéztem...az orosz fórumon linkelt xImgTool megvan itt is [link]
x86 Android Platform-ra , IMG és BIN file-okhoz, INB, SZB, QSB konténerekhez jó (pl .Lenovo K900, Ramos i9, Asus ZenFone 4,5,6, ZTE Geek)
úgy tűnik, nem teljesen tökéletes nekünk, de kiindulásnak jó, és itt is jó lenne némi forrás-kód...majd keresek.
@Adamus1117: te jutottál valamire a pack/repack progiddal?
[ Szerkesztve ]
-
_Soma77_
tag
válasz Orionhilles #205 üzenetére
AndImgTool (Android Image Tool) - a utility for unpacking and re-assembly of the type of boot images and BOOT RECOVERY for ARM-platform...ez lehetett a baj...
-
_Soma77_
tag
sajnos úgy tűnik, hogy kernel forrás nélkül itt semmire sem fogunk menni, mert az image-ek szétszedése még csak megy, de az összerakáshoz valószínűleg kernel szintű algoritmusok / kód fognak kelleni (pl. verify_image az aláírás ellenőrzéshez) ennek ismerete nélkül sajnos nem tudunk működő image-et összerakni... és még ha ez menne is, valószínűleg új kernelt is kellene majd fordítani, ami ugye forrás nélkül nem igazán lehetséges...
nekem eddig tartott a tudományom, kíváncsian várom, esetleg mások jutnak-e valamire...
-
_Soma77_
tag
...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 ]
-
_Soma77_
tag
válasz Orionhilles #230 üzenetére
sajna totál különböző a kettő (bedobtam comparátorba )
-
_Soma77_
tag
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 ]
Új hozzászólás Aktív témák
- iPhone topik
- Le Mans Ultimate
- Világ Ninjái és Kódfejtői, egyesüljetek!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Az USA nem akarja visszafogni Kína növekedését
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Kerékpárosok, bringások ide!
- Politika
- OLED TV topic
- Kertészet, mezőgazdaság topik
- További aktív témák...
- BONTATLAN ÚJ iPad Pro 2021 2022 M1 M2 Chip 11 és 12,9 128-2000GB DEÁK TÉRNÉL AZONNAL ÁTVEHETŐ
- ÚJ Apple Pencil 1 - 2 első és második generációs BONTATLAN AZONNAL ÁTVEHETŐ DEÁK TÉR
- iPad Pro 11" - M1 - 256GB - Hibátlan
- iPad 9th. 64GB Wifi Újszerű/2026.03.14.Gar. Akku 100%/p3353/
- iPad Pro 11 (2018), Wi-Fi, 64 GB, Space Gray