Как взломать мобильный Wi-Fi роутер

    С появлением Интернета все наши сферы жизни приобрели более качественный уровень. Это касается и работы, и досуга, и сервиса и прочего. Поэтому очень важно всегда иметь доступ к сети. И постоянно развивающиеся технологии помогают нам в этом. Если дома проблем с доступом нет (его обеспечивает проводной Интернет), то, находясь вне дома (в загородном доме, на природе, в автомобиле и так далее), спасает беспроводной Интернет Wi — Fi. Именно он с помощью компактного универсального устройства карманного роутера обеспечивает точку доступа к всемирной паутине в любом месте и в любое время.

У меня есть Alcatel MW41, мобильный WiFi-роутер. У меня нет претензий к тому, как это работает, но то, как он устроен, вызывает несколько вопросов. Создается впечатление, что на нем работает какое-то программное обеспечение (точнее, веб-сервер, который предоставляет интерфейс для выполнения настроек устройства). Эта гипотеза заставила меня задать следующие вопросы:

1. Работает ли на устройстве Linux?

       2.Если Linux на роутере работает, то можно ли получить на нём root-права?

TCL-SWITCH-TOOL

Некоторые изыскания привели меня к положительному ответу на первый вопрос. На устройстве, и правда, работает Linux. А ещё я узнал, что есть специальная программа, способная дать root-доступ к мобильному роутеру. Это — TCL-SWITCH-TOOL. Единственное упоминание этой программы я нашёл на одном русском форуме. Откуда взялась эта программа, не сообщается. Программа выглядит сыроватой, но ненамного. Ссылка выше ведет на страницу, посвященную подобному устройству, как у меня, — Alcatel MW40V, но программа также подошла на мой Alcatel MW41 и, похоже, работает и на других подобных устройствах. Работа программы, видимо, основана на том, что при подключении роутера к компьютеру он выглядит как внешний жесткий диск. TCL-SWITCH-TOOL что-то делает с устройством, он переходит в режим отладки, который дает нам root-доступ к командной оболочке.

Программа предназначена исключительно для Windows. Но она, скорей всего, должна заработать и под Wine. Я загрузил программу, запустил её, нажал кнопку SWITCH : 0x16 0xF9(debug) для переключения устройства в режим отладки и…

50

50? Странно… Закрытие этого окна приводит к появлению ещё одной ошибки.

Программа не работает

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

0009:fixme:ntdll:server_ioctl_file Unsupported ioctl 4d014 (device=4 access=3 func=405 method=0)

Похоже, что тут нам сообщают о том, что программа использует некую возможность, которую не полностью поддерживает Wine.

Тут я мог бы отыскать Windows-компьютер и воспользоваться им. Но мы не ищем лёгких путей! Можно ли узнать о том, как именно работает эта программа, и воспроизвести это самостоятельно?

Как это работает?

Я решил исследовать программу с помощью Ghidra, инструмента для реверс-инжиниринга ПО. В ходе поиска по тексту предыдущего сообщения об ошибке, switch device error, я обнаружил несколько ссылок на соответствующую строку. Все они выглядели как составные части сравнительно сложных функций. Конечно, и этот подход позволил бы разобраться с тем, как именно работает программа. Но, может, есть более лёгкий способ это выяснить?

В списке XREF видно, что ссылки на строку есть в четырёх различных функциях

Учитывая то, что программа запрашивает букву диска, соответствующую роутеру, кажется, что разумным будет предположить то, что она каким-то образом отправляет диску некие специальные команды, используя существующее соединение. То есть — не пользуется неким экзотическим USB-протоколом. Такое ощущение, что это подтверждает присутствие в коде такой строки: \\.\PHYSICALDRIVE%c. Это, возможно, указывает на использование некоего механизма для прямого доступа к диску.

Таинственная строка \\.\PHYSICALDRIVE%c

Представьте, что программа каким-то образом открывает диск, а затем, выполняя какие-то загадочные действия, переводит роутер в режим отладки. Сложность TCL-SWITCH-TOOL в данном случае не важна, поскольку в конечном итоге для выполнения обеих этих операций нужно использовать Windows API, который по отношению к программе является внешним ресурсом.

Отладочные материалы Wine

Мониторить вызовы API можно, воспользовавшись отладочными возможностями Wine для включения отладочного канала relay. Эта система делает запись в журнале каждый раз, когда TCL-SWITCH-TOOL обращается к внешней библиотеке (в Windows такие библиотеки называют DLL). Я надеялся, что можно будет обнаружить вызов некоей DLL Windows, ответственной за открытие диска, и передачу этой DLL соответствующих команд. Это смогло бы прояснить ситуацию с тем, как именно работает программа.

Это очень похоже на то, как в Linux функционирует strace. Но тут весь код работает в пользовательском режиме, а мы просто наблюдаем за пересечением границ между двумя разными DLL. А strace, с другой стороны, отслеживает системные вызовы, когда запрашивается использование неких возможностей ядра. Более близкий аналог этого из мира Linux называется ltrace.

Итак, я выполнил следующую команду:

WINEDEBUG=relay wine TCL-SWITCH-TOOL.exe &> tcllog.log

Затем я ввел имя диска и нажал кнопку, чтобы перевести маршрутизатор в режим отладки. В результате у меня получился довольно длинный лог-файл (а именно, его размер был 150 МБ). Я искал ключевое слово PHYSICALDRIVE, которое я знаю из предыдущих экспериментов, и … ничего. Поскольку этот подход не сработал, я решил поискать имя диска, которое я ввел (F), полагая, что программа, вероятно, должна каким-то образом передать имя диска Windows.

Вызовы разных функций, записанные в журнал

Сработало !

Вроде сработало! В журнале каждая строка соответствует либо вызову функции (это строки с меткой Call), либо возврату из нее (строки с меткой Ret). В верхней части предыдущего рисунка вы можете увидеть, как TCL-SWITCH-TOOL вызывает функцию CreateFileA, которая является частью KERNEL32, передавая \\. \\ F: (в файле журнала есть двойная обратная косая черта, которая является результатом экранирования символов в двойных кавычках).Затем реализация Wine для KERNEL32 сама вызывает некоторые функции, после чего решает, что пора вернуть какое-то значение (строка 0009: Ret KERNEL32.CreateFileA () ближе к нижней части приведенного выше фрагмента журнала).

Затем TCL-SWITCH-TOOL выполняет еще один вызов. На этот раз вызывается функция DeviceIoControl из KERNEL32. Эта функция похожа на то, что мы ищем.Ей передается единственный параметр — 4d014. Это значение соответствует сообщению об ошибке, которое мы постоянно получали от Wine в самом начале. Правда я так и не понял, что случилось с линией \\. \ PHYSICALDRIVE% c. А позже оказалось, что это один из способов доступа к дискам в Windows, когда использовался индекс диска, а не его имя. Эта строка, вероятно, использовалась в другом компоненте программы.

А что такое DeviceIoControl? Если заглянуть в официальную документацию Microsoft, то получается, что это — довольно-таки универсальная функция, которая выполняет некие действия, опираясь на параметр dwIoControlCode (в целом, её можно назвать Windows-версией ioctl). В нашем случае значением dwIoControlCode является 0x4d014, что соответствует IOCTL_SCSI_PASS_THROUGH_DIRECT, а это то, что, в соответствии с документацией, «позволяет приложению отправлять почти любые SCSI-команды целевому устройству».

Поиск команды

В этот момент у меня сложилось впечатление, что вызов этой функции — это суть TCL-SWITCH-TOOL. Какую команду SCSI программа отправляет устройству? Я снова использовал инструмент Ghidra, чтобы узнать, откуда вызывается DeviceIoControl.

Ссылка на DeviceIoControl из KERNEL32.dll

В правом нижнем углу предыдущей иллюстрации есть строка, которая начинается с XREF. Она сообщает нам, что есть только одна ссылка на эту функцию во всей программе (то есть нам говорят, что функция вызывается в программе только один раз). Двойной щелчок по этой строке приводит нас к коду, который вызывает DeviceIoControl.

Единственное место в программе, где используется DeviceIoControl

Сборка в Ghidra

Теперь можнаа изучить сборку в Ghidra и увидеть, как строятся различные аргументы для DeviceIoControl. Но то же самое можно сделать проще. Мы знаем, что вызов функции находится по адресу 0x4031d4. Следовательно, вы можете использовать отладчик Wine для установки точки останова по этому адресу. Затем мы можем запустить программу, она остановится там, где нам нужно, и мы сможем отобразить аргументы функции. Адреса функций обычно рандомизируются из-за использования ASLR. Но GDB автоматически отключает ASLR. Поэтому нам не о чем беспокоиться.

Итак, я выполнил команду winedbg --gdb TCL-SWITCH-TOOL.exe и воспользовался командой b *0x4031d4 для установки точки останова. После этого я снова попробовал воспользоваться программой.

Установка (и срабатывание!) точки останова

Точка останова сработала! Как теперь разобраться с аргументами функции?

В системах Windows x86 используется соглашение о вызовах функций cdecl (то есть — набор правил, которые, кроме прочего, указывают на то, куда попадают аргументы функций и возвращаемые ими значения). А это значит, что аргументы должны были быть помещены в стек. GDB позволяет взглянуть на текущее содержимое стека.

Содержимое стека

Команда, которую мы тут используем, x/10x $sp, предлагает GDB вывести 10 шестнадцатеричных слов, начиная с адреса, хранящегося в регистре sp (stack pointer, указатель стека). Этот подход работает благодаря тому, что в x86-системах стек растёт вниз. Подробности об этом смотрите здесь.

Значения из стека можно сопоставить с аргументами DeviceIoControl (повторяю, их описание можно найти здесь). В документации говорится, что IOCTL_SCSI_PASS_THROUGH_DIRECT принимает команду SCSI для отправки устройству через входной буфер, который должен соответствовать третьему аргументу DeviceIoControl — lpInBuffer. В нашем случае третий аргумент — 0x32ed90. И четвертый аргумент, nInBufferSize, содержит информацию о размере этого входного буфера. Вот это 0x50 байт. Итак, давайте посмотрим на 0x50 байт из 0x32ed90.

Содержимое lpInBuffer

Итак, это ли та самая команда, благодаря которой программа позволяет взломать роутер? Страница документации по IOCTL говорит нам о том, что это должна быть структура SCSI_PASS_THROUGH_DIRECT. Вот как она выглядит:

typedef struct _SCSI_PASS_THROUGH_DIRECT {
  USHORT Length;
  UCHAR  ScsiStatus;
  UCHAR  PathId;
  UCHAR  TargetId;
  UCHAR  Lun;
  UCHAR  CdbLength;
  UCHAR  SenseInfoLength;
  UCHAR  DataIn;
  ULONG  DataTransferLength;
  ULONG  TimeOutValue;
  PVOID  DataBuffer;
  ULONG  SenseInfoOffset;
  UCHAR  Cdb[16];
} SCSI_PASS_THROUGH_DIRECT, *PSCSI_PASS_THROUGH_DIRECT;

Данные, полученные из GDB, можно сопоставить с полями этой структуры. В Windows тип данных ULONG представляет собой 32-битное целое число. Кроме того, при отладке 32-битных приложений нужно учитывать то, что PVOID — это тоже 32-битное значение.

Воспроизведение команды

Теперь, когда мы расшифровали структуру выше, давайте выясним, какие именно действия предлагает эта структура для запуска Windows. Большинство сфер нам не интересны. Самое важное для нас поле — это Cdb. Согласно документации, он «определяет блок дескриптора команды SCSI, который должен быть отправлен на целевое устройство».Другими словами, это должна быть та же команда, которая переводит ваш маршрутизатор в режим отладки! Затем, когда эта команда отправляется, поскольку флаг DataIn установлен в 0x01 (что эквивалентно SCSI_IOCTL_DATA_IN), Windows будет читать 0xc0 или 192 байта (значение DataTransferLength) с устройства. В архитектуре x86 используется формат little-endian. Следовательно, байты 0xc0 0x00 0x00 0x00 интерпретируются как 32-битное целое число 0x000000c0.

Некоторые изыскания вывели меня на команду sg_raw — на Linux-инструмент, который позволяет отправлять SCSI-устройствам произвольные команды (в Ubuntu это средство можно найти в пакете sg3-utils). Если использовать значение из Cdb, то интересующая нас команда будет выглядеть так:

sudo sg_raw /dev/sgX 16 f9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -v

Здесь X — это номер, соответствующий диску роутера. Это будет, вероятно, либо 1, либо — 2. Для того чтобы просмотреть список SCSI-устройств, подключённых к компьютеру, можно воспользоваться командой ls /dev/sg*.

Я попробовал выполнить эту команду.

Успешные результаты выполнения команды

Итоги

Если вы внимательно прочитали мою историю, вы могли заметить, что первые два байта команды (0x16 0xf9) одинаковы, написанные на TCL-SWITCH-TOOL, SWITCH: 0x16 0xF9 (отладка), кнопка, используемая для перевода маршрутизатора в режим отладки (Вы можете увидеть это на скриншоте в начале статьи). Но, хотя решение нашей проблемы изначально было так близко, я не думаю, что проделал всю эту работу напрасно.Все это помогло мне понять, как именно формируются эти байты. Это вдобавок означает, что, возможно, устройство можно переключить в «режим диагностики», «diag», потому что на другой кнопке есть соответствующая надпись SWITCH: 0x16 0xF5 (diag) (думаю, слово «diag» Кнопка связана с протоколом Qualcomm DIAG, но я все еще ищу эту проблему).

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

И еще одно — adb (Android Debug Bridge,отладочный мост Android) используется для доступа к командной оболочке роутера. Хотя маршрутизатор не работает под управлением Android, он, вероятно, использует adbd, а также некоторые другие компоненты Android. Подробное изучение всех программ, которые работают на Alcatel MW41, могло бы стать темой одной из моих следующих статей.

Как бы вы поступили с мобильным Wi-Fi роутером имея бы root доступ к нему?Пишем в коменты)