Objekt: Autoradio auf Androidbasis

Ziel kurzfristig: Verbesserungen wie insecure Kernel, Mountpunkte, Repartitionierung

Ziel langfristig: Custom Kernel, gglfs. Portierung von CM

Im ersten Schritt geht es erst einmal um die Informationsbeschaffung:

Analyse der Partitionen (cat (/proc/partitions):

 179 0 3866624 mmcblk0 <-- Device Interner Speicher 
 179 1 512 mmcblk0p1 <-- Bootloader STAGE 2 (uboot.bin) - aber leer im Betrieb
 179 2 6144 mmcblk0p2 <-- Bitmap = Bootlogo 1024*600*32
 179 3 16384 mmcblk0p3 <-- uImage (Recovery) 10107413 bytes
 179 4 8192 mmcblk0p4 <-- uImage 8364759 bytes (Kernel?)
 179 5 655360 mmcblk0p5 <-- ext4 Filessystem /system (build.prop etc)
 179 6 698368 mmcblk0p6 <-- ext2 Filesystem /userdata
 179 7 307200 mmcblk0p7 <-- ext2 Filesystem /cache 
 259 0 8192 mmcblk0p8 <-- pqbin Partition - PQ Boot Magic? WTF? sieht eher aus wie ein Kernelbackup bzw. der Recoverykernel?
 259 1 131072 mmcblk0p9 <-- ext2 Filesystem (custcon partition) /img2 (app, lost+found, cartype.xml, factory.prop etc.)
 259 2 393216 mmcblk0p10 <-- ext2 Filesystem Backup (boot.img, recovery.img und system.img)
 259 3 1615356 mmcblk0p11 <-- Fat Partition - Interner Speicher /sdcard 
 179 16 2048 mmcblk0boot1 <-- ausgenullt
 179 8 2048 mmcblk0boot0 <-- ausgenullt
 179 24 31341568 mmcblk1 <-- Device SD Karte 1
 179 25 31337472 mmcblk1p1 <-- Partition von SD Karte 1
 179 32 31341568 mmcblk2 <-- Device SD Karte 2
 179 33 31337472 mmcblk2p1 <-- Partition von SD Karte 2

“ Recovery“ Filesysteme:

# mount point	  fstype  device  [device2]

/misc             emmc    /dev/block/mmcblk0p1
/bootlogo         emmc    /dev/block/mmcblk0p2
/recovery         emmc    /dev/block/mmcblk0p3
/boot             emmc    /dev/block/mmcblk0p4
/system           ext4    /dev/block/mmcblk0p5
/data             ext4    /dev/block/mmcblk0p6
/cache            ext4    /dev/block/mmcblk0p7
/sdcard	          vfat    /dev/block/mmcblk1 /dev/block/mmcblk1p1
/mnt/sdcard       vfat    /dev/block/mmcblk1 /dev/block/mmcblk1p1

Was auf den ersten Blick fehlt: MBR (vermutlich Sektor 0) und STAGE 1 Bootloader… – rund 16 Blöcke.

Und wie sind die aktuellen Mountpoints:

Filesystem Size Used Free Blksize
Filesystem             Size   Used   Free   Blksize
/dev                   498M   104K   497M   4096
/mnt/usb               498M     0K   498M   4096
/mnt/sd                498M     0K   498M   4096
/mnt/asec              498M     0K   498M   4096
/mnt/obb               498M     0K   498M   4096
/system                377M   303M    74M   4096
/mnt/config            123M    95M    28M   1024
/data                  671M   566M   104M   4096
/cache                 290M    13K   290M   1024
/mnt/sd/mmcblk2p1       29G     4G    25G   16384
/mnt/sd/mmcblk0p11       1G    28M     1G   4096
/mnt/sdcard             29G     3G    26G   16384
/mnt/secure/asec        29G     3G    26G   16384

Hardware... welche CPU?

Es handelt sich offenbar um eine Mstar CPU – Cortex-A9, Mst786 (mstar/cedric) @ 1 Ghz.

Processor	: ARMv7 Processor rev 0 (v7l)
processor	: 0
BogoMIPS	: 1784.21

processor	: 1
BogoMIPS	: 1784.21

Features	: swp half thumb fastmult vfp edsp neon vfpv3 tls 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x3
CPU part	: 0xc09
CPU revision	: 0

Hardware	: cedric
Revision	: 0000
Serial		: 0000000000000000

Was wissen wir über den Kernel?

Linux version 3.4.5 (server@buildserver03) (gcc version 4.7.2 20120701 (prerelease) (crosstool-NG linaro-1.13.1-2012.07-20120720 - Linaro GCC 2012.07) ) #1 SMP Tue Jul 1 10:48:51 CST 2014

Unangenehm: Es gibt scheinbar kein ADB Zugang – obwohl der verwendete u-boot Bootloader das sicher kann. Hier muss noch geforscht werden – denn ein System komplett ohne Recovery ist nicht wünschenswert.

Das Updatepaket eröffnet dann endlich ein paar Möglichkeiten und vor allem Einblick über den Flash wie auch Bootvorgang. Neben ein paar Scripten enthält das Updatepaket einige höchst verdächtige Files:

boot.img <– wird wohl der Kernel sein. Leider nicht im Standardformat (kein ANDROID! Magic) sondern als uImage, nicht komprimiert.
cboot.img
PQ.bin
recovery.img <– die Recovery, die aus dem System heraus leider sowieso nicht erreichbar ist. Auch hier nicht komprimiertes uImage.
uboot.bin <— aahh… offenbar ein u-boot loader!
ui.bin
rtk.bin
system.img.lzo
uramdisk.img <– die Ramdisk, gleiches Format wie Kernel und Recovery.

Als nächstes soll der Kernel analysiert werden. Hierzu benötigen wir normalerweise die „klassischen“ bootimg_tools (split_boot, unpack_ramdisk) etc. Diese funktionieren aufgrund unseres Formates leider nicht – egal, dann so sparen wir uns das aufsplitten in Kernel, Ramdisk und Header.

Jedenfalls sollten wir zb. ubuntu überzeugen, doch flott das Paket u-boot-tools zu installieren, womit wir boot.img näher anschauen können:

android@builduntu:~/android/kernel/$ mkimage -l boot.img
Image Name: MStar-linux
Created: Tue Apr 15 18:31:51 2014
Image Type: ARM Linux Multi-File Image (uncompressed)
Data Size: 8298014 Bytes = 8103.53 kB = 7.91 MB
Load Address: 40a08000
Entry Point: 40a08000
Contents:
Image 0: 8123780 Bytes = 7933.38 kB = 7.75 MB
Image 1: 174222 Bytes = 170.14 kB = 0.17 MB

Aha – also ein ARM Linux Multi-File Image laut dem Header. Dann graben wie mal weiter und sehen uns die beiden Images an. Hierfür müssen wir den 64 Byte Header abschneiden, sowie 4 byte image 1 size plus 4 byte null terminator -> dh. 76 bytes. Dann können wir das erste Image mit 8123780 bytes und das zweite mit 174222 bytes extrahieren. Achtung – diese sind dann wieder jeweils ein uImage! (76 Byte Header === Image 1 ==== Image 2)

android@builduntu:~/android/kernel$ dd if=boot.img of=boot.image1 bs=1 skip=76 count=8123780
8123780+0 records in
8123780+0 records out
8123780 bytes (8,1 MB) copied, 10,8443 s, 749 kB/s
android@builduntu:~/android/kernel$ dd if=boot.img of=boot.image2 bs=1 skip=8123856 count=174222
174222+0 records in
174222+0 records out
174222 bytes (174 kB) copied, 0,232809 s, 748 kB/s

Soweit die Theorie – doch leider zeigt und file(1) bzw. mkimage -l noch nicht den Kernel an – wird aber sehr wohl der Kernel sein. Jedenfalls haben wir die Trennung des Images schonmal an der richtigen Stelle gemacht, denn das 2. File beginnt mit den wohlbekannten Code 1F 8B 08 -> dh. hier beginnt ein gzip File!

android@builduntu:~/android/kernel$ zcat boot.image2 > boot2
android@builduntu:~/android/kernel$ file boot2
boot2: ASCII cpio archive (SVR4 with no CRC)

Aha! Also CPIO gepackt…

android@builduntu:~/android/kernel/$ cpio -t < boot2
.
init.rc
proc
init.rc~
config
config/mmap.ini
init.usb.rc
ueventd.cedric.rc
init.trace.rc#
ueventd.rc
data
ueventd.goldfish.rc
init.goldfish.rc
sbin
sbin/adbd
sbin/ueventd
dev
sys
default.prop
init
system
701 blocks

Sieht wie das Basisverzeichnis aus… sehr gut! Und was finden wir im default.prop?

# ADDITIONAL_DEFAULT_PROPERTIES
ro.secure=1
ro.allow.mock.location=0
ro.debuggable=1
persist.sys.usb.config=adb

BINGO! Die Einstellung ro.secure=1 verhindert, dass das Rooten des Gerätes funktioniert bzw. /system als r/w remounted werden kann. Na das werden wir jetzt doch mal ändern 🙂

Des weiteren finden wir im init.rc nun die Mountpoints, die bis dato sehr ungeschickt gesetzt waren. Auf gehts – abändern und das File in umgekehrter Reihenfolge wieder zusammenbauen.

Grundsätzlich gibt es für den Bootvorgang also folgendes festzuhalten:

Kein Standardbootloader von AOSP, sondern es kommt u-boot zum Einsatz
Die Imagefiles (boot.img, recovery.img, uramdisk.imrg) verwenden ein anderes Format (uImage) – daher kein „Magic ANDROID!“ vorhanden
Der u-boot Bootloader scheint OHNE Fastboot Support compiliert zu sein
Was wir sonst als Recovery kennen, wird zum Updaten des Systems missbraucht (flash-ok.sh)
boot.img, recovery.img und uramdisk haben dieselben entry- und load adresses.
Da sich das Flashscript via init-setup bereits mit der Ramdisk geladen wird, muss der Trigger (Update oder nicht? Oder anders: Ist eine SD eingelegt mit update/ Verzeichnis?) bereits am Ende des Bootloaders liegen.

Sieht also eher schlecht aus, jemals eine vernünftige Recovery oder Fastboot zu erhalten ohne den Bootloader zu tauschen. Und dies wiederrum ohne Recovery…. – ein heisser Ritt!

Und für alle Fälle hier noch eine kleine Hilfe über die benötigten Befehle fürs ent- bzw. repacken!

System.img:

Extract:
lzop -d system.img.lzo
-> dann als ext4 mounten
Repack:
chmod 644 system.img
lzop -o system.img.lzo system.img
chmod 766 system.img.lzop

boot/ramdisk/recovery Images:

Extract:
mkimage -l boot.img 
dd if=boot.img of=boot.image1 bs=1 skip=76 count=8123780
dd if=boot.img of=boot.image2 bs=1 skip=8123856 count=174222
mkdir boot2-inhalt
cd boot2-inhalt/
zcat ../boot.image2 | cpio -i

Info: 76 Header, dann Image1 gefolgt von Image2. skip/count ausrechnen!

Repack:
cd boot2-inhalt
find . | cpio -o -H newc | gzip > ../ramdisk.image2.changed
mkimage -A arm -T multi -C none -n 'Cardroid-linux' -a 40a08000 -e 40a08000  -d ../ramdisk.image1:ramdisk.image2.changed uramdisk.img

Format der uImages:

android@builduntu:~/android/kernel/neue/work$ mkimage -l ../update/images/boot.img 
Image Name:   MStar-linux
Created:      Mon Jun 30 20:19:35 2014
Image Type:   ARM Linux Multi-File Image (uncompressed)
Data Size:    8364759 Bytes = 8168.71 kB = 7.98 MB
Load Address: 40a08000
Entry Point:  40a08000
Contents:
   Image 0: 8190724 Bytes = 7998.75 kB = 7.81 MB
   Image 1: 174023 Bytes = 169.94 kB = 0.17 MB
android@builduntu:~/android/kernel/neue/work$ mkimage -l ../update/images/recovery.img 
Image Name:   MStar-linux(recovery)
Created:      Tue Sep 23 01:14:34 2014
Image Type:   ARM Linux Multi-File Image (uncompressed)
Data Size:    10107413 Bytes = 9870.52 kB = 9.64 MB
Load Address: 40a08000
Entry Point:  40a08000
Contents:
   Image 0: 8206724 Bytes = 8014.38 kB = 7.83 MB
   Image 1: 1900677 Bytes = 1856.13 kB = 1.81 MB
android@builduntu:~/android/kernel/neue/work$ mkimage -l ../update/bin/uramdisk.img 
Image Name:   Cardroid-linux
Created:      Wed May  7 22:31:53 2014
Image Type:   ARM Linux Multi-File Image (uncompressed)
Data Size:    10333459 Bytes = 10091.27 kB = 9.85 MB
Load Address: 40a08000
Entry Point:  40a08000
Contents:
   Image 0: 8123780 Bytes = 7933.38 kB = 7.75 MB
   Image 1: 2209667 Bytes = 2157.88 kB = 2.11 MB
android@builduntu:~/android/kernel/neue/work$

Hier gehts zum entsprechenden Custom Rom!

build.prop – Galaxy Nexus lässt grüssen! 🙂

# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=JRO03C
ro.build.display.id=CA03-N043-TY02-A3-r0.7.713s
ro.build.version.incremental=0.7.713s
ro.build.version.sdk=16
ro.build.version.codename=REL
ro.build.version.release=4.1.1
ro.build.date=Wed Sep 17 10:27:40 CST 2014
ro.build.date.utc=1410920860
ro.build.type=userdebug
ro.build.user=server
ro.build.host=buildserver01
ro.build.tags=test-keys
ro.product.model=CA03
ro.product.brand=cardroid
ro.product.name=CA03
ro.product.device=CA03
ro.product.board=
ro.product.cpu.abi=armeabi-v7a
ro.product.cpu.abi2=armeabi
ro.product.manufacturer=cardroid
ro.product.locale.language=en
ro.product.locale.region=US
ro.wifi.channels=
ro.board.platform=cedric
# ro.build.product is obsolete; use ro.product.device
ro.build.product=CA03
# Do not try to parse ro.build.description or .fingerprint
ro.build.description=CA03-userdebug 4.1.1 JRO03C 0.7.713s test-keys
ro.build.fingerprint=cardroid/CA03/CA03:4.1.1/JRO03C/0.7.713s:userdebug/test-keys
ro.build.characteristics=default
# end build properties
ms.mstplayer=1
ms.mstplayer.logless=1
hw.ms.display.destination=3
hw.ms.sc1_sync_sc0=1
hw.ms.hdmitx_timing=480_60P
hw.ms.hdmitx_color=YUV
ro.ms.System.bDualScreen=true
debug.sf.electron_frames=1
ms.subchannel.audio=1

Flash – Log:

1970-01-01 00:14:06: INFO: SD flash tool 2.0 start ...
1970-01-01 00:14:07: INFO: source device is /dev/block/mmcblk1
1970-01-01 00:14:07: INFO: target device is /dev/block/mmcblk0
1970-01-01 00:14:07:  
1970-01-01 00:14:08: mount SD card: mount /dev/block/mmcblk1 to /src ... 
1970-01-01 00:14:08: Running: mount /dev/block/mmcblk1 /src
mount: mounting /dev/block/mmcblk1 on /src failed: Invalid argument
1970-01-01 00:14:08: return code is: 255
1970-01-01 00:14:08:  
1970-01-01 00:14:08: mount SD card: mount /dev/block/mmcblk1p1 to /src ... 
1970-01-01 00:14:08: Running: mount /dev/block/mmcblk1p1 /src
1970-01-01 00:14:08: return code is: 0
1970-01-01 00:14:08: OK
1970-01-01 00:14:08: checking image directory ... 
1970-01-01 00:14:08: OK
1970-01-01 00:14:08: read md5sum info ... 
1970-01-01 00:14:08: OK
1970-01-01 00:14:08: checking md5sum for image boot.img ... 
1970-01-01 00:14:09: OK
1970-01-01 00:14:09: checking md5sum for image system.img.lzo ... 
1970-01-01 00:14:35: OK
1970-01-01 00:14:35: checking md5sum for image recovery.img ... 
1970-01-01 00:14:37: OK
1970-01-01 00:14:37: checking md5sum for image PQ.bin ... 
1970-01-01 00:14:37: OK
1970-01-01 00:14:37: checking md5sum for image rtk.bin ... 
1970-01-01 00:14:37: OK
1970-01-01 00:14:37: checking md5sum for image uboot.bin ... 
1970-01-01 00:14:37: OK
1970-01-01 00:14:37: checking md5sum for image cboot.bin ... 
1970-01-01 00:14:37: OK
1970-01-01 00:14:37: checking md5sum for image ui.bin ... 
1970-01-01 00:14:37: OK
1970-01-01 00:14:41: Compare rtk.bin
1970-01-01 00:14:41: OK
1970-01-01 00:14:43: Compare uboot.bin
1970-01-01 00:14:43: OK
1970-01-01 00:14:43: Compare cboot.bin
1970-01-01 00:14:43: OK
1970-01-01 00:14:47: Compare ui.bin
1970-01-01 00:14:47: OK
1970-01-01 00:14:47: flash image: boot please wait ... 
1970-01-01 00:14:47: Running: dd if=/src/update/images/boot.img of=/dev/block/mmcblk0p4 bs=4096
2046+1 records in
2046+1 records out
8381869 bytes (8.0MB) copied, 1.197576 seconds, 6.7MB/s
1970-01-01 00:14:48: return code is: 0
1970-01-01 00:14:48: OK
1970-01-01 00:14:48: flash image: logo.bmp please wait ... 
1970-01-01 00:14:48: Running: dd if=/src/update/images/logo.bmp of=/dev/block/mmcblk0p2 bs=4096
600+1 records in
600+1 records out
2457656 bytes (2.3MB) copied, 0.619101 seconds, 3.8MB/s
1970-01-01 00:14:49: return code is: 0
1970-01-01 00:14:49: OK
1970-01-01 00:14:49: flash image: PQ value settings please wait ... 
1970-01-01 00:14:49: Running: dd if=/src/update/images/PQ.bin of=/dev/block/mmcblk0p8 bs=4096
427+1 records in
427+1 records out
1751412 bytes (1.7MB) copied, 0.265540 seconds, 6.3MB/s
1970-01-01 00:14:49: return code is: 0
1970-01-01 00:14:49: OK
1970-01-01 00:14:49: flash image: recovery image please wait ... 
1970-01-01 00:14:49: Running: dd if=/src/update/images/recovery.img of=/dev/block/mmcblk0p3 bs=4096
2468+1 records in
2468+1 records out
10110457 bytes (9.6MB) copied, 1.450816 seconds, 6.6MB/s
1970-01-01 00:14:51: return code is: 0
1970-01-01 00:14:51: OK
1970-01-01 00:14:51: make backup partition ... 
1970-01-01 00:14:51: Running: mke2fs -j /dev/block/mmcblk0p10
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
98304 inodes, 393216 blocks
19660 blocks (5%) reserved for the super user
First data block=1
Maximum filesystem blocks=524288
48 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks:
	8193, 24577, 40961, 57345, 73729, 204801, 221185
1970-01-01 00:14:55: return code is: 0
1970-01-01 00:14:55: OK
1970-01-01 00:14:55: mount backup partition ... 
1970-01-01 00:14:55: Running: mount /dev/block/mmcblk0p10 /img2
1970-01-01 00:14:55: return code is: 0
1970-01-01 00:14:55: OK
1970-01-01 00:14:55: copy /img2/system.img.lzo for backup ... 
1970-01-01 00:15:14: OK
1970-01-01 00:15:27: check md5sum for /img2/system.img.lzo
1970-01-01 00:15:27: OK
1970-01-01 00:15:27: copy /img2/recovery.img for backup ... 
1970-01-01 00:15:27: OK
1970-01-01 00:15:28: check md5sum for /img2/recovery.img
1970-01-01 00:15:28: OK
1970-01-01 00:15:28: copy /img2/boot.img for backup ... 
1970-01-01 00:15:28: OK
1970-01-01 00:15:29: check md5sum for /img2/boot.img
1970-01-01 00:15:29: OK
1970-01-01 00:15:32: program system.img.lzo  ... 
1970-01-01 00:16:24: OK
1970-01-01 00:16:24: make config partition ... 
1970-01-01 00:16:25: OK
1970-01-01 00:16:25: mount config partition ... 
1970-01-01 00:16:25: OK
1970-01-01 00:16:41: clear userdata ... 
1970-01-01 00:16:41: Running: mke2fs -j dev/block/mmcblk0p6
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
65536 inodes, 262144 blocks
13107 blocks (5%) reserved for the super user
First data block=0
Maximum filesystem blocks=4194304
8 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376
1970-01-01 00:16:44: return code is: 0
1970-01-01 00:16:44: OK
1970-01-01 00:16:44: clear Resident SD data ... 
1970-01-01 00:16:44: Running: mkfs.vfat dev/block/mmcblk0p11
1970-01-01 00:16:44: return code is: 0
1970-01-01 00:16:44: OK
1970-01-01 00:16:44: clear cache data ... 
1970-01-01 00:16:44: Running: mke2fs -j dev/block/mmcblk0p7
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
76912 inodes, 307200 blocks
15360 blocks (5%) reserved for the super user
First data block=1
Maximum filesystem blocks=524288
38 block groups
8192 blocks per group, 8192 fragments per group
2024 inodes per group
Superblock backups stored on blocks:
	8193, 24577, 40961, 57345, 73729, 204801, 221185
1970-01-01 00:16:47: return code is: 0
1970-01-01 00:16:47: OK
1970-01-01 00:16:47: clear misc partition ... 
1970-01-01 00:16:47: OK
1970-01-01 00:16:47: syncing target device ... 
1970-01-01 00:16:47: Running: sync /dev/block/mmcblk0
sync: ignoring all arguments
1970-01-01 00:16:47: return code is: 0
1970-01-01 00:16:47: OK
1970-01-01 00:16:47: umount /src ...

Kommentare

4 Antworten zu „Analyse AV7 + plus build.prop Mod“

AV7 Bootprozess | valki.com

15. Dezember 2014

[…] komischerweise trifft das auch auf z.b. das default.prop zu – dennoch wurde der Kernel insecure geladen. […]
AV7 Custom Rom Valki | valki.com

19. Dezember 2014

[…] das Gerät, deshalb musste ich an mehreren Stellen das “Rad neu erfinden” und alles durchtesten. Dass es derzeit kein ADB / Fastboot Zugang gibt, hilft überhaupt nicht […]
Artur

19. Juni 2018

Ist es möglich die custom rom erneut hochzuladen?
valki

19. Juni 2018

Sollte alles online sein… Falls du etwas vermisst, bitte um Info welcher Link genau offline ist! Lg

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.