А научите меня реверс-инженерингу ((-:)

[Bizdelnick]

Есть желание разобраться, как устроен некий блоб. С тем чтобы в перспективе, может быть, заменить его своим, делающим примерно то же самое, но более человекообразным способом, но для начала задача — именно понять, как устроен и как работает. Опыта в колупании бинарей нет, представления об ассемблере довольно смутные.
Итак, что имеем. Есть ARM-железка, в просторечьи именуемая смартфоном. Есть бинарник, который может быть в эту железку загружен и запущен даже в том случае, когда она обращена в кирпич. С протоколом загрузки пока не разбирался, но там я представляю, в какую сторону копать. А чтобы разобраться в формате бинарника — нужна помощь понимающих людей. Исходя из общих соображений, можно предположить, что формат должен быть предельно простой.
Вот что у нас в начале файла:

Код: Выделить всё

- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x00000000  4d54 4b5f 444f 574e 4c4f 4144 5f41 4745  MTK_DOWNLOAD_AGE
0x00000010  4e54 0000 0000 0000 0000 0000 0000 0000  NT..............
0x00000020  4d54 4b5f 416c 6c49 6e4f 6e65 5f44 415f  MTK_AllInOne_DA_
0x00000030  7633 2e33 3030 312e 3030 2e30 3000 0000  v3.3001.00.00...
0x00000040  0000 0000 0000 0000 0000 0000 0000 0000  ................
0x00000050  0000 0000 0000 0000 0000 0000 0000 0000  ................
0x00000060  0400 0000 9988 6622 1700 0000 dada 7365  ......f"......se
0x00000070  0000 10ca 01ca 0000 0010 0000 0100 0300  ................
0x00000080  6c37 0000 7002 0000 0060 0090 0000 0000  l7..p....`......
0x00000090  0000 0000 dc39 0000 2c62 0100 0050 0090  .....9..,b...P..
0x000000a0  2c61 0100 0001 0000 089c 0100 5016 0000  ,a..........P...
0x000000b0  0000 00f1 5016 0000 0000 0000 0000 0000  ....P...........
0x000000c0  0000 0000 0000 0000 0000 0000 0000 0000  ................
0x000000d0  0000 0000 0000 0000 0000 0000 0000 0000  ................
0x000000e0  0000 0000 0000 0000 0000 0000 0000 0000  ................
0x000000f0  0000 0000 0000 0000 0000 0000 0000 0000  ................

В самом начале, очевидно, некий magic. Со смещением 0x20 — что-то вроде уникального идентификатора. А вот с 0x60 начинается интересное. Это уже исполняемый код? Или сначала смещение, с которого начнётся исполняемый код (ещё 4 байта), а с 0x64 — исполняемый код? Или это что-то совсем другое?
Приветствуются любые советы: что почитать, какими инструментами пользоваться, ну и, конечно, соображения по теме.

P. S. Вот тут файл целиком, но не тот же самый, а другой в том же формате: http://en.webhex.net/view/05e4c776942d491f89320b9962109ccd/0. Ссылку на другой файл даю из-за ограничения в 5 МиБ на размер: он чуть меньше, а тот, кусок которого я привёл выше, больше. Всего имеется 5 файлов, из коих две пары почти идентичных. При необходимости можно поискать файлы других версий.

[NickLion]

Гуглением обнаружил вот такой лог. Из интересного (661 строка и ниже):

Код: Выделить всё

03/02/14 10:50:59.583 BROM_DLL[3256][5624]: DEBUG: DAEntrySet::Validation(): m_da_identifier(MTK_AllInOne_DA_v7.1344.00.000), m_da_description(MTK_DOWNLOAD_AGENT), m_info_ver(0x4), m_info_magic(0x22668899). (FlashToolLib/source/common/generic/src/da_entry_base.cpp:278)
03/02/14 10:50:59.583 BROM_DLL[3256][5624]: DEBUG: DAEntrySet::Validation(): m_da_count(10). (FlashToolLib/source/common/generic/src/da_entry_base.cpp:283)
03/02/14 10:50:59.583 BROM_DLL[3256][5624]: DEBUG: DAEntryV4::Validation(): DA(0x6573): m_load_regions_count(3). (FlashToolLib/source/common/generic/src/da_entry_base.cpp:221)

m_info_ver(0x4) — высока вероятность, что то 04 — это версия заголовка, который идёт далее. Упомянутый DA(0x6573) встречается и Вашем бинарнике.

[yoshakar]

Вот тут файл целиком

А нельзя ли посмотреть на сам (бинарный) файл, а не на его хекс-дамп?

[Bizdelnick]

yoshakar
http://4pda.ru/forum/dl/post/7219810/SP_Fl...1548.00.100.zip
Файлы *.bin

[Bizdelnick]

NickLion
Почему я, собственно, решил, что это не заголовок, а уже код. Когда пролистывал дамп файла, заметил, что последовательности вроде

Код: Выделить всё

dada7365

в позиции 0x6c встречаются довольно часто. Это дизассемблируется в такой код:

Код: Выделить всё

ldrbvs sp, [r3, -2778]!

Вроде похоже на часть вызова функции, или я ошибаюсь?

[yoshakar]

http://4pda.ru/forum/dl/post/7219810/SP_Fl...1548.00.100.zip

"Ой! Ошибка 404.

Запрашиваемая информация не существует, перемещена или удалена."

[Bizdelnick]

yoshakar
Прошу прощения. Вот тут дают без регистрации и СМС: http://mtk2000.ucoz.ru/down15/SP_Flash_Too...nux_v5.1548.rar (извиняюсь за rar).

[yoshakar]

Bizdelnick, спасибо. По-моему, вначале идут какие-то данные (заголовки), не код: видна цикличность — то есть это массив структур, размер структуры 220 байт (см. похожие куски 14C:154, 228:230, 304:30C, 3E0:3E8, 4BC:4C4, 598:5A0, 674:67C, 750:758 и т. д.). То есть если это код, то почему так ровненько?

[Stauffenberg]

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

Для начала - устройство ELF.

Это уже исполняемый код? Или сначала смещение, с которого начнётся исполняемый код (ещё 4 байта), а с 0x64 — исполняемый код? Или это что-то совсем другое?

Если Вы сможете запустить этот бинарник в системе, на которой под рукой будут стандартные linux-инструменты, можно будет ответить и на эти вопросы. В сети есть примеры модулей ядра, которые специально для этого и написаны - разложить бинарник по полочкам и предоставить все это в понятном формате.

[Bizdelnick]

Для начала - устройство ELF.

Если бы это был ELF, всё было бы намного проще. Но это не ELF. И именно потому я и создал эту тему: я хочу понять, что это за формат и как он устроен. objdump его не распознаёт.

Если Вы сможете запустить этот бинарник в системе, на которой под рукой будут стандартные linux-инструменты

Он вообще не рассчитан на запуск в какой-то системе. Он запускается примитивным (или не очень) загрузчиком, зашитым в ПЗУ SoC. Можно, конечно, попытаться как-нибудь запустить в qemu, но вряд ли это что-то даст, потому что он не найдёт нужных ему для работы устройств и... Фиг его знает, что он дальше будет делать.

[NickLion]

Почему я, собственно, решил, что это не заголовок, а уже код. Когда пролистывал дамп файла, заметил, что последовательности вроде

Код: Выделить всё

dada7365

в позиции 0x6c встречаются довольно часто. Это дизассемблируется в такой код:

Код: Выделить всё

ldrbvs sp, [r3, -2778]!

Вроде похоже на часть вызова функции, или я ошибаюсь?

Ещё раз посмотрите на лог:

Код: Выделить всё

03/02/14 10:50:59.583 BROM_DLL[3256][5624]: DEBUG: DAEntrySet::Validation(): m_da_identifier(MTK_AllInOne_DA_v7.1344.00.000), m_da_description(MTK_DOWNLOAD_AGENT), m_info_ver(0x4), m_info_magic(0x22668899). (FlashToolLib/source/common/generic/src/da_entry_base.cpp:278)

m_info_ver(0x4) — соответствует 0x00000060 04 00 00 00
m_info_magic(0x22668899) — соотвествует 0x00000064 99 88 66 22
по логике вещей, далее 17 00 00 00 — это число сегментов/секций, каждый из которых начинается на DA DA, а что значат следующие 2 байта — непонятно, то ли какой-то идентификатор, то ли флаги, то ли ещё что-то.

UPD да, смотрите, далее идёт 23 секции по 220 байт каждая, которые начинаются с DA DA (c 0x006C по 0x1430, последняя DA DA на 0x1354)

[NickLion]

Код: Выделить всё

0x00000080  6c 37 00 00

— это похоже на адрес 0x0000376C, с которого начинается что-то интересное:

Код: Выделить всё

0x00003760: 00 00 00 00 00 00 00 00 00 00 00 00 4d 4d 4d 01  ............MMM.
0x00003770: 38 00 00 00 46 49 4c 45 5f 49 4e 46 4f 00 00 00  8...FILE_INFO...
0x00003780: 01 00 00 00 07 00 00 02 00 60 00 90 70 02 00 00  .........`..p...
0x00003790: 00 40 00 00 38 00 00 00 00 01 00 00 99 00 00 00  .@..8...........
0x000037a0: 01 00 00 00 b0 b5 04 1c 00 20 01 25 2d 04 01 30  ......... .%-..0
0x000037b0: a8 42 fc db 00 f0 28 f8 00 28 0f d1 00 f0 26 f8  .B....(..(....&.
0x000037c0: 00 28 04 d1 20 1c 00 f0 23 f8 00 28 17 d1 21 1c  .(.. ...#..(..!.
0x000037d0: 00 20 00 f0 1f f8 00 28 11 d1 08 e0 00 f0 16 f8  . .....(........
0x000037e0: 00 28 04 d1 20 1c 00 f0 13 f8 00 28 07 d1 00 f0  .(.. ......(....
0x000037f0: 14 f8 00 28 03 d1 01 30 a8 42 fc db 00 20 b0 bc  ...(...0.B... ..
0x00003800: 08 bc 18 47 00 20 70 47 00 20 70 47 00 20 70 47  ...G. pG. pG. pG
0x00003810: 00 20 70 47 00 20 70 47 70 47 00 20 70 47 00 00  . pG. pGpG. pG..
0x00003820: f0 03 2d e9 01 30 e0 e1 01 40 81 e0 03 50 83 e0  ..-..0...@...P..
0x00003830: 04 60 84 e0 05 70 85 e0 06 80 86 e0 07 90 87 e0  .`...p..........
0x00003840: fa 03 80 e8 f0 03 bd e8 1e ff 2f e1 f0 1f 2d e9  ........../...-.
0x00003850: 00 c0 a0 e3 01 30 e0 e1 f0 0f 90 e8 01 00 54 e1  .....0........T.

[NickLion]

В том же файле, 734 строка:

Код: Выделить всё

03/02/14 10:50:59.585 BROM_DLL[3256][5624]: DA_HANDLE(0x05F08F20):     DA[0]={ magic(0xDADA), hw_code(0x6571), hw_ver(0xCA00), sw_ver(0x0000), entry_region_index(0) }.                                                                                                    (FlashToolLib/source/common/handle/src/flashtool_handle_internal.cpp:4948)

Получается сначала DA DA, потом какой-то hw_code (похоже 4 байта) /*аппаратный код?*/, потом hw_ver (2 байта) /*аппаратная версия?*/, потом sw_ver (2 байта) /*программная версия?*/, далее 10 байт — не знаю что, а затем 4 байта смещение от начала файла данных, в которых, наверное, уже и находится код. В первой секции на 6C 37 00 00, второй на 58 B2 01 00, и т.д. Они начинаются одинаково:

Код: Выделить всё

4D 4D 4D 01 38 00 00 00 46 49 4C 45 5F 49 4E 46 4F 00 00 00 | MMM.8...FILE_INFO...

[Bizdelnick]

Спасибо!
Действительно, там, похоже, есть некое подобие файловой системы. Бинарь оказался не таким примитивным, как я думал.
А вот кое-кто уже ковырялся в подобных бинарях: http://china-gsm.ru/posts/statji/instrukci...-linejki-mt625h. Добрый человек поведал нам, где искать длину «файла».

[Bizdelnick]

потом какой-то hw_code (похоже 4 байта) /*аппаратный код?*/

Весьма вероятно, что имеется в виду чип MT6571, для которого предназначен соответствующий «файл». Тогда со смещением 0x0e2c — запись для моего MT6735.
Не зря эта штука называется «all in one».