2024. március 29., péntek

Gyorskeresés

Útvonal

Cikkek » Telefónia rovat

Android magyarítás guide

"Fordítsuk le a rendszert, közelebb jutunk egy saját ROM-hoz!" - így kezdődött minden...

[ ÚJ TESZT ]

A rendszer mentése, boncasztalon a droid

Egy idealizált világban, a gyártó hajlandó zip formában kiadni legalább a telefonunkon futó rendszert, amiben rögtön kibontva megtaláljuk a kívánt system mappánk, benne az apk fájlokat. A valóságban pedig hajlandó RUU és egyéb misztikus lemezképekbe csomagolni, hogy megvédje tőlünk a jogi és szellemi tartalmait, illetve a buherátoroktól a készüléket.


Nézzük: mi van itt?!

Valahogy ki kéne tehát szednünk a készülékből a fordítani kívánt fájlokat. Alapvető gond ezzel, hogy a legtöbb esetben, ha tetszik, ha nem, rootolni kéne a készüléket. Amennyiben ezt szeretnénk elkerülni, akkor legalább annyit meg kell tennünk, hogy szerzünk egy custom recoveryt mellé. Szükségünk lesz tehát egy CWM, TWRP vagy egyéb NEM GYÁRI recoveryre, mert nincs harmadik út vagy recovery, vagy root, másképp nem fog menni.

Itt szögezném le, hogy recoverys módszer CSAK nyitott bootloader mellett fog menni, illetve ott sem garantálható, hogy nem kell kerülőutat keresnünk rögtön az elején.

Tehát mire is van szükség nagy hirtelen?

- Értelemszerűen maga a készülék és egy működő USB kábel. Erre kicsit lejjebb kitérek, miért említem külön.
- Működő kapcsolatok a számítógéppel, az ÖSSZES driver telepítve.
- Működő adb és fastboot, amik az Android SDK részei, a telepítésével a másik cikkemben már foglalkoztam részletesebben.
- Működő Linux Terminal vagy Terminal Emulator.

A recovery-metódus:

Lássuk előbb a recovery-s módszert, mert ez szokott egyszerűbb lenni!

Kapcsoljuk be az USB hibakeresést, ha PC-vel dolgozunk!
Indítsuk el a Terminalunk vagy az Emulatort és adjuk ki az:

adb reboot bootloader

...parancsot. Erre a készülék újraindul és rögtön a bekapcsolást követően nem bootol be többé, hanem vagy "lefagy" még az indító képernyőn, vagy valamilyen speciális menübe dob be, ahol esetleg még van valami teendőnk (HBoot, S-BOOT, Droidboot, kinek milyen készüléke van...).

Ha sikerrel jártunk, akkor most a Windows elégedetten nyugtázza, hogy talált egy másik eszközt, a Linuxon ezt nem fogjuk észrevenni. A Windows alatt figyeljünk, hogy a driver, amit ilyenkor kér NEM azonos azzal, amit bekapcsolt állapotban! Ez a bootloader driver.

Egy könnyed paranccsal nézzük is meg, hogy mindent jól csináltunk-e:

fastboot devices

Ha itt egy nevet látunk, akkor minden oké, ha nem, akkor bizony nem tettük fel a drivert... Fentebb írtam, hogy kell egy USB kábel: erre azt mondta egy szervizes, hogy szerviz USB kábel kell. Na most olyan nincsen, de semmi baj.

Most pedig indítsuk el a letöltött custom recovery fájlunk! (Vagy nem, erről picit később...) Ezt a következő paranccsal tehetjük meg:

fastboot boot recoveryfájlodneve.img

Ha szerencsénk van, pár másodperc múlva a választott recovery betöltődik és már nyomhatjuk is a backupot, amit később ki fogunk bontani. Ha nem, akkor rendszerint a készülék kijelzőjén is, illetve a Terminalban (Windows alatt parancssorban) is hibaüzenetet kapunk, hogy nem támogatja a rendszer ezt a boot eljárást. Kénytelenek vagyunk flashelni, ami kiváltképp akkor necces, ha nincs meg a gyári recovery, ugyanis azt ugye így nem tudtuk menteni... (Elő lehet állítani, nem kell pánikolni, erről kicsit később.)

Mindenesetre álljanak itt a parancsok, miként jutunk a recoverybe, ha mégiscsak flashelni kell:

fastboot flash recovery recoveryfájlodneve.img
fastboot reboot (Újraindul a készülék, várd meg még a rendszer felkel!)
adb reboot recovery

Mehet a mentés! Ha végeztünk, akkor az SD kártyán megtaláljuk a mentett romunkat. A korábbi verziós recoveryk rendre simg lemezképbe mentettek, aminek img a kiterjesztése, rendkívül fantáziadúsan, az újabbak tarball fájlokba csomagolnak, aminek tar.gz, de itt tessék vigyázni, mert a CWM alatt van olyan verzió, ami párfájlokat hoz létre: van egy tar.gz és egy nagyobb tar.gz.a, ami maga a mentés. Nyissuk meg a system- nevűt, hogy biztos jóval álljunk neki dolgozni! Persze kell hozzá valami a Windows alatt, ami kezeli, például Total Commander, mert a tarball nem támogatott alapesetben. Nem véletlen szajkózom a Linuxot!

A dd, avagy "kezdetben vala a Terminal"

Jó-jó, de mi van akkor, ha nincsen custom recovery? Most kaptunk egy vadi új telót, nincs semmi még. Kénytelenek vagyunk rootolni, mert másképp nem fogunk mi innen semmit leszedni, sem menteni. Számos megoldás létezik erre, de egyetlen biztos pont van bennük: bárhogy is csináljuk, nincs olyan Android, amit nem lehet rootolni. Nem azért, mert a rendszer túl sebezhető, hanem azért, mert mindig kell egy lehetőséget adni a fejlesztőknek is és ezt többnyire mások is megtalálják.

Miután "megtört" a védelem, a Terminal alól kezdjük el faggatni a kis droidot, hogy miként is látja a system meghajtóját. Az első és legrosszabb eset, hogy kb. sehogy, mert rejtve van. Ilyenkor jöhetnek a trükkök és a reménykedés, hogy valamelyiken "fennakad". Lássunk párat, a legnépszerűbbek közül:

A dmesg:

Ehhez két parancsot kell kiadnunk:

adb shell
dmesg

Jó hosszú listát kapunk. Ha szerencsénk van, valahol kiírja, hogy milyen meghajtókat csatolt. Kellemes szórakozás megtalálni... Szívhajuk a fogunk, ha nincs benne mégsem.

Az android.fstab

Többnyire lapul egy ilyen fájl a gyökérkönyvtárunkban, lássuk hát, mi van benne:

adb shell
cat android.fstab

Kapunk egy ilyesmi leírást:

#mount point fstype device device2 size hint flags and options...
/reserved hidden /dev/block/mmcblk0_none none size_hint=100
/factory ext4 /dev/block/mmcblk0p1 none size_hint=128
/system ext4 /dev/block/mmcblk0p2 none size_hint=768 ro
/cache ext4 /dev/block/mmcblk0p3 none size_hint=256 nosuid nodev noatime fsck data=ordered
/config ext4 /dev/block/mmcblk0p5 none size_hint=16 ro
/panic raw /dev/block/mmcblk0p6 none size_hint=2
/media vfat /dev/block/mmcblk0p7 none size_hint=512
/data ext4 /dev/block/mmcblk0p8 none size_hint=0,length=-16384 nosuid nodev noatime fsck noauto_da_alloc data=ordered
/logs ext4 /dev/block/mmcblk0p9 none size_hint=256
/mnt/sdcard vfat /dev/block/mmcblk1p1 /dev/block/mmcblk1 size_hint=-1

Mint láthatjuk, ezt egyszerűbb megtalálni és elég közlékeny is. Ezeket a blokkokat már menthetjük is a megfelelő paranccsal, amire kicsit később visszatérünk!

A mount parancs:

Mi sem egyszerűbb:

adb shell
mount

Kapunk egy listát, ebből is lehet szemezgetni:

rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
/dev/block/mmcblk0p2 /system ext4 ro,relatime,user_xattr,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p3 /cache ext4 rw,nosuid,nodev,noatime,user_xattr,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p5 /config ext4 ro,relatime,user_xattr,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p8 /data ext4 rw,nosuid,nodev,noatime,user_xattr,barrier=1,data=ordered,noauto_da_alloc 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mmcblk0p1 /factory ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p9 /data/logs ext4 rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
/dev/block/vold/179:7 /mnt/sdcard-ext vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1023,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:11 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:11 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /mnt/sdcard/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0
/dev/block/dm-0 /mnt/asec/com.opera.browser-2 vfat ro,dirsync,nosuid,nodev,relatime,uid=1000,fmask=0222,dmask=0222,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

Kicsit talán túl bőséges is...

Az MTK procis készülékeken az:

adb shell
cat /proc/dumchar_info

...lesz mérvadó.

A shellt az exit paranccsal tudjuk elhagyni.

A mentés:

Most, hogy már tudjuk, hogy melyik blokk a system, valahogy le kell szednünk a készülékről. Erre találták ki - többek közt - a dd parancsot.

Lássuk például a fenti készülékről miként készül mentés a systemből!

$ adb shell
$ su
# dd if=/dev/block/mmcblk0p2 of=/sdcard/system.img

A su parancs nyilván a Superuser jogok miatt kell, külön nem részletezném. A dd a diskdump mozaikszava: mindent ment egy menetben, tehát az üres helyet is, lehúzza a rendszert, ahogy van.

Az "if"-ben azt adjuk meg, ahonnan másolni szeretnénk, az "of"-ban pedig ahová másolunk. A dd képes a saját lemezképeit visszafelé is feldolgozni, tehát a:

$ dd if=/sdcard/system.img of=/dev/block/mmcblk0p2

...elvben a rendszert cseréli ki. Nyilván nem nagyon szokott ez menni a gyakorlatban, mert egyik rendszer sem lesz "öngyilkos", tehát nem cseréli ki saját magát. Viszont, ha a recoveryt szeretnénk flashelni, azzal minden további nélkül végig tudjuk ezt csinálni. Feltéve, ha most felnézve nem merül fel az a kérdés, mint az itt modellnek használt készüléknél: "Oké... és hol van ezen a recovery?!".

Ha éppen sehol, de nekünk kell a gyári, akkor bizony azt elő kell állítani, amihez 4 dolog kell:

ApplyPatch bináris

Valamint a rendszerből a recovery-from-boot.p fájl, az install-recovery.sh, valamit a boot.img. Az első kettőt többnyire a recovery mappában találjuk meg.

Az install-recovery.sh fájlt nyissuk meg, kb. így néz ki:

#!/system/bin/sh
update_recovery --check-sha1 c9e2cd20b9119b87839652ebcc3d64006663827e \
--src-sha1 b45133d10bef32df8f53838b5141a6d302b79010 \
--tgt-sha1 aa0dc7245bca09dd5146509866d6778c9ad940a6 \
--tgt-size 8478720 \
--patch /system/recovery-from-boot.p

Másoljuk a boot.img fájlunk és a recovery-from-boot.p fájlunk az applypatch könyvtárába, most pedig adjuk ki ezt a parancsot:

$ ./applypatch_static <src-file> <tgt-file> <tgt-sha1> <tgt-size> <src-sha1>:<patch>

Természetesen a fenti számsorokkal és fájlokkal behelyettesítve:

$ ./applypatch_static boot.img recovery.img aa0dc7245bca09dd5146509866d6778c9ad940a6 8478720 b45133d10bef32df8f53838b5141a6d302b79010:recovery-from-boot.p

Pár másodperc és a gyári recovery fájlunk előáll.

Miután most már ismerjük a fájlrendszerünk típusát, már csatolhatjuk is a lemezképünk, hogy kiszedjük belőle a rendszert. Windows alatt erre már most szólok: nagyjából nulla lehetőségünk van, illetve jelentősen korlátozottabbak azok is, mint Linuxon.

A cikk még nem ért véget, kérlek, lapozz!

Azóta történt

Előzmények

Hirdetés

Copyright © 2000-2024 PROHARDVER Informatikai Kft.