Как разобрать(разархивировать) образ u-boot uImage

Ну а что говорит

file demo.bin

demo.bin: u-boot legacy uImage

Попробуй поставить пакет u-boot-tools (так он в Debian называется, по крайней мере). Там есть утилита dumpimage, ей можно вытащить куски. Сначала запросить состав образа, так как там может быть несколько частей.

Что то я не понимаю как распаковать, position что писать и outfile - это директория или что?

Usage: dumpimage -l image
          -l ==> list image header information
       dumpimage -i image -T type [-p position] [-o outfile] data_file
          -i ==> extract from the 'image' a specific 'data_file'
          -T ==> set image type to 'type'
          -p ==> 'position' (starting at 0) of the 'data_file' inside the 'image'
       dumpimage -V ==> print version information and exit

Ну я точно не знаю. У меня тут нет таких файлов. Надо скачать. Я так понимаю, что тебе надо сначала посмотреть, что там лежит. Это опцией -l делаешь. Там он покажет, скажем, что там одна-две-три части (образ ядра, файловое дерево и т. д.). Я так понимаю, что -p будет указывать номер этой части (0, 1, 2...). Вот все их последовательно надо вытащить опцией -i и сохранить в разные файлы. Потом эти файлы отдельно смотреть, что там.

Информации мало и все тоже самое

dumpimage -l demo.bin
Image Name:   jz_fw
Created:      Sat Mar 21 13:10:07 2020
Image Type:   MIPS Linux Firmware (uncompressed)
Data Size:    11075584 Bytes = 10816.00 KiB = 10.56 MiB
Load Address: 00000000
Entry Point:  00000000

Ну, попробуй тогда просто без -p. Мне трудно вслепую советовать определенно. Попробуй просто:

$ dumpimage -i demo.bin image-0
$ dumpimage -i demo.bin -p 1 image-1

Если там только одна часть - нулевая, то на остальные он ругнется. Неужели тебе страшно попробовать без совета? Файл не испортится. Потом скажешь, что получается.

Вообще, конечно, уже мог бы поиском воспользоваться, а не на каждую закорючку вопросы задавать. :)

Если какие-то файлы вылезут, то потом сделай file image-0 и посмотри что там. Если этот файл один всего. то это, скорее всего, kernel image пожатый. Что-то типа LZMA или gzip. Наверное.

Получается полная ерудна не зависимо от значения -p (1,2,100,200....) выходной файл получается один и тот же

dumpimage -i demo.bin -p 100 image-1

file image-1
image-1: u-boot legacy uImage, Linux-3.10.14, 
Linux/MIPS, OS Kernel Image (lzma), 1816781 bytes, 
Fri Mar 20 15:44:39 2020, 
Load Address: 0x80010000, Entry Point: 0x803E9230, 
Header CRC: 0x7771D66A, Data CRC: 0xBDC20C2D

Мне кажется что -p нужно задавать в байтах как начало и конец, но как узнать где начало и конец?

Можно binwalk использовать, натравить его и получить структуру. Файл этот, скорее всего, слеплен из нескольких разделов squashfs и их надо вытащить по отдельности, зная смещения. А что за файл. Я его могу где-то взять? Гляну.

Image Name: jz_fw

Я тут сам быстро поискал. Это какая-то камера Xiaomi Dafang? скачал я какую-то прошивку. Если так, то по binwalk я думаю, что тут четыре части в образе после снятия заголовка при помощи dumpimage:

0x000000 - пожатое ядро.

0x200000 - rootfs. (squashfs, сжатие xz)

0x550000 - это драйвера (squashfs, сжатие xz)

0x5f0000 - а тут и до конца приложения начинаются, должно быть (размер 0x4a0000).

То есть тебе нужно разобрать образ на кусочки: kernel, rootfs, drivers, apps, распаковать при помощи unsquashfs файл drivers, добавить свой драйвер, запаковать при помощи mksquashfs с правильными параметрами дерево драйверов назад, собрать из кусочков образ назад.

Да ты прав это камера Xiaomi Xiafang, прошивку которую я хочу расковырять можно взять от сюда demo.bin

В общем, смотри. Если я с файлом угадал, то разобрать на кусочки можно так.

$ dumpimage -i demo.bin image.bin
$ dd if=image.bin bs=64K skip=0 count=32 of=kernel
$ dd if=image.bin bs=64K skip=32 count=53 of=rootfs
$ dd if=image.bin bs=64K skip=85 count=10 of=drivers
$ dd if=image.bin bs=64K skip=95 of=apps
$ # Смотрим информацию
$ unsquashfs -s drivers
$ # Распаковываем
$ unsquashfs drivers

Сразу вопрос зачем нужно делать dumpimage -i demo.bin image.bin, почему нельзя сразу работать с demo.bin?

И вот что мне выдал binwalk, после dumpimage -i demo.bin image.bin, хотя и с demo.bin тоже самое.

binwalk  image.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0x7771D66A, 
                              created: 2020-03-20 15:44:39, image size: 1816781 bytes, 
							  Data Address: 0x80010000, Entry Point: 0x803E9230, data CRC: 0xBDC20C2D, 
							  OS: Linux, CPU: MIPS, image type: OS Kernel Image, 
							  compression type: lzma, image name: "Linux-3.10.14"
64            0x40            LZMA compressed data, properties: 0x5D, dictionary size: 67108864 bytes, 
                              uncompressed size: -1 bytes
2097152       0x200000        Squashfs filesystem, little endian, version 4.0, compression:xz, 
                              size: 3353204 bytes, 407 inodes, blocksize: 131072 bytes, 
							  created: 2019-05-21 17:22:45
5570560       0x550000        Squashfs filesystem, little endian, version 4.0, compression:xz, 
                              size: 583802 bytes, 13 inodes, blocksize: 131072 bytes, 
							  created: 2020-02-23 16:07:18

Сразу вопрос зачем нужно делать dumpimage -i demo.bin image.bin, почему нельзя сразу работать с demo.bin?

Потому что в demo.bin заголовок 64 байта от u-boot legacy uImage, который надо убрать. Его можно убрать и dd. Тогда тебе надо будет при копировании кусков еще 64 байта отступать самого начала. Просто образ uImage может быть составной. В твоем случае там один кусок. dumpimage этот заголовок просто убирает. Когда будешь назад запаковывать, то mkimage должен этот заголовок заново сгенерить, а в нем будет контрольная сумма заголовка и данных, кстати, для контроля целостности образа.

И вот что мне выдал binwalk, после dumpimage -i demo.bin image.bin, хотя и с demo.bin тоже самое.

Там должно быть еще 0x40 в demo.bin в самом начале.

и продолжение, это что? тут этого много

6225920       0x5F0000        JFFS2 filesystem, little endian
8072000       0x7B2B40        JFFS2 filesystem, little endian
8082408       0x7B53E8        JFFS2 filesystem, little endian
8162252       0x7C8BCC        Zlib compressed data, compressed
8165440       0x7C9840        Zlib compressed data, compressed
8168256       0x7CA340        Zlib compressed data, compressed
8170808       0x7CAD38        JFFS2 filesystem, little endian
8172864       0x7CB540        Zlib compressed data, compressed
8175888       0x7CC110        Zlib compressed data, compressed
...
...
...
11069036      0xA8E66C        Zlib compressed data, compressed
11070588      0xA8EC7C        JFFS2 filesystem, little endian
11072752      0xA8F4F0        Zlib compressed data, compressed

Если залезть еще в rootfs, то там в /etc/init.d/rcS можно узнать, что apps состоит еще из разделов. Всего тут 9 разделов. mtd1 - ядро, mtd2 - rootfs, mtd3 - drivers, а дальше уже идут разделы jffs2. В принципе, это можно не трогать, если не нужно там ковыряться. Еще, к тому же, надо найти, где они начинаются.

# Mount driver partition
mount -t squashfs /dev/mtdblock3 /driver

# Mount system partition
mount -t jffs2 /dev/mtdblock4 /system

# Mount backup partition
#mount -t jffs2 /dev/mtdblock5 /backupk

# Mount backup partition
#mount -t jffs2 /dev/mtdblock6 /backupd

# Mount backup partition
mount -t jffs2 /dev/mtdblock7 /backupa

# Mount configs partition
mount -t jffs2 /dev/mtdblock8 /configs

# Mount params partition
mount -t jffs2 /dev/mtdblock9 /params

binwalk показывает кое-какие. Я полагаю вот это кандидаты, но это надо проверять (UPD: это цифры для другой прошивки! На них не полагаться!)

0x5F0000 - 0x61FFFF - mtd4

0x620000 - 0x6DFFFF -

0x6E0000 - 0x7DFFFF -

0x7E0000 - 0x90FFFF -

0x910000 - 0x93FFFF -

0x940000 - до конца - mtd9

demo.bin:

0             0x0             uImage header, header size: 64 
64            0x40            uImage header, header size: 64 
128           0x80            LZMA compressed data, properties: 

image.bin

0             0x0             uImage header, header size: 64 
64            0x40            LZMA compressed data, properties: 

Хотя нет. Ту прошивку что я проверял, она другое разбиение использует. Я все еще смотрел ту, что скачал. Но вот основные разделы kernel, rootfs, drivers и apps вроде такие же. А разбиение apps надо поглядеть.

Итак что я сделал:

binwalk  image.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0x7771D66A, 
                              created: 2020-03-20 15:44:39, image size: 1816781 bytes, 
                              Data Address: 0x80010000, Entry Point: 0x803E9230, 
                              data CRC: 0xBDC20C2D,  OS: Linux, CPU: MIPS, 
                              image type: OS Kernel Image, 
                              compression type: lzma, image name: "Linux-3.10.14"
64            0x40            LZMA compressed data, properties: 0x5D, dictionary size: 67108864 bytes, 
                              uncompressed size: -1 bytes
2097152       0x200000        Squashfs filesystem, little endian, version 4.0, compression:xz, 
                              size: 3353204 bytes, 407 inodes, blocksize: 131072 bytes, 
                              created: 2019-05-21 17:22:45
5570560       0x550000        Squashfs filesystem, little endian, version 4.0, compression:xz, 
                              size: 583802 bytes, 13 inodes, blocksize: 131072 bytes, 
                              created: 2020-02-23 16:07:18
6225920       0x5F0000        JFFS2 filesystem, little endian
8072000       0x7B2B40        JFFS2 filesystem, little endian
8082408       0x7B53E8        JFFS2 filesystem, little endian
...
...

Это я так понимаю какие то разделы:

2097152 0x200000 Squashfs filesystem
5570560 0x550000 Squashfs filesystem

dd if=image.bin of=kernel.lzma bs=1 count=64 skip=0
dd if=image.bin of=data.lzma bs=1 count=2097088 skip=64
dd if=image.bin of=squashfs1.xz bs=1 count=3473408 skip=2097152
dd if=image.bin of=squashfs2.xz bs=1 count=655360 skip=5570560

Далее я так понял squashfs можно примантировать, но не понял как т.е. на какое /dev ?

Это какие-то странные действия. И неправильно. Почему ядро 64 байта? Сделай вот так, как я написал вот ниже по ссылке. Тут правильные цифры:

Как разобрать(разархивировать) образ u-boot uImage (комментарий)

rootfs и drivers - это squashfs:

Как разобрать(разархивировать) образ u-boot uImage (комментарий)

Если ты хочешь что-то дописать в squashfs, то тебе не монтировать надо (он замонтируется из файла только в readonly), а распаковать. Выше по ссылке написано, как это сделать (hint: unsquashfs). Потом правка и запаковка назад с теми же параметрами сжатия.

Тебе, в общем-то, что надо сделать вообще? Ты написал, что драйвер поставить. Новый или заменить старый каким-то новым?

Просто я не понимаю математики bs=64K skip=32 count=53 откуда эти цифры взялись?

Да и распаковал drivers, как раз то что нужно! Мне нужно в drivers добавить драйвер wifi, а т.к. эта прошивка от аналога камеры xiafang там не тот драйвер что надо. Ну далее собрать обратно.

0x000000
0x200000
0x550000
0x5F0000

Гранулярность 64 Кб (65536 байт, 0x010000). первый блок размером 0x20 по 64кБ = это 32 в десятичном виде. Потом идет блок размером 0x55-0x20=0x35=53 десятичные (гранулярность 64 КБ). Потом идет блок размером 0x5F-0x55=0x0A=10 десячитные, а последний блок просто до конца.

Это применимо везде или только к этой прошивке?

Нет. Данные числа конкретно для этой прошивки. Я как-то немного сбит с толку, почему эти вопросы возникают. Ты можешь указать и побайтно, но просто у тебя dd нагрузит систему. Блоками он копирует гораздо быстрее. Сравни, если хочешь.

kernel - это lzma будет.

rootfs - это squashfs

drivers - это squashfs

apps - это еще один слепок, состоящий из шести разделов jffs2. Разбинение надо выяснять. Но если в нем не нужно ничего править, то и оставить его в покое как есть.

Это применимо везде или только к этой прошивке?

Вернее, будет так сказать. Это разбиение флеш-памяти на разделы выбрали разработчики. Но чтобы правильно образ разобрать, надо знать, где начинается каждый mtd и по отдельности их вытаскивать. Это производитель так решил разбить.

Я, к сожалению, не могу найти ничего по твоему конретно устройству. Оно какое-то редкое (для нашего рынка делали?) или просто это то же самое, что и Dafang. Вот кто-то расписал, как в Dafang разбито, хотя вот там есть mtd10, о котором я ничего не вижу в твоей прошивке. Может, раздел и есть, но где он используется, с первого раза не нашел.

https://github.com/ndabar/Xiaomi-Dafang-Teardown/blob/master/mod_getroot/firm...

О! Вот, кстати, распаковщик и запаковщик образа на Питоне. По сути то же, что мы и делали, только уже оформлено программой. unpacker.py, packer.py (все это, конечно, можно было shell-скриптом сделать). Думаю, что тебе будет полезно.

https://github.com/EliasKotlyar/Xiaomi-Dafang-Hacks/tree/master/hacks/firmware

Тут и Xiofang есть - https://github.com/EliasKotlyar/Xiaomi-Dafang-Hacks/blob/master/hacks/firmwar... (какой-то хак с заменой rcS, но это просто пример).

Спасибо за подсказки, моё устройство это тот же Dafang но другого производителя. Поковыряюсь с этим ещё чуть позже, если что напишу. Но думаю ещё будут вопросы.

Узнаю старый-добрый Ingenic. Скачал уже их тулчейн?

Нет не качал