[Перевод] Хакинг прошивок жёстких дисков

• Samsung HM020GI
  
• Hitachi HTS545032B9A300
  
• Western Digital WD3200BEVT
  
• Samsung PM871a

• Получить дамп прошивки, или найдя образ прошивки онлайн, или сдампив её самостоятельно.
  
• Загрузить прошивку в IDA для анализа; этот этап также может включать в себя обход сжатия или шифрования. Если я не смогу проанализировать прошивку, то практически никак не смогу и вносить изменения в неё.
  
• Найти способ записи модифицированной прошивки обратно в диск. Это будет или ручное программирование флэш-чипа на плате логики HDD, или применение стандартных/бэкдор-команд. Невозможность записи модифицированной прошивки мгновенно ставит крест на дальнейшей работе с диском.
  
• Проанализировать прошивку и попытаться найти код, отвечающий за обработку запросов чтения. Меня интересовала команда DMA READ EXT, которую консоль использует для запросов чтения. Скорее всего, где-то в прошивке есть таблица функций-обработчиков команд, применяемая для обработки различных команд ATA, поддерживаемых диском. Нахождение этой команды или приведёт меня прямиком к обработчику команды DMA READ EXT, или станет отправной точкой для трассирования и обнаружения её. Наверно, это будет самой сложной частью процесса.
  
• Написать патчи, добавляющие задержку в несколько сотен миллисекунд при чтении с диска конкретного сектора.
  
• Записать модифицированное ПО обратно на диск.

• Расшифровывает/деобфусцирует прошивку, если она защищена.
  
• Записывает её на HDD.

void DecodeFirmware(unsigned char* pBuffer, unsigned int Length)
{
    // Циклический обход всего буфера прошивки.
    for (unsigned int i = 0; i < Length; i++)
    {
        // Получение старшего ниббла текущего байта.
        unsigned char nibbleHi = (pBuffer >> 4) & 0xF;
        // Выполнять модификацию бит?
        if ((nibbleHi & 1) != 0)
            nibbleHi >>= 1;
        else
            nibbleHi = 0xF - (nibbleHi >> 1);
        // Маска в новом значение старшего ниббла.
        pBuffer = (pBuffer & 0xF) | (nibbleHi << 4);
    }
}

Конкретно эту утилиту обновления прошивок можно использовать в более чем двух десятках разных моделей SSD Samsung (а также в нескольких десятках различных моделей DVD), поэтому извлечение информации из этих утилит крайне полезно для дальнейшего масштабирования исследований. Затем я открыл деобфусцированный образ прошивки в шестнадцатеричном редакторе, чтобы разобраться, с чем я имею дело. Первым делом я заметил какие-то подозрительные данные в первых нескольких килобайтах файла, которые походили на криптографическую подпись (а это означало, что у меня, возможно, не получится изменять прошивку). Однако, сравнив два файла прошивок, я понял, что за исключением небольших изменений в данных/коде, единственной заметной разницей были какие-то 28 байт в самом начале файла:

Comparing of the two firmware files
Хоть из этого и нельзя сделать окончательные выводы, это хороший показатель того, что файл прошивки, скорее всего, не подписан каким-то сильным криптоалгоритмом с публичным ключом наподобие RSA или ECDSA. Стоит также отметить, что два файла прошивки имеют одну версию, но для разных форм-факторов Samsung PM871a: один для 2,5-дюймовой модели SATA, другой для модели M.2. То есть, несмотря на небольшие отличия в них, всё равно есть вероятность, что они подписаны. 28 байт — странная длина для хэша или подписи, это может быть SHA-224 или обрезанный SHA-256, но с этим мы разберёмся потом.
Следующим этапом будет определение местоположения заголовков разделов (если они вообще есть). Загрузив файл в IDA в виде двоичного, я сразу увидел, что он разбит на разделы с разными базовыми адресами; значит, чтобы всё загрузилось правильно, нам нужны заголовки разделов. Похоже, первые 8 килобайт файла — это какие-то блоки метаданных, после которых мы видим следующее:

Выделенные красным байты — это почти наверняка адреса памяти сегментов кода/данных. Откуда я это знаю? Потому что смотрел в шестнадцатеричные редакторы бездну уже больше двадцати лет, и невероятно хорошо справляюсь с разбором форматов двоичных файлов. Кроме того, эти адреса достаточно точно соответствуют распределению памяти ядер ARM Cortex-M3:

Вглядываясь в бездну ещё несколько минут, я смог разобраться, что смещение и размер каждого раздела располагаются интервалами блоков по 16 КБ, а после написания ещё одного скрипта загрузчика IDA прошивка полностью загрузилась и была готова к анализу.
Samsung HM020GI
Последним остался Samsung HM020GI. Изучая дамп прошивки этого накопителя в шестнадцатеричном редакторе, я чётко видел незашифрованные строки и то, что походило на машинный код. Однако, несмотря на все мои попытки, мне не удалось найти архитектуры, для которой мог бы дизассемблироваться этот код. Выделялось в этом файле то, что во всём нём порядок слов как будто был изменён:

Это начинало походить на крайне эзотерическую архитектуру набора команд или даже специализированный байт-код, который выполняется через встроенную в микроконтроллер виртуальную машину. Я решил пока отложить этот HDD, но мы вернёмся к нему во второй части!
Запись модифицированной прошивки
Ниже я буду рассказывать о своей работе только с жёстким диском Western Digital, потому что на него я потратил больше всего времени. К тому же читателям будет не очень интересно, если я просто буду повторять одни и те же шаги для каждого диска, с которым работал. Другие накопители вернутся во второй части, где я опишу уникальное исследование, которое провёл для одного из них.
Существует три основных способа записи новой прошивки в накопитель:

• При помощи команды ATA DOWNLOAD MICROCODE. Это самый распространённый способ, поддерживаемый большинством (или даже всеми?) накопителями.
  
• Через бэкдор-команды производителя, обычно используемые для ремонта/диагностики или в накопителях, где в качестве средств патчинга/обновления прошивок в основном применяются оверлеи служебной области.
  
• Через последовательный интерфейс на печатной плате накопителя, обычно предназначенный для ремонта/диагностики.

• Для отправки команд ATA и наблюдения за срабатыванием контрольных точек HDD должен быть подключён PC. К сожалению, у меня нет USB-адаптера, поддерживающего передачу ATA, поэтому диск придётся подключать к PC напрямую через SATA.
  
• Если диск не отвечает в течение определённого интервала таймаута, то Windows подумает, что он умер, и все последующие коммуникации не будут выполняться до перезапуска Windows. В некоторых версиях Windows из-за этого возникать «синий экран смерти», вызванный volmgr.
  
• При отладке HDD проявляет свой норов и иногда нужно переводить его в состояние, требующее отключения-включения питания для правильной работы.

bool SendVSCAccessKey(HANDLE hDrive, BYTE bVscCmd, bool bWriteAccess, DWORD dwAddress = 0, DWORD dwSize = 0)
{
    DWORD BytesRead = 0;
    DWORD BufferSize = sizeof(ATA_PASS_THROUGH_EX) + 512;
    BYTE abPassthroughData[sizeof(ATA_PASS_THROUGH_EX) + 512] = { 0 };
    ATA_PASS_THROUGH_EX* pAtaPassthrough = (ATA_PASS_THROUGH_EX*)abPassthroughData;
    VSC_COMMAND_DATA* pVscCommand = (VSC_COMMAND_DATA*)(pAtaPassthrough + 1);
    // Подготовка данных передачи:
    pAtaPassthrough->Length = sizeof(ATA_PASS_THROUGH_EX);
    pAtaPassthrough->AtaFlags = ATA_FLAGS_DATA_OUT;
    pAtaPassthrough->TimeOutValue = 5;
    pAtaPassthrough->DataTransferLength = 512;
    pAtaPassthrough->DataBufferOffset = sizeof(ATA_PASS_THROUGH_EX);
    // Подготовка регистров порта для команды SMART READ LOG:
    IDEREGS* pRegs = (IDEREGS*)pAtaPassthrough->CurrentTaskFile;
    pRegs->bCommandReg = ATA_OP_SMART;
    pRegs->bFeaturesReg = SMART_WRITE_LOG;
    pRegs->bSectorCountReg = 1;
    pRegs->bSectorNumberReg = 0xBE;     // Специальный log address WD
    pRegs->bCylLowReg = 0x4F;
    pRegs->bCylHighReg = 0xC2;
    pRegs->bDriveHeadReg = 0xA0;
    // Подготовка данных команды VSC:
    pVscCommand->CommandId = bVscCmd;
    pVscCommand->Mode = bWriteAccess == true ? VSC_MODE_WRITE : VSC_MODE_READ;
    pVscCommand->ReadWriteRam.Address = dwAddress;
    pVscCommand->ReadWriteRam.Length = dwSize;
    // Отправка команды в накопитель.
    if (DeviceIoControl(hDrive, IOCTL_ATA_PASS_THROUGH, pAtaPassthrough, BufferSize,
        pAtaPassthrough, BufferSize, &BytesRead, nullptr) == FALSE)
    {
        wprintf(L"SendVSCAccessKey failed 0x%08x\n", GetLastError());
        return false;
    }
    // Проверка на ошибки.
    OUT_REGS* pOutRegs = (OUT_REGS*)pAtaPassthrough->CurrentTaskFile;
    if ((pOutRegs->bStatusReg & 1) != 0)
    {
        wprintf(L"SendVSCAccessKey failed drive returned 0x%04x\n", WD_ERROR_CODE(pOutRegs));
        return false;
    }
    return true;
}

.syntax unified
# Связанные с таймингами переменные для управления задержкой:
.set F_CPU,                 10000000        # частота CPU
.set MS_DELAY,              200             # задержка в 200 мс
# ============================================================================
# Наш код
# ============================================================================
    .long 0xFFEAB600
    .long (9f - 0f)
0:
        # Вызов нашего перехватчика.
        push    {r0-r7, lr}
        blx     Hook_SataDmaRead
        pop     {r0-r7, lr}
        # Замена команд, которые мы переписали.
        movs    r7, r0
        lsls    r0, r0, #4
        adds    r5, r0, r1
        ldrb    r1, [r5, #0xD]
        sub     sp, sp, #0x1C
        str     r1, [sp, #0xC]
        ldrb    r0, [r5, #0xE]
        # Перескакиваем назад.
        ldr     lr, =0x0001672E+1
        bx      lr
    Hook_SataDmaRead:
        # Подготовка счётчика задержки.
        ldr     r3, =(MS_DELAY * F_CPU / 1000)
    Hook_SataDmaRead_loop:
        # Продложаем, пока счётчик не будет равен 0.
        sub     r3, r3, #1
        bne     Hook_SataDmaRead_loop
        bx      lr
        .pool
9:
# ============================================================================
# Перехват обработчика запросов DMA SATA
# ============================================================================
    .long 0x00016720
    .long (9f - 0f)
0:
        .thumb_func
        ldr     r7, =0xFFEAB600
        bx      r7
        .pool
9:
.long 0xFFFFFFFF

• Десятикратное выполнение цикла и чтение определённого сектора, вычисление среднего времени чтения на основании времени каждой итерации.
  
• Запись моих патчей в ОЗУ, добавив таким образом задержку примерно в 200 мс для каждой операции чтения.
  
• Повторение шага 1 и вычисление нового среднего времени.

• У меня есть полностью немодифицированный HDD, на который я подам внешнее питание и выполню предварительный патчинг кода в ОЗУ своим патчем чтения с задержкой. Это упростит тестирование: мне пока не придётся беспокоиться о записи моих патчей в прошивку диска/модули оверлеев.
  
• HDD будет подключен к Xbox 360 через SATA (только кабелем для передачи данных). При запуске консоли я попробую считать с HDD определённый сектор. Пока это происходит, на фоне будет выполняться «хакинг» (о нём я расскажу в следующем посте).
  
• Если операция чтения будет выполняться достаточно долго, то должен сработать мой эксплойт, а код оболочки должен зажечь всё кольцо индикаторов консоли оранжевым цветом, чтобы показать, что всё сработало.