# Firmware Analysis {{#include ../../banners/hacktricks-training.md}} ## **Introduction** ### Related resources {{#ref}} synology-encrypted-archive-decryption.md {{#endref}} Firmware є основним програмним забезпеченням, яке дозволяє пристроям працювати правильно, керуючи та полегшуючи зв'язок між апаратними компонентами та програмним забезпеченням, з яким взаємодіють користувачі. Воно зберігається в постійній пам'яті, що забезпечує доступ пристрою до важливих інструкцій з моменту його ввімкнення, що призводить до запуску операційної системи. Аналіз та потенційне модифікування прошивки є критичним кроком у виявленні вразливостей безпеки. ## **Gathering Information** **Збір інформації** є критично важливим початковим кроком у розумінні складу пристрою та технологій, які він використовує. Цей процес включає збір даних про: - Архітектуру ЦП та операційну систему, на якій він працює - Специфікації завантажувача - Схему апаратного забезпечення та технічні характеристики - Метрики кодової бази та місця розташування виходу - Зовнішні бібліотеки та типи ліцензій - Історії оновлень та регуляторні сертифікації - Архітектурні та потокові діаграми - Оцінки безпеки та виявлені вразливості Для цієї мети **інструменти відкритих джерел (OSINT)** є безцінними, як і аналіз будь-яких доступних компонентів програмного забезпечення з відкритим кодом через ручні та автоматизовані процеси перевірки. Інструменти, такі як [Coverity Scan](https://scan.coverity.com) та [Semmle’s LGTM](https://lgtm.com/#explore), пропонують безкоштовний статичний аналіз, який можна використовувати для виявлення потенційних проблем. ## **Acquiring the Firmware** Отримання прошивки можна здійснити різними способами, кожен з яких має свій рівень складності: - **Безпосередньо** від джерела (розробників, виробників) - **Створення** її з наданих інструкцій - **Завантаження** з офіційних сайтів підтримки - Використання **Google dork** запитів для знаходження розміщених файлів прошивки - Доступ до **хмарного сховища** безпосередньо, з інструментами, такими як [S3Scanner](https://github.com/sa7mon/S3Scanner) - Перехоплення **оновлень** за допомогою технік "людина посередині" - **Витягування** з пристрою через з'єднання, такі як **UART**, **JTAG** або **PICit** - **Сниффінг** запитів на оновлення в межах зв'язку пристрою - Виявлення та використання **жорстко закодованих кінцевих точок оновлень** - **Скидання** з завантажувача або мережі - **Видалення та читання** чіпа пам'яті, коли всі інші способи не спрацювали, використовуючи відповідні апаратні інструменти ## Analyzing the firmware Тепер, коли ви **маєте прошивку**, вам потрібно витягти інформацію про неї, щоб знати, як з нею працювати. Різні інструменти, які ви можете використовувати для цього: ```bash file strings -n8 strings -tx #print offsets in hex hexdump -C -n 512 > hexdump.out hexdump -C | head # might find signatures in header fdisk -lu #lists a drives partition and filesystems if multiple ``` Якщо ви не знайдете багато з цими інструментами, перевірте **ентропію** зображення за допомогою `binwalk -E `, якщо ентропія низька, то, ймовірно, воно не зашифроване. Якщо ентропія висока, ймовірно, воно зашифроване (або стиснуте якимось чином). Крім того, ви можете використовувати ці інструменти для витягування **файлів, вбудованих у прошивку**: {{#ref}} ../../generic-methodologies-and-resources/basic-forensic-methodology/partitions-file-systems-carving/file-data-carving-recovery-tools.md {{#endref}} Або [**binvis.io**](https://binvis.io/#/) ([code](https://code.google.com/archive/p/binvis/)), щоб перевірити файл. ### Отримання файлової системи З попередніми коментованими інструментами, такими як `binwalk -ev `, ви повинні були змогти **витягти файлову систему**.\ Binwalk зазвичай витягує її в **папку, названу на честь типу файлової системи**, яка зазвичай є однією з наступних: squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs. #### Ручне витягування файлової системи Іноді binwalk **не має магічного байта файлової системи у своїх сигнатурах**. У цих випадках використовуйте binwalk, щоб **знайти зсув файлової системи та вирізати стиснуту файлову систему** з бінарного файлу та **вручну витягти** файлову систему відповідно до її типу, використовуючи наведені нижче кроки. ``` $ binwalk DIR850L_REVB.bin DECIMAL HEXADECIMAL DESCRIPTION ----------------------------------------------------------------------------- --- 0 0x0 DLOB firmware header, boot partition: """"dev=/dev/mtdblock/1"""" 10380 0x288C LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 5213748 bytes 1704052 0x1A0074 PackImg section delimiter tag, little endian size: 32256 bytes; big endian size: 8257536 bytes 1704084 0x1A0094 Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 8256900 bytes, 2688 inodes, blocksize: 131072 bytes, created: 2016-07-12 02:28:41 ``` Запустіть наступну **dd команду**, щоб вирізати файлову систему Squashfs. ``` $ dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs 8257536+0 records in 8257536+0 records out 8257536 bytes (8.3 MB, 7.9 MiB) copied, 12.5777 s, 657 kB/s ``` Альтернативно, також можна виконати наступну команду. `$ dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs` - Для squashfs (використовується в наведеному вище прикладі) `$ unsquashfs dir.squashfs` Файли будуть у директорії "`squashfs-root`" після цього. - Файли архіву CPIO `$ cpio -ivd --no-absolute-filenames -F ` - Для файлових систем jffs2 `$ jefferson rootfsfile.jffs2` - Для файлових систем ubifs з NAND flash `$ ubireader_extract_images -u UBI -s ` `$ ubidump.py ` ## Аналіз ПЗ Після отримання ПЗ важливо розібрати його для розуміння його структури та потенційних вразливостей. Цей процес передбачає використання різних інструментів для аналізу та витягування цінних даних з образу ПЗ. ### Інструменти початкового аналізу Набір команд надається для початкової перевірки бінарного файлу (який називається ``). Ці команди допомагають у визначенні типів файлів, витягуванні рядків, аналізі бінарних даних та розумінні деталей розділів і файлових систем: ```bash file strings -n8 strings -tx #prints offsets in hexadecimal hexdump -C -n 512 > hexdump.out hexdump -C | head #useful for finding signatures in the header fdisk -lu #lists partitions and filesystems, if there are multiple ``` Щоб оцінити статус шифрування зображення, перевіряється **ентропія** за допомогою `binwalk -E `. Низька ентропія вказує на відсутність шифрування, тоді як висока ентропія може свідчити про можливе шифрування або стиснення. Для витягування **вбудованих файлів** рекомендуються інструменти та ресурси, такі як документація **file-data-carving-recovery-tools** та **binvis.io** для перевірки файлів. ### Витягування файлової системи Використовуючи `binwalk -ev `, зазвичай можна витягти файлову систему, часто в каталог, названий на честь типу файлової системи (наприклад, squashfs, ubifs). Однак, коли **binwalk** не може розпізнати тип файлової системи через відсутні магічні байти, необхідно виконати ручне витягування. Це передбачає використання `binwalk` для визначення зсуву файлової системи, а потім команди `dd` для вирізання файлової системи: ```bash $ binwalk DIR850L_REVB.bin $ dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs ``` Після цього, в залежності від типу файлової системи (наприклад, squashfs, cpio, jffs2, ubifs), використовуються різні команди для ручного витягування вмісту. ### Аналіз файлової системи Після витягування файлової системи починається пошук вразливостей безпеки. Увага приділяється небезпечним мережевим демонів, жорстко закодованим обліковим даним, API-інтерфейсам, функціональності серверів оновлень, некомпільованому коду, скриптам запуску та скомпільованим двійковим файлам для офлайн-аналізу. **Ключові місця** та **елементи** для перевірки включають: - **etc/shadow** та **etc/passwd** для облікових даних користувачів - SSL сертифікати та ключі в **etc/ssl** - Конфігураційні та скриптові файли на предмет потенційних вразливостей - Вбудовані двійкові файли для подальшого аналізу - Загальні веб-сервери та двійкові файли IoT пристроїв Кілька інструментів допомагають виявити чутливу інформацію та вразливості в файловій системі: - [**LinPEAS**](https://github.com/carlospolop/PEASS-ng) та [**Firmwalker**](https://github.com/craigz28/firmwalker) для пошуку чутливої інформації - [**The Firmware Analysis and Comparison Tool (FACT)**](https://github.com/fkie-cad/FACT_core) для комплексного аналізу прошивок - [**FwAnalyzer**](https://github.com/cruise-automation/fwanalyzer), [**ByteSweep**](https://gitlab.com/bytesweep/bytesweep), [**ByteSweep-go**](https://gitlab.com/bytesweep/bytesweep-go) та [**EMBA**](https://github.com/e-m-b-a/emba) для статичного та динамічного аналізу ### Перевірки безпеки скомпільованих двійкових файлів Як вихідний код, так і скомпільовані двійкові файли, знайдені у файловій системі, повинні бути ретельно перевірені на вразливості. Інструменти, такі як **checksec.sh** для Unix двійкових файлів та **PESecurity** для Windows двійкових файлів, допомагають виявити незахищені двійкові файли, які можуть бути використані в атаках. ## Емуляція прошивки для динамічного аналізу Процес емулювання прошивки дозволяє **динамічний аналіз** або роботи пристрою, або окремої програми. Цей підхід може стикатися з проблемами залежностей апаратного забезпечення або архітектури, але перенесення кореневої файлової системи або конкретних двійкових файлів на пристрій з відповідною архітектурою та порядком байтів, наприклад, Raspberry Pi, або на попередньо зібрану віртуальну машину, може полегшити подальше тестування. ### Емуляція окремих двійкових файлів Для аналізу окремих програм важливо визначити порядок байтів програми та архітектуру ЦП. #### Приклад з архітектурою MIPS Щоб емулювати двійковий файл архітектури MIPS, можна використовувати команду: ```bash file ./squashfs-root/bin/busybox ``` І щоб встановити необхідні інструменти емуляції: ```bash sudo apt-get install qemu qemu-user qemu-user-static qemu-system-arm qemu-system-mips qemu-system-x86 qemu-utils ``` Для MIPS (big-endian) використовується `qemu-mips`, а для little-endian бінарних файлів вибір буде `qemu-mipsel`. #### Емуляція архітектури ARM Для ARM бінарних файлів процес подібний, з використанням емулятора `qemu-arm`. ### Емуляція повної системи Інструменти, такі як [Firmadyne](https://github.com/firmadyne/firmadyne), [Firmware Analysis Toolkit](https://github.com/attify/firmware-analysis-toolkit) та інші, полегшують повну емуляцію прошивки, автоматизуючи процес і допомагаючи в динамічному аналізі. ## Динамічний аналіз на практиці На цьому етапі використовується реальне або емульоване середовище пристрою для аналізу. Важливо підтримувати доступ до оболонки ОС та файлової системи. Емуляція може не ідеально відтворювати взаємодію з апаратним забезпеченням, що потребує періодичних перезапусків емуляції. Аналіз має повторно перевіряти файлову систему, експлуатувати відкриті веб-сторінки та мережеві сервіси, а також досліджувати вразливості завантажувача. Тести цілісності прошивки є критично важливими для виявлення потенційних вразливостей бекдорів. ## Техніки аналізу в реальному часі Аналіз в реальному часі передбачає взаємодію з процесом або бінарним файлом у його операційному середовищі, використовуючи інструменти, такі як gdb-multiarch, Frida та Ghidra для встановлення точок зупинки та виявлення вразливостей через фуззинг та інші техніки. ## Експлуатація бінарних файлів та доказ концепції Розробка PoC для виявлених вразливостей вимагає глибокого розуміння цільової архітектури та програмування на мовах нижчого рівня. Захисти бінарного часу виконання в вбудованих системах рідкісні, але коли вони присутні, можуть знадобитися такі техніки, як Return Oriented Programming (ROP). ## Підготовлені операційні системи для аналізу прошивки Операційні системи, такі як [AttifyOS](https://github.com/adi0x90/attifyos) та [EmbedOS](https://github.com/scriptingxss/EmbedOS), надають попередньо налаштовані середовища для тестування безпеки прошивки, оснащені необхідними інструментами. ## Підготовлені ОС для аналізу прошивки - [**AttifyOS**](https://github.com/adi0x90/attifyos): AttifyOS - це дистрибутив, призначений для допомоги у проведенні оцінки безпеки та тестування на проникнення пристроїв Інтернету речей (IoT). Він економить ваш час, надаючи попередньо налаштоване середовище з усіма необхідними інструментами. - [**EmbedOS**](https://github.com/scriptingxss/EmbedOS): Операційна система для тестування безпеки вбудованих систем на базі Ubuntu 18.04, попередньо завантажена з інструментами для тестування безпеки прошивки. ## Атаки на зниження версії прошивки та небезпечні механізми оновлення Навіть коли постачальник реалізує перевірки криптографічного підпису для образів прошивки, **захист від зниження версії (downgrade) часто пропускається**. Коли завантажувач або відновлювальний завантажувач лише перевіряє підпис з вбудованим відкритим ключем, але не порівнює *версію* (або монотонний лічильник) образу, що записується, зловмисник може легітимно встановити **стару, вразливу прошивку, яка все ще має дійсний підпис** і таким чином повторно ввести виправлені вразливості. Типовий робочий процес атаки: 1. **Отримати старий підписаний образ** * Завантажити його з публічного порталу завантаження постачальника, CDN або сайту підтримки. * Витягти його з супутніх мобільних/десктопних додатків (наприклад, всередині Android APK під `assets/firmware/`). * Отримати його з сторонніх репозиторіїв, таких як VirusTotal, архіви Інтернету, форуми тощо. 2. **Завантажити або надати образ пристрою** через будь-який відкритий канал оновлення: * Веб-інтерфейс, API мобільного додатку, USB, TFTP, MQTT тощо. * Багато споживчих IoT-пристроїв відкривають *неаутентифіковані* HTTP(S) кінцеві точки, які приймають Base64-кодовані бінарні файли прошивки, декодують їх на сервері та запускають відновлення/оновлення. 3. Після зниження версії експлуатувати вразливість, яка була виправлена в новішому випуску (наприклад, фільтр ін'єкції команд, який був доданий пізніше). 4. За бажанням перепрошити останній образ або вимкнути оновлення, щоб уникнути виявлення після отримання стійкості. ### Приклад: Ін'єкція команд після зниження версії ```http POST /check_image_and_trigger_recovery?md5=1; echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC...' >> /root/.ssh/authorized_keys HTTP/1.1 Host: 192.168.0.1 Content-Type: application/octet-stream Content-Length: 0 ``` У вразливому (зниженому) прошивці параметр `md5` безпосередньо конкатенується в команду оболонки без санітизації, що дозволяє ін'єкцію довільних команд (тут – увімкнення доступу до root через SSH за допомогою ключа). Пізніші версії прошивки впровадили базовий фільтр символів, але відсутність захисту від зниження версії робить виправлення недійсним. ### Витягування прошивки з мобільних додатків Багато постачальників об'єднують повні образи прошивки всередині своїх супутникових мобільних додатків, щоб додаток міг оновлювати пристрій через Bluetooth/Wi-Fi. Ці пакети зазвичай зберігаються незашифрованими в APK/APEX під шляхами, такими як `assets/fw/` або `res/raw/`. Інструменти, такі як `apktool`, `ghidra` або навіть простий `unzip`, дозволяють вам витягувати підписані образи, не торкаючись фізичного обладнання. ``` $ apktool d vendor-app.apk -o vendor-app $ ls vendor-app/assets/firmware firmware_v1.3.11.490_signed.bin ``` ### Checklist for Assessing Update Logic * Чи адекватно захищений транспорт/автентифікація *endpoint оновлення* (TLS + автентифікація)? * Чи порівнює пристрій **номери версій** або **монотонний анти-ролбек лічильник** перед прошивкою? * Чи перевіряється образ у безпечному завантажувальному ланцюзі (наприклад, підписи перевіряються кодом ROM)? * Чи виконує код користувацького простору додаткові перевірки (наприклад, дозволена карта розділів, номер моделі)? * Чи *часткові* або *резервні* потоки оновлення повторно використовують ту ж логіку валідації? > 💡 Якщо щось із вищезазначеного відсутнє, платформа, ймовірно, вразлива до атак ролбеку. ## Vulnerable firmware to practice Щоб практикуватися у виявленні вразливостей у прошивці, використовуйте наступні вразливі проекти прошивки як відправну точку. - OWASP IoTGoat - [https://github.com/OWASP/IoTGoat](https://github.com/OWASP/IoTGoat) - Проект Damn Vulnerable Router Firmware - [https://github.com/praetorian-code/DVRF](https://github.com/praetorian-code/DVRF) - Damn Vulnerable ARM Router (DVAR) - [https://blog.exploitlab.net/2018/01/dvar-damn-vulnerable-arm-router.html](https://blog.exploitlab.net/2018/01/dvar-damn-vulnerable-arm-router.html) - ARM-X - [https://github.com/therealsaumil/armx#downloads](https://github.com/therealsaumil/armx#downloads) - Azeria Labs VM 2.0 - [https://azeria-labs.com/lab-vm-2-0/](https://azeria-labs.com/lab-vm-2-0/) - Damn Vulnerable IoT Device (DVID) - [https://github.com/Vulcainreo/DVID](https://github.com/Vulcainreo/DVID) ## References - [https://scriptingxss.gitbook.io/firmware-security-testing-methodology/](https://scriptingxss.gitbook.io/firmware-security-testing-methodology/) - [Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things](https://www.amazon.co.uk/Practical-IoT-Hacking-F-Chantzis/dp/1718500904) - [Exploiting zero days in abandoned hardware – Trail of Bits blog](https://blog.trailofbits.com/2025/07/25/exploiting-zero-days-in-abandoned-hardware/) ## Trainning and Cert - [https://www.attify-store.com/products/offensive-iot-exploitation](https://www.attify-store.com/products/offensive-iot-exploitation) {{#include ../../banners/hacktricks-training.md}}