Obtuve una imagen de Android que contiene:
-rwxr-xr-x 1 root root 69206016 Dec 16 17:01 cache.img
-rwxr-xr-x 1 root root 6024864 Mar 23 2016 Image
-rwxr-xr-x 1 root root 1108329 Mar 7 2016 ramdisk.img
-rwxr-xr-x 1 root root 943718400 Mar 7 2016 system.img
-rwxr-xr-x 1 root root 576716800 Dec 16 17:02 userdata.img
Y se puede iniciar mediante un emulador de Android con:
./emulator64-ranchu-arm64 -system ./system.img -data ./userdata.img -ramdisk ./ramdisk.img -kernel ./Image -cache ./cache.img -sysdir ./ -no-window -verbose -show-kernel
O use qemu directamente:
./qemu/linux-x86_64/qemu-system-aarch64 -cpu cortex-a57 -machine type=ranchu -m 512 -append 'console=ttyAMA0,38400 keep_bootcon earlyprintk=ttyAMA0' -serial mon:stdio -kernel .//Image -initrd .//ramdisk.img -drive index=0,id=sdcard,file=.//system.img -device virtio-blk-device,drive=sdcard -drive index=1,id=userdata,file=.//.//userdata.img -device virtio-blk-device,drive=userdata -drive index=2,id=cache,file=.//cache.img -device virtio-blk-device,drive=cache -drive index=3,id=system,file=.//system.img -device virtio-blk-device,drive=system -netdev user,id=mynet -device virtio-net-device,netdev=mynet -show-cursor -nographic -L lib/pc-bios
Ahora quiero extraer el código del kernel pero esta imagen parece diferente. Los pasos habituales: encontrar el desplazamiento de los datos gzip, dividirlos usando dd, usar gzip para obtener vmlinux, no funciona en él. Aquí está la información obtenida de esta imagen:
root@Debian:~$ file Image
Image: data
root@Debian:~$ binwalk Image
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
4395136 0x431080 Linux kernel version "3.10.0+ (root@jiayy) (gcc version 4.9.x-google 20140827 (prerelease) (GCC) ) #63 SMP PREEMPT Wed Mar 23 11:27:47 CST 2016"
4407688 0x434188 gzip compressed data, maximum compression, from Unix, NULL date (1970-01-01 00:00:00)
5270000 0x5069F0 Unix path: /data2/kernel/goldfish/arch/arm64/include/asm/pgalloc.h
5347656 0x519948 Ubiquiti partition header, header size: 56 bytes, name: "PARTNAME=%s", base address: 0x63697479, data size: 0 bytes
5367856 0x51E830 Unix path: /lib/firmware/updates/3.10.0+
5382775 0x522277 Unix path: /net/ethernet/smsc/smc91x.c
5410863 0x52902F Unix path: /staging/android/ion/ion.c
5412463 0x52966F Unix path: /staging/android/ion/ion_heap.c
5412663 0x529737 Unix path: /staging/android/ion/ion_page_pool.c
5412823 0x5297D7 Unix path: /staging/android/ion/ion_system_heap.c
5443853 0x53110D Copyright string: "Copyright (c) 2006-2007 BalaBit IT Ltd."
5483104 0x53AA60 Neighborly text, "NeighborSolicits"
5483128 0x53AA78 Neighborly text, "NeighborAdvertisementsErrors"
5488754 0x53C072 Neighborly text, "neighbor %.2x%.2x.%pM lost rename link %s to %s"
5710184 0x572168 ASCII cpio archive (SVR4 with no CRC), file name: "dev", file name length: "0x00000004", file size: "0x00000000"
5710300 0x5721DC ASCII cpio archive (SVR4 with no CRC), file name: "dev/console", file name length: "0x0000000C", file size: "0x00000000"
5710424 0x572258 ASCII cpio archive (SVR4 with no CRC), file name: "root", file name length: "0x00000005", file size: "0x00000000"
5710540 0x5722CC ASCII cpio archive (SVR4 with no CRC), file name: "TRAILER!!!", file name length: "0x0000000B", file size: "0x00000000"
5754880 0x57D000 ELF, 64-bit LSB shared object, version 1 (SYSV)
5760064 0x57E440 CRC32 polynomial table, little endian
root@Debian:~$ xxd -g 1 Image|head
0000000: 10 00 00 14 00 00 00 00 00 00 08 00 00 00 00 00 ................
0000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000030: 00 00 00 00 00 00 00 00 41 52 4d 64 00 00 00 00 ........ARMd....
0000040: f5 03 00 aa 72 00 00 94 0e 00 00 94 16 00 38 d5 ....r.........8.
0000050: e0 03 16 aa fb 00 00 94 f7 03 00 aa 97 1e 00 b4 ................
0000060: 0a 01 00 94 73 00 00 94 9b 1a 00 58 3e 0b 00 10 ....s......X>...
0000070: ec 0a 40 f9 8c 01 1c 8b 80 01 1f d6 1f 20 03 d5 ..@.......... ..
0000080: 40 42 38 d5 1f 20 00 f1 04 18 49 fa 20 17 00 58 @B8.. ....I. ..X
0000090: 00 00 1c 8b 60 00 00 54 1f 00 00 b9 c0 03 5f d6 ....`..T......_.
El archivo de configuración del kernel se puede extraer del desplazamiento 0x434188 (corresponde al segundo segmento en la salida de binwalk). También intenté usar extract-vmlinux.sh de google git (https://android.googlesource.com/kernel/goldfish/+/android-goldfish-3.10-m-dev/scripts/extract-vmlinux) pero tampoco funcionó.
Entonces, ¿qué formato tiene esta imagen del núcleo y cómo puedo extraer el código del núcleo de ella?
Respuesta1
Sé que llegué un poco tarde a la fiesta, pero estaba tratando con una imagen de vmlinux muy similar a la del autor de la pregunta. Desensamblar una imagen del kernel sin formato como esta y analizar el código es una tarea monstruosa cuando todo lo que tienes es el resultado de aarch64-linux-gnu-objdump -b binary -maarch64 -EL -D vmlinux.
Afortunadamente, alguna alma hermosa escribió una herramienta para convertir imágenes vmlinux sin procesar a formato binario ELF. Esta imagen no es ejecutable, pero un depurador/desensamblador como gdb oCortador. También intentará encontrar los símbolos incrustados y resolverlos en el archivo ELF de salida. La herramienta, llamada vmlinux-to-elf, se puede encontraraquí
Enlaces:
Respuesta2
Esta imagen del kernel es la parte binaria sin formato de arranque de vmlinux, lo que significa que no es un archivo ELF completo. Simplemente desmóntelo desde el principio para obtener el código del kernel.