Как создать поддельную флешку на 1 ТБ и какая здесь связь с BadUSB

Прокомментировать Просмотры: 6

Рынок микроэлектроники переживает очередной виток подорожания. За прошедшие двенадцать месяцев ценники выросли настолько, что твердотельный накопитель от проверенного вендора стал восприниматься скорее как предмет роскоши, нежели как стандартный компонент системы. Одновременно с этим на маркетплейсах творится настоящий аттракцион щедрости: брендовые накопители колоссального объема отдают буквально за бесценок. Очевидно, что за столь привлекательным фасадом кроется подвох…

Приветствую! Меня зовут Денис Астафиев, я руковожу направлением аппаратных исследований в компании «Бастион». Тема фальсифицированных флешек регулярно всплывает как на SE7ENе, так и на других профильных площадках. Однако чаще всего авторы ограничиваются взглядом со стороны рядового потребителя: разбирают методы выявления подделок, утилиты для проверки реальной емкости и базовую диагностику. Мне же показался куда более любопытным инженерный аспект: за счет чего недобросовестные производители добиваются подобного эффекта и на какие модификации они способны, помимо тривиальной правки одного байта в конфигурации контроллера? Разумеется, существовал единственный надежный способ выяснить это…

Что покажет вскрытие?

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

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

Неужели перед нами абсолютно честный продукт?

Иллюзия рассеивается при первом же запуске бенчмарка: пропускная способность при записи бесконечно далека от возможностей спецификации USB 3.0.

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

Поняв, что штатными средствами операционной системы полную картину не составить, я подключил накопитель к стенду под управлением Linux и запустил диагностику из набора f3 (Fight Flash Fraud) (под macOS данный пакет поставляется со значительными функциональными ограничениями).

Худшие подозрения мгновенно подтвердились: физически доступный объем памяти составляет всего около одного мегабайта.

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

Внутри, помимо глухого пластика, занимающего не менее 80% внутреннего объема, обнаружился скромный набор: пара миниатюрных микросхем и базовая обвязка. Где же спрятан терабайт? Его здесь не было изначально — роль единственного физического хранилища данных выполняет копеечная SPI-флеш емкостью 16 Мбит (всего 2 МБ).

Прямо скажем, результат обескураживающий. Обычно создатели подобного фальсификата устанавливают отбракованную NAND-память хотя бы на пару гигабайт, но в данном случае производитель решил сэкономить абсолютно на всем, распаяв копеечную микросхему для хранения BIOS. Фактически перед нами не накопитель, а бутафорский брелок.

Исключительно ради академического интереса микросхему выпаяли, вычитали программатором и изучили дамп (для желающих повторить: переходник USON8 4×3, микросхема GD25LQ16). Однако внутренняя структура лишь продублировала ранее зафиксированные сведения:

Field

Value

bLength

0x12 / 18

bDescriptorType

0x01 / DEVICE

bcdUSB

0x0200 / USB 2.00

bDeviceClass

0x00 / class defined per interface

bDeviceSubClass

0x00

bDeviceProtocol

0x00

bMaxPacketSize0

64

idVendor

0x2013

idProduct

0x0917

bcdDevice

0x0000

Index

Offset

Raw descriptor bytes

Display string

0

0x000084

04 03 09 04

English (United States), LANGID 0x0409

1

0x000088

12 03 54 00 35 00 00 00 00 00 00 00 00 00 00 00 00 00

T5

2

0x00009a

22 03 46 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

F8

3

0x0000bc

22 03 31 00 31 00 31 00 30 00 30 00 30 00 35 00 38 00 37 00 35 00 38 00 00 00 00 00 00 00 00 00 00 00

11100058758

Механика исчезновения данных

У неподготовленного пользователя наверняка возникнет закономерный вопрос: «Как же на такой носитель успешно копируются тяжелые файлы и почему проводник продолжает их отображать?».

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

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

Хотя в оригинале структура файла выглядит совершенно иначе:

В данном сценарии контроллер просто имитирует успешное выполнение операций ввода-вывода. Поскольку подобное поведение не регламентировано никакими стандартами, прошивка может вести себя непредсказуемо: перезаписывать доступные секторы по кругу, молча отбрасывать пакеты или отправлять данные в «черную дыру». Финал у всех этих вариантов один — гарантированная утрата файлов.

Воссоздаем поведение в лаборатории

Поскольку весь секрет кроется в прошивке контроллера, воспроизведем этот алгоритм на тестовом стенде. Для этого задействуем:

  • GreatFET One — аппаратную платформу для отладки и эмуляции протоколов USB;

  • библиотеку facedancer, позволяющую разворачивать виртуальные USB-устройства напрямую из Python-скриптов.

Подготовим окружение:

python3 -m venv ~/venvs/greatfet
source ~/venvs/greatfet/bin/activate
pip install --upgrade greatfet facedancer

Убедимся в корректности подключения GreatFET One:

greatfet info

Сгенерируем разреженный (sparse) образ диска нужного объема:

mkdir -p ~/greatfet-1tb
cd ~/greatfet-1tb
truncate -s 1000000000000 fake-1tb.img
ls -lh fake-1tb.img
du -h fake-1tb.img

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

Берем штатный пример эмуляции Mass Storage из состава facedancer и натравливаем его на наш файл образа:

curl -L -o mass-storage.py https://raw.githubusercontent.com/greatscottgadgets/facedancer/main/examples/mass-storage.py
export BACKEND=greatfet
python3 mass-storage.py fake-1tb.img

Подключаем target-интерфейс платы к компьютеру — операционная система тут же монтирует накопитель объемом 1 ТБ, с которого даже можно прочесть базовую структуру (хоть и небыстро в силу программной эмуляции).

В логах терминала можно наблюдать детальный обмен низкоуровневыми USB-пакетами между хостом и контроллером.

К слову, почему создатели контрафакта прошивают объем именно в 1 ТБ, а не сразу петабайты? Все дело в SCSI-командах: для дисковых пространств до ~2 ТБ хост использует инструкцию READ CAPACITY(10). Чтобы заявить больший объем, требуется поддержка команды READ CAPACITY(16) с совершенно другим форматом дескрипторов ответа. Это неизбежно потребовало бы более сложного микрокода и дорогой аппаратной базы, что лишает кустарное производство экономической целесообразности.

Реальная цена копеечной экономии

Через пару дней после оформления заказа карточка товара была оперативно заблокирована маркетплейсом. Тем не менее, сотни аналогичных позиций в идентичных корпусах и с накрученными положительными отзывами по-прежнему находятся в открытой продаже. Конвейер работает без сбоев, и поток обманутых покупателей не иссякает.

Финансовый ущерб в пару сотен рублей неприятен, но вряд ли критичен. Куда серьезнее другой аспект: что, если подобный копеечный девайс несет в себе скрытый и куда более опасный функционал?

Многие помнят легендарный доклад BadUSB — On Accessories that Turn Evil, прозвучавший на конференции BlackHat 2014 и заложивший фундамент для атак через эмуляцию устройств ввода. Исследователи успешно модифицировали прошивку контроллера Phison 2251-03 — одного из самых тиражируемых чипов на рынке, — заставив накопитель исполнять произвольные команды в режиме клавиатуры. Хотя контроллер нашего подопытного невозможно идентифицировать из-за полного отсутствия маркировки, история знает немало наглядных примеров масштабных аппаратных атак:

  • Best Buy, 2008 год. Фирменные цифровые фоторамки бренда Insignia еще на этапе фабричной сборки были заражены трояном Mocmex. Вредонос умел подавлять работу более сотни антивирусных систем и загружать дополнительные модули из сети. Аналогичные инфицированные партии всплывали в крупнейших торговых сетях вроде Sam’s Club, Target и Costco.

  • IBM, 2017 год. Корпоративные клиенты IBM вместе с комплексами хранения Storwize получили сервисные флеш-накопители, содержавшие червь W32.Faedevour!inf. Все носители имели идентичный серийный номер — 01AC585. Источник проникновения зловреда в цепь поставок вендор так и не раскрыл, порекомендовав клиентам физически уничтожить подозрительные носители.

  • Силы самообороны Японии, 2024–2025 годы. На протяжении года (с марта 2024 года) личный состав ведомства использовал контрафактные USB-накопители, где вместо полноценной памяти распаяли медленные microSD-карты. На ряде устройств присутствовал вредоносный код, аффилированный с китайской APT-группировкой и срабатывающий при подключении к ПК. Флешки приобретались на маркетплейсах по демпинговым ценам, а антивирусное ПО не инспектировало их из-за исключений в политиках безопасности. Компрометацию вскрыли лишь в феврале 2025 года: за это время вредонос успел проникнуть более чем на 50 рабочих станций, включая закрытые сегменты с секретным документооборотом.

Можно возразить: кому нужно устраивать таргетированные атаки на обычных пользователей интернет-магазинов? Действительно, публичные сообщения о подобных инцидентах появляются нечасто. Однако вектор BadUSB никогда не требовал строгого таргетинга. Поэтому нет никакой гарантии того, чем окажется следующий безымянный гаджет, подключенный к вашему компьютеру, — безобидной дешевкой или скрытым аппаратным бэкдором.


PURP — Telegram-канал, где кибербезопасность раскрывается с обеих сторон баррикад

t.me/purp_sec — инсайды и экспертный анализ из мира этичного хакинга и практической безопасности от команды «Бастиона»

 

Источник

Поделиться:

Похожие статьи

Поиск по играм, новостям и статьям…

Введите не менее двух символов

Введите не менее двух символов