Я заказчик Проект: обратный инжиниринг прошивки Initio INIC-1610 (8051) из SPI-флеш (SST25VF010A, 128 КБ) Цель: выяснить, как прошивка работает с «хвостом» HDD

[Guardian0x00]

Цель: выяснить, как прошивка работает с «хвостом» HDD (последние десятки секторов), и используется ли этот хвост как:
– токен/анти-swap,
– либо как контейнер ключа (eDEK) / параметров шифрования,
– либо вообще как нечто третье.

Входные данные:​

• бинарный дамп U4.bin (SST25VF010A, 128 КБ);
• описание железа (модель 57Y4400, USB диск на INIC-1610 + PIC16F883);
• экспериментальные наблюдения:
  
  • хвост 32 КБ с «магическими байтами» 25 C9 9C ...;
  • при смене PIN / admin PIN на новом устройстве содержимое хвоста не меняется (бит-в-бит одинаковые дампы);
  • иногда изменение байтов в хвосте через SATA приводит к появлению или пропаже LUN.

Задачи:​

1. Базовый реверс прошивки:
   
   • настроить в Ghidra/IDA 8051-проект, указать правильную карту памяти (CODE/XDATA/IDATA, внешние регистры);
   • выявить стартовую точку (reset vector, boot-код);
   • найти обработчики USB/SATA/ATA, таблицы команд.
2. Поиск логики чтения хвоста HDD:
   
   • найти использование ATA команд 0xEC, 0xC8, 0x25;
   • отследить где прошивка получает MaxLBA (результат IDENTIFY DEVICE);
   • найти арифметику вида LBA_tail = MaxLBA - const (например, 0x3F сектора, 32 КБ и т.п.);
   • найти код, который инициирует чтение именно этого диапазона.
3. Анализ обработки буфера хвоста:
   
   • определить адрес в XDATA / внутренней RAM, куда читается хвост;
   • проследить дальнейший data-flow:
     
     • цикл по буферу с подсчётом суммы/CRC/хеша и последующим сравнением с константой или регистром;
     • либо цикл копирования байтов в фиксированный диапазон XDATA (предполагаемые MMIO-регистры криптоблока, например 0xB000–0xBFFF).
4. Поиск связки с AES / криптологикой INIC:
   
   • найти функции, настраивающие шифрование (режим, ключ, IV);
   • выяснить, откуда берутся байты ключа (из хвоста или от внешнего МК по какому-то интерфейсу);
   • зафиксировать адреса регистров, куда пишется ключ/вектор.
5. Отчёт / выводы:
   
   • текстовое описание найденных функций (адреса, назначение, псевдокод);
   • схема: «ATA READ → буфер → … → (CRC check / MMIO write)»;
   • однозначный ответ: используются ли данные хвоста как ключ/IV, или только как проверка/токен;
   • если есть, отметить любые проверки, которые при несоответствии приводят к отсутствию LUN / блокировке диска.

Что НЕ требуется:​

• не нужно писать эксплойты, ломать защиту, подбирать PIN и т.д.;
• задача — анализ логики прошивки, а не фактический взлом устройства.

 

[for]

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

 

[Guardian0x00]

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

Да, я тоже всё больше склоняюсь к версии «токен/ID, а не ключ». На свежем 57Y4400 я снимал хвост 32 КБ до/после смены user PIN и admin PIN — дампы бит-в-бит одинаковые, т.е. никакой eDEK там не перегенерируется. Плюс сам хвост лежит очень «правильно» — по адресу где и ожидаешь, без обфускации, с понятной сигнатурой 25 C9 9C…, что больше похоже на анти-swap/anti-clone метаданные, чем на ключ с шумом.


Логику шифрования, похоже, реально вынесли в отдельный МК с защищённой флешью (PIC + AES-блок), а INIC через U4 просто проверяет токен и решает, давать LUN или нет. Сейчас пытаюсь как раз это подтвердить через дизасм U4: если найдём только проверку хвоста (CRC/хеш/сравнение) без копирования в MMIO AES-регистров — вопрос «ключ vs токен» можно будет закрыть окончательно.

Кстати, ещё наблюдение: при каждом factory reset хвост меняется, но он не привязан к конкретному HDD – я копировал хвост на другой винт и даже на SSD, LUN всё равно появляется. То есть устройство опирается на сам факт «правильного хвоста», а не на какие-то уникальные параметры носителя.

 

[Guardian0x00]

Найти в ТГ @Ground_x00