HackWare.ru
Этичный хакинг и тестирование на проникновение, информационная безопасность
Анализ и разбивка составных файлов (прошивки, образы дисков)
Файлы контейнеры (матрёшки)
2 способа объединения файлов
С практической точки зрения, с точки зрения поиска файлов можно выделить 2 способа объединить файлы:
1. Файлы хранятся без изменения, в своём начальном виде.
Пример такого объединения файлов это файловые системы без шифрования и без сжатия. Например, EXT4, NTFS — в них файлы помещены в своём первоначальном виде. Соответственно, образы таких файловых систем также относятся к этой группе. Сюда же можно отнести некоторые прошивки, например, для роутеров и IP камер.
Понятно, что в таких больших файлах (образах) можно найти хранимые файлы. Более того, хранимые файлы можно извлечь и сохранить в виде самостоятельного файла, который будет идентичен исходному.
2. Файлы обрабатываются по определённому алгоритму.
Примеры такого способа объединения файлов это файловые системы с шифрованием или сжатием (например, Squashfs), архивы со сжатием.
Для поиска отдельных файлов по их сигнатурам необходимо выполнить обратное действие, то есть если файл был сжат, необходимо его разархивировать. Если это файловая система со сжатием, то необходимо её смонтировать.
С практической точки зрения это означает, что бесполезно искать файлы по сигнатурам в архивах, пока эти архивы не распакованы (НО: некоторые программы по анализу сырых данных поддерживают работу с архивами!). Бесполезно искать файлы по сигнатурам в файловой системе Squashfs до её монтирования. При этом можно применять поиск по сигнатурам в EXT4 и NTFS и их монтирование не требуется!
Монтирование, например, образа NTFS даст нам следующее: мы сможем получать доступ к файлам этой файловой системы тем способом, каким это предусмотрели разработчики, то есть мы увидим список файлов и сможем получить доступ к любому из них без необходимости искать файлы по сигнатурам. Но при этом мы не сможем получить или даже узнать об уже удалённых файлах.
Без монтирования образа NTFS мы сможем работать с хранящимися на нём файлами напрямую, то есть с одной стороны нам придётся искать файлы по сигнатурам, но с другой стороны мы получим доступ даже к удалённым файлам. Удалённые файлы доступны в результате того, что обычно удаление на HDD заключается в том, что информация о файле просто удаляется из «журнала» файловой системы, но сам файл остаётся там же, где и был (если его впоследствии случайно не перезаписали другим файлом). Что касается с SSD, то там обычно данные всё-таки удаляются.
Ничего не мешает комбинировать эти способы, причём криминалистические инструменты позволяют сделать поиск удалённых данных более эффективным, например, поиск удалённых файлов выполняется только на тех частях диска, которые считаются пустыми.
Как распаковать прошивку камеры
Рассмотрим пример распаковки прошивки камеры Network Surveillance DVR r80x20-pq (эту камеру я использовал в тестах, например, в статье «Аудит безопасности IP камер».
Скачиваем и распаковываем архив. Он называется General_IPC_XM530_R80X20-PQ_WIFIXM711.711.Nat.dss.OnvifS_V5.00.R02.20210818_all.bin, для краткости последующих команд я переименую его в firmware.bin.
Проверим, что это за файл:
То есть это Zip архив.
Проверим с помощью Detect It Easy:
Также воспользуемся утилитой Binwalk, которая специально предназначена для анализа прошивок:
Поскольку это просто архив, распакуем его:
Видимо, следующие образы являются составными частями файловой системы:
Поинтересуемся файлом user-x.cramfs.img:
U-Boot — это загрузчик для встроенных плат на базе PowerPC, ARM, MIPS и нескольких других процессоров, который можно установить в загрузочное ПЗУ и использовать для инициализации и тестирования оборудования или для загрузки и запуска кода приложения. В вашем Linux вы можете найти пакеты uboot-tools (Arch Linux и производные) и u-boot-tools (Debian и производные) — это инструменты и утилиты для сборки прошивок и выполнения с ними других действий.
Попробуем смонтировать образ user-x.cramfs.img:
Обратимся за помощью к утилите Binwalk, которая умеет находить файлы и файловые системы даже если они находятся не в начале:
Теперь всё стало ясно — данный образ состоит из двух разделов. Первые 64 байта занимает заголовок uImage. А сама файловая система Squashfs идёт начиная с 64 байта.
Мы можем извлечь файловую систему — как это сделать сразу несколькими способами будет показано ниже, — но также по-прежнему можем её просто смонтировать, указав смещение:
Посмотрим на файлы, размещённые в образе user-x.cramfs.img:
В этом образе я не нашёл ничего интересного, размонтируем его:
Посмотрим, где начинается файловая система в romfs-x.cramfs.img:
Здесь можно найти хеш дефолтного пользователя root:
Аналогичным образом, сканируя с помощью Binwalk и монтируя разделы файловой системы, можно искать интересные файлы.
Как вырезать файловую систему из образа
1. Монтировать без извлечения
Как было показано выше, с помощью опции offset можно указать смещение и монтировать файловую систему которая является частью образа и расположена не в самом его начале:
Если образ содержит несколько файловых систем, вам может понадобиться указать ещё и опцию sizelimit — размер файловой системы:
2. Извлечение с помощью dd
Найдём разделы в прошивке:
Всего имеется три области:
Для извлечения каждого из этих разделов можно использовать команду вида:
К примеру, из файла Keenetic-II-V2.06(AAFG.0)C3.bin я хочу извлечь первые 64 байт, тогда команда следующая:
Теперь я хочу извлечь второй раздел, начинающийся с 64 байта. Этот раздел заканчивается на байте 1376256, но опция count команды dd указывает сколько байт нужно прочитать (а не границу извлечения данных), поэтому значение count рассчитывается по формуле:
Файл LZMA можно распаковать, например, с помощью 7z:
В принципе команда извлекла данные, хотя и сообщила об ошибке:
Суть ошибки в том, что после конца полезной нагрузки были обнаружены данные. Можно сказать, что это нормально (неизбежно) в данном случае, поскольку мы не знали точный размер блока и указали в качестве его конца байт, где начинается другой раздел. Другой раздел начинается с байта (в шестнадцатеричном виде) 0x150000, поэтому можно предположить, что для паддинга (padding, выравнивания) между разделами просто «набиты» нули. В этом можно убедиться, открыв файл data.lzma в шестнадцатеричном редакторе, например в Bless:
Да, в конце этого файла нули — если точный размер неизвестен, то лучше записать лишнего, чем потерять данные.
Третий блок начинается с 1376256 байта и имеет размер 6205991 об этом нам говорит строка «size: 6205991 bytes». Команда по его извлечению следующая:
Но производители прошивки всё равно меня перехитрили использовав Squashfs version 3.0 из 2006 года и я не смог её открыть по техническим причинам:
3. Извлечение с помощью Binwalk
У программы Binwalk имеются следующие опции для извлечения:
Более подробное их описание вы можете прочитать в карточке программы https://kali.tools/?p=6771. Это кажется удобным — извлекать данные автоматически, но на практике результат будет не совсем тем, который вы ожидаете. Поскольку даже в ручном режиме мы не всегда точно знаем границы разделов, то это же самое относится и к указанным опциям, которые плохо работают с разделами, для которых не указан конкретный размер.
4. Извлечение с помощью dc3dd и dcfldd
У программы dd есть улучшенные версии dc3dd и dcfldd. При желании для извлечения разделов файловой системы из образа диска вы можете использовать их.
Поиск последовательности байтов в бинарном файле
Программы file, Binwalk и Detect It Easy в поиске данных используют сигнатуры. Эти сигнатуры предопределены в их базах данных (так называемые магические файлы).
Если вам нужно выполнить поиск по вашим собственным сигнатурам, то есть по строке бинарных данных, то вы можете использовать Binwalk со следующими опциями:
Например, поиск шестнадцатеричных байтов 53EF в файле /mnt/disk_d/fs.ext4:
Программа sigfind из пакета Sleuth также позволяет искать по сигнатурам, при этом программа позволяет указать отступ от начала блока (НЕ файла). В программе прописаны несколько сигнатур для поиска файловых систем, например:
В следующем примере ищется последовательность байтов 53EF (обратный порядок записи байтов) со смещением 56 от любого блока (если не указать смещение, то будут выведены только блоки, где данная последовательность байтов имеет смещение 0):
Реверс-инжиниринг домашнего роутера с помощью binwalk. Доверяете софту своего роутера?
Несколько дней назад, я решил провести реверс-инжиниринг прошивки своего роутера используя binwalk.
Я купил себе TP-Link Archer C7 home router. Не самый лучший роутер, но для моих нужд вполне хватает.
Каждый раз когда я покупаю новый роутер, я устанавливаю OpenWRT. Зачем? Как правило производители не сильно заботятся о поддержке своих роутеров и со временем софт устаревает, появляются уязвимости и так далее, в общем вы поняли. Поэтому я предпочитаю хорошо поддерживаемую сообществом open-source прошивку OpenWRT.
Скачав себе OpenWRT, я так же скачал последний образ прошивки под мой новый Archer C7 с официального сайта и решил проанализировать его. Чисто ради фана и рассказать о binwalk.
Что такое binwalk?
Binwalk — это инструмент с открытым исходным кодом для анализа, реверс-инжиниринга и извлечения образов прошивок.
Созданный в 2010 году Крейгом Хеффнером, binwalk может сканировать образы прошивок и находить файлы, идентифицировать и извлекать образы файловой системы, исполняемый код, сжатые архивы, загрузчики и ядра, форматы файлов, такие как JPEG и PDF, и многое другое.
Вы можете использовать binwalk для реверс-инжиниринга прошивки для того, что бы понять как она устроена. Искать в бинарных файлах уязвимости, извлекать файлы и искать бекдоры или цифровые сертификаты. Можно так же найти opcodes для кучи разных CPU.
Вы можете распаковать образы файловой системы для поиска определенных файлов паролей (passwd, shadow и т.д.) И попытаться сломать хэши паролей. Вы можете выполнить двоичный анализ между двумя или более файлами. Вы можете выполнить анализ энтропии данных для поиска сжатых данных или закодированных ключей шифрования. Все это без необходимости доступа к исходному коду.
В общем все, что необходимо, есть 🙂
Как работает binwalk?
Основной особенностью binwalk является его сигнатурное сканирование. Binwalk может сканировать образ прошивки для поиска различных встроенных типов файлов и файловых систем.
Binwalk работает так же. Но вместо того, чтобы искать подписи только в начале файла, binwalk будет сканировать весь файл. Кроме того, binwalk может извлечь файлы, найденные в образе.
Инструменты file и binwalk используют библиотеку libmagic для идентификации подписей файлов. Но binwalk дополнительно поддерживает список пользовательских магических сигнатур для поиска сжатых / заархивированных файлов, заголовков прошивок, ядер Linux, загрузчиков, файловых систем и так далее.
Установка binwalk
Binwalk поддерживается на нескольких платформах, включая Linux, OSX, FreeBSD и Windows.
Чтобы установить последнюю версию binwalk, вы можете загрузить исходный код и следовать инструкции установки или краткому руководству, доступному на веб-сайте проекта.
У Binwalk много разных параметров:
Сканирования образов
Начнем с поиска сигнатур файлов внутри образа (образ с сайта TP-Link).
Теперь у нас много информации об этом образе.
Давайте теперь распакуем загрузчик (U-Boot) с помощью команды dd :
Поскольку образ сжат с помощью LZMA, нам нужно распаковать его:
Теперь у нас есть образ U-Boot:
Переменная окружения U-Boot bootargs используется для передачи параметров ядру Linux. И из вышеприведенного мы лучше понимаем флэш-память устройства.
Как насчет извлечения образа ядра Linux?
Мы можем проверить, что образ был успешно извлечен с помощью команды file :
Формат файла uImage — это в основном образ ядра Linux с дополнительным заголовком. Давайте удалим этот заголовок, чтобы получить окончательный образ ядра Linux:
Образ сжат, поэтому давайте распакуем его:
Теперь у нас есть образ ядра Linux:
Что мы можем сделать с образом ядра? Мы могли бы, например, сделать поиск по строкам в образе и найти версию ядра Linux и узнать об окружающей среде, используемой для сборки ядра:
Несмотря на то, что прошивка была выпущена в прошлом году (2019 г.), когда я пишу эту статью, она использует старую версию ядра Linux (3.3.8), выпущенную в 2012 г., скомпилированную с очень старой версией GCC (4.6) также с 2012 г.!
(прим. перев. еще доверяете своим роутерам в офисе и дома?)
Полная корневая файловая система будет извлечена в подкаталог:
Теперь мы можем сделать много разного.
Мы можем искать файлы конфигурации, хэши паролей, криптографические ключи и цифровые сертификаты. Мы можем проанализировать бинарные файлы для поиска ошибок и уязвимостей.
С помощью qemu и chroot мы можем даже запустить (эмулировать) исполняемый файл из образа:
Здорово! Но обратите внимание, что версия BusyBox — 1.19.4. Это очень старая версия BusyBox, выпущенная в апреле 2012 года.
Таким образом, TP-Link выпускает образ прошивки в 2019 году с использованием программного обеспечения (GCC toolchain, kernel, BusyBox и т. Д.) 2012 года!
Теперь вы понимаете, почему я всегда устанавливаю OpenWRT на свои роутеры?
Это еще не все
Binwalk также может выполнять энтропийный анализ, печатать необработанные энтропийные данные и генерировать энтропийные графики. Обычно большая энтропия наблюдается, когда байты в образе случайны. Это может означать, что образ содержит зашифрованный, сжатый или обфусцированный файл. Хардкорно прописанный ключ шифрования? Почему бы и нет.
Вы можете найти больше информации о binwalk в официальной документации.
Расширение binwalk
Существует API-интерфейс binwalk, реализованный в виде модуля Python, который может использоваться любым скриптом Python для программного выполнения сканирования binwalk, а утилита командной строки binwalk может быть почти полностью продублирована всего двумя строками кода Python!
С помощью Python API вы также можете создавать плагины под Python для настройки и расширения binwalk.
Также существует плагин IDA и облачная версия Binwalk Pro.
Так почему бы вам не скачать образ прошивки из Интернета и не попробовать binwalk? Обещаю, вам будет очень весело 🙂
Что такое bin и чем открыть bin файлы?
Описание файлов формата BIN
Расширение Binary содержит двоичный код, предназначенный для совершенно разных целей. Чаще всего – это вспомогательное программное средство, необходимое для выполнения той или иной задачи на вашем ПК. Может храниться в системных папках либо идти в комплекте с каким-либо приложением, установленным на компьютер. В более редких случаях, БИН является виртуальным образом оптического носителя, подобно формату ISO, MDF, IMG, NRG и т.д.
Рассмотрим основные виды BIN-файлов
Некоторые из вышеприведенных расширений можно конвертировать в другие более удобные форматы.
Кстати, открыть файл BIN в онлайне невозможно, так что пользователю придётся воспользоваться одной из специальных программ, о которых пойдёт речь в статье ниже.
Открытие BIN стандартными средствами операционной системы Windows 7, 8, 10?
Реализовать задачу можно в обычном Блокноте, входящем в штатный набор инструментов операционки. Как известно, это приложение умеет открывать и отображать практически любые виды текстов. Разумеется, метод сработает не во всех случаях, но всё же не станет лишним испытать его на практике.
Программы для открытия файлов расширением BIN
Чтобы выяснить, является ли БИН образом CD/DVD диска, обратите внимание на его размер. Если объём соответствует размеру оптического носителя — скорее всего, ваш файл представляет собой образ.
После того, как будете знать такую информацию, можете попробовать одну из универсальных программ для монтирования CD/DVD-образов.
UltraISO
Очень функциональная утилита, отлично справляется с распаковкой и записью разных данных. Умеет создавать установочные флешки и DVD-диски.
Daemon Tools
Популярный софт с интуитивно понятным интерфейсом. Поможет узнать подробные сведения о содержимом файла и отредактировать его. Поддерживает разные версии Microsoft Windows, Mac OS и Linux.
Nero
Ещё одна хорошая программка. Запускается автоматически вместе со стартом OS. Отличается высокой скоростью работы, предоставляет много полезных функций и настроек.
Если BIN-расширение небольшого размера появилось после подключения к компьютеру смартфона или фотоаппарата, оно связано с драйверами для подключенных устройств. Открывать такой тип файла можно через специальные программы, поставляющиеся в комплекте с гаджетом, например: Nokia PC Suite, Samsung Kies, BlackBerry Desktop Manager, Mackintosh Suite и т.д.
Исследуем OpenWRT: чем отличаются образы uImage и sysupgrade
В комментариях к статье “Прошиваем роутер Upvel UR-313N4G на OpenWRT” между вашим покорным слугой и уважаемым Maysoft завязался спор насчет различий в структуре образов uImage и sysupgrade прошивки OpenWRT. Я обещал Maysoft разобраться в проблеме, и вот перед вами эта статья.
Как известно, в каталоге загрузок OpenWRT доступны, по большей части, прошивки двух типов — uImage и sysupgrade, например:
Официальный FAQ пишет об их различиях весьма скупо:
What is the difference between the different image formats?
a factory image is one built for the bootloader flasher or stock software flasher
a sysupgrade image (previously named trx image) is designed to be flashed from within openwrt itself
The two have the same content, but a factory image would have extra header information or whatever the platform needs. Generally speaking, the factory image is to be used with the OEM GUI or OEM flashing utilities to convert the device to OpenWrt. After that, use the sysupgrade images.
Согласно документации, содержание образов идентично, за исключением того, что в образе factory присутствуют дополнительные заголовки, чтобы этот образ можно было прошить через Web-интерфейс оригинальной прошивки.
Отлично, сравним размер прошивок:
openwrt-15.05-rc3-ramips-rt305x-dir-320-b1-initramfs-uImage.bin — 3253035 байт.
openwrt-15.05-rc3-ramips-rt305x-dir-320-b1-squashfs-sysupgrade.bin — 3407876 байт.
Ого, прошивка sysupgrade почти на 140 Кб больше uImage, а по документации они должны быть примерно одного размера, причем uImage за счет этой самой “extra header information” — немного больше.
Конечно, достаточно посмотреть в сборочные скрипты, чтобы понять, чем различаются uImage и sysupgrade-образы, но это, согласитесь, неспортивно. Сегодня мы будем анализировать прошивки “в лоб”, как будто у нас нет исходников, а уже в конце заглянем в сборочные скрипты, чтобы подтвердить наши догадки.
Основным средством анализа прошивок на данный момент является утилита binwalk, доступная под Linux. Переименуем файлы прошивок покороче, чтобы нам было удобнее, и начнем анализ.
Посмотрим, что у нас получилось
Файл с именем 40 (смещение в исходном файле) — и есть распакованный поток. Натравим на него binwalk:
А здесь у нас что-то, на первый взгляд, непонятное — binwalk обнаружил ядро Linux по смещению 0x2AEB14 и три сжатых потока данных, следующих за ядром. Дело в том, что binwalk для анализа использует эвристики и то, что получается у него на выходе — не истина в последней инстанции, а информация к размышлению.
Здравый смысл подсказывает, что ядро должно начинаться со смещения 0, а сжатый поток — быть один и содержать initramfs — начальную файловую систему, загружаемую в RAM. О том же говорит и документация на ядро:
What is initramfs?
— All 2.6 Linux kernels contain a gzipped «cpio» format archive, which is extracted into rootfs when the kernel boots up. After extracting, the kernel checks to see if rootfs contains a file «init», and if so it executes it as PID 1.
Populating initramfs:
— The 2.6 kernel build process always creates a gzipped cpio format initramfs archive and links it into the resulting kernel binary. By default, this archive is empty (consuming 134 bytes on x86).
Здесь же упоминается и формат потока — CPIO.
Посмотрим, что binwalk сможет извлечь из нашего образа:
Итак, успешно распаковался только поток по смещению 33E2C8. Если мы все правильно делаем, то это должен быть CPIO-контейнер с файловой системой:
В конце архива мы видим файл с именем TRAILER. который. согласно документации, является меткой конца архива.
Значит, структура прошивки initramfs-uImage такова:
Теперь возьмемся за образ squashfs-sysupgrade. Из названия следует, что в образе содержится (кроме ядра) файловая система squashfs. Посмотрим, так ли это:
Возьмемся за арифметику: 64 + 1142606 (image size) = 1142670, как раз по этому смещению начинается образ squashfs, а заканчивается он по смещению 1142670 + 2221946 = 3364616. Размер образа, между тем, 3407876 байт, значит, у нас есть еще 3407876 — 3364616 = 43260 байт неидентифицированной информации. Посмотрим, что там, hexdump’ом
Тут явно какая-то заглушка. Вернемся к ней позднее.
Посмотрим, что у нас в каталоге с распакованным образом:
Распакуем LZMA-поток по смещению 40:
Здесь у нас ядро Linux и небольшой initramfs-образ с четырьмя файлами. Остальное, видимо, переместилось в образ squashfs:
Действительно, основная файловая система содержится в образе squashfs.
Теперь разберемся с заглушкой в конце образа. Есть подозрение, что она как-то относится к ФС JFFS2, потому что при прошивке образа sysupgrade и последующей загрузке в dmesg появляются строки:
а при прошивке и загрузке образа uImage этих строк нет. Поиск в “ванильном“ ядре по этим строкам ничего не дает, а вот в дереве исходных кодов OpenWRT такие строки есть:
Ага, вот и наша заглушка 0xDEADCODE. Если драйвер JFFS2 находит эту метку, то он считает ее концом предыдущей файловой системы и стирает все, начиная с нулевого байта метки и заканчивая концом накопителя. Таким образом сама метка также затирается.
После этого драйвер создает на этом месте новый экземпляр JFFS2.
Итак, получается следующая структура образа:
В заключении заглянем сборочные скрипты OpenWRT, чтобы убедиться в своих выводах. Начнем с файла /target/linux/ramips/Makefile. Но если вы думаете, что это обычный GNU Makefile, то это не так. Вот как описывают улучшенный Makefile сами разработчики:
Looking at one of the package makefiles, you’d hardly recognize it as a makefile. Through what can only be described as blatant disregard and abuse of the traditional make format, the makefile has been transformed into an object oriented template which simplifies the entire ordeal.
Кажется, сборка образа запускается в строке 564:
Цель BuildFirmware/Default8M описана в строках 195 и 196:
Она состоит из двух позиций: squashfs и initramfs. Цели BuildFirmware/OF и BuildFirmware/OF/initramfs описаны в том же файле чуть выше
По имени цели MkImageLzmaDtb можно догадаться, что она создает образ uImage по описанию из DTS-файла. Для цели BuildFirmware/OF/initramfs к этому образу добавляется раздел initramfs с основной файловой системой, после чего образ копируется в выходной каталог. Для цели BuildFirmware/OF исходный образ обрабатывается функцией MkImageSysupgrade, которая с помощью команды “cat” прицепляет к нему раздел squashfs, а затем, взывает функцию prepare_generic_squashfs, определенную в файле image.mk.
А утилита padjffs2, написанная на C, записывает отметку 0xDEADCODE в конец файла образа:
В общем, мир OpenWRT прекрасен и удивителен, особенно доставляют комментарии типа:
# The real magic happens inside these templates
