Автор: Uri Shaked

После появления статьи Reverse Engineering a Smart Light Bulb со мной связался Эяль, член сообщества TAMI, с предложением об исследовании недавно приобретенного устройства Xiaomi Yeelight WiFi Bulb.

Аббревиатура TAMI расшифровывается как Tel Aviv Makers International (Профсоюз Мастеров из Тель-Авива). Техническая площадка сообщества TAMI оснащена различным электронным оборудованием и компонентами, мастерской по дереву и металлу, станком ЧПУ, ткацкими станками и всеми другими инструментами, необходимыми для работы. Помимо физического пространства у сообщества TAMI есть очень активная группа в Facebook, в которой состоят более 4 тысяч израильских мастеров. Здесь часто обсуждаются вопросы, связанные с электроникой, радиотехникой, производством, лабораторным оборудованием, машиностроением, сантехникой и т. д.

Эяль и я встретились в Тель-Авиве в офисе TAMI, где разработали план по исследованию внутреннего устройства беспроводной электрической лампочки. После короткой дискуссии мы решили начать с аппаратной части: разобрать лампочку и попытаться считать прошивку, которая управляет железом, напрямую с чипа.

Мы предполагали обнаружить цепь для преобразования напряжения, несколько светоизлучающих диодов и цепь управления. Изначально мы не знали, как работать с цепью управления и надеялись опознать модель чипа, извлечь прошивку или даже попробовать отладку прямо во время работы лампы.

Нам удалось без особых усилий снять пластиковую крышку, под которой оказалась плата со светоизлучающими диодами:

Рисунок 1: Светоизлучающие диоды электрической лампочки

Как видно на рисунке выше, внутри находятся 7 высокомощных диодов, излучающих теплый белый свет, и небольшая цепь, чуть выдвинутая посередине. Для удаления цепи требовалось сломать оболочку лампочки, что мы сделали при помощи инструмента от компании Dremel:

Рисунок 2: Разрезание оболочки

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

Рисунок 3: Внутреннее устройство электрической лампочки

Первая наша встреча закончилась ужином в традиционном индийском ресторане 24 Rupee (который я горячо рекомендую, если вы когда-либо окажетесь в Тель-Авиве), где мы наметили время следующей встречи с целью извлечения прошивки.

Вторая встреча проходила в FabLab Hulon, широко известном месте, где работают производители, в основном связанные с цифровыми технологиями. Здесь можно увидеть множество 3D принтеров, лазерных резаков, фрезерных станков и радиоэлектронную аппаратуру. На площадке FabLab Hulon делают специальные проекты, в частности мастерскую цифровой живописи для слепых и слабовидящих детей.

Целью нашей второй встречи было извлечение прошивки из электронной лампочки. При помощи лупы удалось найти номера компонентов. Используя поисковую систему, мы выяснили модели:

• 88MW300 — A Marvell Wi-Fi Microcontroller system-on-chip (SoC).
• 25Q16BVSIG — 16M-Bit Serial Flash Memory Chip.

Рисунок 4: CPU и флеш-память

Быстро выяснилось, что процессор на базе архитектуры ARM. Существует множество утилит для работы с данными процессорами, включая стандартный метод отладки.

Мы отпаяли плату логики (белая) от платы питания (зеленая) и подсоединили два пина к источнику питания. К сожалению, когда после включения питания появился дымок. Скорее всего, где-то оказалась закорочена цепь.

Вывод: отладка процессора по месту не представляется возможным.

Рисунок 5: Присоединение платы логики к внешнему источнику питания

Забавный факт: 3 из 8 пинов на белой плате не были припаяны, а поскольку данные концы помечены “R”, “B”, “G”, возможно, это означает, что логическая плата используется для лампочки RGBW.

Микросхему флеш-памяти (которая содержит прошивку и, следовательно, код, управляющий питанием лампочки) демонтировать оказалось достаточно просто.

Микросхема памяти представляет собой обычную серийную флеш. К тому же, у нас под рукой оказалась плата Raspberry Pi, не раз меня выручавшая, когда дело доходило соединения с нестандартным оборудованием. В нашей ситуации мы смогли найти утилиту «flashrom», которая могла читать и писать на серийную флешку, подсоединенную к GPIO-пинам (General Purpose Input/Output; входные/выходные пины общего назначения) платы Raspberry Pi.

Рисунок 6: Флеш-память, подсоединенная к плате Raspberry Pi

После установки утилиты Flashrom и подсоединения флеш-памяти к плате Raspberry Pi мы запустили следующую команду:
flashrom -p linux_spi:dev=/dev/spidev0.0 -read yeerom.bin

После минуты напряженного ожидания прошивка была извлечена:

Рисунок 7: Успешное извлечение прошивки из флеш-памяти

Наконец-то мы получили нечто, с чем можно работать: файл с прошивкой размером 2 МБ. С этого момента начинается программная часть нашей истории.

Первое, что нужно сделать после извлечения прошивки, - обработать полученный файл при помощи утилиты strings, используемой для извлечения всех строк. Например, на рисунке ниже показаны все строки, содержащие последовательность символов http:

Рисунок 8: Перечень строк из прошивки, содержащих фразу http

Как видно на рисунке выше, в коде прошивки активно используется протокол HTTP, и один из узлов для общения - https://cloud.yeelight.com/open/wifi_device_stats. Нам показалось, что найдено нечто интересное.

Другие полезные вещи, которые мы нашли при изучении строк, – SSL-сертификат, несколько структур JSON и перечень строк, напоминающий имена команд, отправляемых с сервера (см. рисунок ниже).

Рисунок 9: Перечень возможных команд, отправляемых с сервера

Ниже показан декодированный сертификат:

Рисунок 10: SSL сертификат

Кажется, что разработчики всерьез позаботились о безопасности при взаимодействии с сервером cloud.yeelight.com при помощи сертификата, встроенного в прошивку. Чтобы точно удостовериться, что именно данная лампочка на другом конце провода, а не злоумышленник (эта атака называется SSL public key pinning).

Исследуя только лишь информацию, полученную при помощи утилиты strings, мы уже выяснили некоторые интересные особенности протокола, используемого электрической лампочкой. Следующий шаг – изучение кода, который отвечает за подачу энергии на лампочку.

Мы выгрузили содержимое файла при помощи утилиты hd (hex dump) и обнаружили несколько секций, включая ту, которая представляет собой файловую систему, индексирующую остальные секции из образа прошивки.

Рисунок 11: Различные секции прошивки

Из рисунка выше видно, что в образе прошивки содержится две копии секций app и wifi и некоторые другие секции, одна из которых использует пользовательские данные, включающие, как выяснилось позже, имя пользователя и пароль для WiFi в открытом виде, сконфигурированные нами перед началом исследования.

У нас не было необходимости декодировать структуру таблицы, поскольку там было большое количество нулевых байтов, разделяющих секции. Мы выяснили, что прошивка (одна из двух копий) находится по смещению 0xa000, и извлекли нужные данные при помощи команды dd:

dd if=yeerom.bin bs=$((0xa000)) skip=1 count=7 of=firmware.bin

Затем я наивно попытался загрузить полученный .bin файл в IDA, популярную утилиту, используемую в реверс-инжиниринге. Я надеялся получить дополнительную информацию о формате прошивки. Возможно, данный формат имел отношение к модели Marvell (если взглянуть внутрь файла, то вначале можно увидеть 4 байта - MRVL).

Затем я решил выяснить, как правильно загрузить прошивку. Начало файла выглядело как соответствующее некоторому формату. Возможно таблица секций и смещений.

Рисунок 12: Начало прошивки

Я решил поискать в интернете информацию о модели 88MW300 и о формате «MRVL». В итоге по этой теме нашлось очень мало, но мне удалось найти SDK с открытым исходным кодом от компании Marvell, цель которого – помочь разработчикам в создании IoT-устройств на базе их чипа и облака Amazon. В SDL было несколько примеров, при помощи которых создавались прошивки. Для сборки использовалась утилита axf2firmware, также являющаяся частью SDK. Таблица содержит записи размером 20 байт, каждая из которых имеет следующую структуру (DWORD – целое размером 4 байта в формате с прямым порядком байтов):

DWORD magic;     // Always 0x2
DWORD offset;    // Offset into the file
DWORD size;      // Size of the section
DWORD address;   // Memory address where this section will be loaded
DWORD unknown;   // Probably some kind of checksum?

Благодаря этой информации мне удалось считать таблицу секций, которые мне удалось разделить на несколько файлов при помощи следующей команды:

dd if=firmware.bin bs=200 skip=1 | dd bs=11920 count=1 of=s1.bin
dd if=firmware.bin bs=12120 skip=1 | dd bs=1 count=272180 of=s2.bin
dd if=firmware.bin bs=284300 skip=1 | dd bs=4104 count=1 of=s3.bin

В итоге у меня получилось три файла: s1.bin, s2.bin и s3.bin. На базе информации из таблицы выше теперь я знаю, по каким адресам находятся данные файлы при загрузке прошивки. Я решил объединить все файлы в такой формат, который потом можно загрузить в IDA. Я выбрал ELF (или формат исполняемых файлов в ОС Linux), поскольку данный формат хорошо задокументирован.

Вначале я установил бинарные утилиты для работы с ELF-файлами:

sudo apt-get install binutils-arm-none-eabi

Затем запустил следующую команду для сборки всех секций в единый ELF-файл:

arm-none-eabi-objcopy -I binary -O elf32-littlearm -set-start 0x134 -adjust-vma 0x100000 -binary-architecture arm -rename-section .data=.text,contents,alloc,load,readonly,code -add-section .text2=s2.bin -set-section-flags .text2=contents,alloc,load,readonly,code -change-section-address .text2=0x1f002f58 -add-section .text3=section3.bin -set-section-flags .text3=contents,alloc,load,readonly,code -change-section-address .text3=0x20000000 s1.bin firmware.elf

Эта команда довольно длинная и требует несколько часов на преобразование всех битов к правильному формату. Нужно указать 3 файла, содержащие секции, адрес, куда требуется загрузить эти секции, флаги для пометки секций как секции кода с атрибутом «только чтение» (так, чтобы была возможность дизассемблирования / декомпиляции) и инструкцию для установки базового адреса 0x100000 и начала выполнения кода по смещению 0x134.

Итоговый файл с именем firmware.elf я смог загрузить IDA, но, к сожалению, в увиденном коде было не очень много смысла.

IDA, как и предполагалось, интерпретировал файл как машинный ARM-код, однако выяснилось, что ARM-процессоры имеют специальный рабочий режим под названием «Thumb». В режиме Thumb инструкции закодированы в 2 байта (16 бит) вместо 4 байт (32 бит).

Сие недоразумение можно легко исправить, переместившись в самое начало файла, найдя строку CODE32, нажав Alt+G и изменив значение на 0x1 (все эти секреты я выяснил через Google).

Рисунок 13: Изменение значения в строке CODE32

Выполнив вышеуказанную операцию я получил огромное количество ассемблерного ARM-кода. Однако даже несмотря на то, что IDA может автоматически опознавать функции, сложно выяснить назначение этих функций. Здесь есть интересный трюк – во многих случаях в коде прошивки встречаются отладочные метки, используемые при разработке, и эти метки очень полезны при выяснении логики работы кода. После некоторых исследований мне удалось найти функцию printf, при помощи которой я нашел отладочные комментарии, используя клавишу “X”, отображающую все участки кода, где используется функция printf:

Рисунок 14: Все участки кода со ссылкой на функцию printf()

На этом мое участие в данном проекте закончилось. Надеюсь, что информация, представленная в этой статье, окажется полезной тем, кто часто имеет дело с оборудованием и занимается исследованием прошивок.