1. Цель работы Выделение программного интерфейса (API) взаимодействия с контроллерами SSD/NVMe из предоставленного набора консольных утилит (Phison, Silicon Motion, Realtek, Maxiotek, Marvell, JMicron и др.). Результатом должно стать рабочий код на языке C/C++ или точная документация структур для воспроизведения логики опроса накопителей.
На самом деле, написание аналогичных утилит было одним из вариантов моей возможной дипломной работы, но я выбрал более простую тему, а интерес остался. К сожалению, у меня самого не хватает времени разобраться, хотя я периодически возвращаюсь к этой теме, в том числе и потому, что не люблю незавершенные проекты. Сейчас мне надоело ждать, пока сам разберусь.
2. Объект анализа Набор исполняемых файлов (PE, x86/x64) утилит семейства *_flash_id. Программы являются свободно распространяемыми диагностическими утилитами автора Вадима Очкина (vlo). Они осуществляют опрос SSD-накопителей через стандартные драйверы ОС Windows для получения технологической информации (Flash ID, параметры прошивки).
3. Технические требования к реализации
- Язык программирования: Чистый C / C++ (без использования сторонних библиотек и фреймворков). Код должен быть написан прозрачно.
- Использование скриптов PowerShell, платформ .NET (C#) или Python и другие для финального решения не приветствуются.
- Анализ инициализации устройства: Определить, с какими параметрами вызывается функция CreateFile (какие флаги доступа и имена устройств используются, например \.\PhysicalDriveX, \.\ScsiX:, \.\ChangerX).
- Перехват и документирование IOCTL: Найти все вызовы DeviceIoControl, которые используются для отправки команд контроллеру диска.
- Реконструкция структур данных:
- Зафиксировать точные значения dwIoControlCode (например, SMART_RCV_DRIVE_DATA, IOCTL_SCSI_PASS_THROUGH_DIRECT, IOCTL_ATA_PASS_THROUGH или вендор-специфические коды).
- Полностью восстановить разметку байтов (структуру) входного буфера (lpInBuffer) для каждого критического вызова.
- Восстановить разметку выходного буфера (lpOutBuffer) для корректной интерпретации ответа накопителя.
- Механизм взаимодействия с оборудованием: Программа должна напрямую вызывать функции Windows API (CreateFile, DeviceIoControl) через стандартные системные структуры драйверов (IOCTL_SCSI_PASS_THROUGH_DIRECT, IOCTL_ATA_PASS_THROUGH, SMART_RCV_DRIVE_DATA или вендор-специфические коды).
- Требования к функционалу программы и парсингу данных Исполнитель должен самостоятельно исследовать не только параметры отправки команд, но и структуру ответа контроллера. Разрабатываемая утилита должна выполнять автоматический парсинг полученного сырого буфера памяти и выводить в консоль (или текстовый файл) структурированную текстовую информацию:
- Точная модель / тип тестируемого контроллера SSD.
- Производитель и тип установленной флеш-памяти (например: Micron 96L TLC, Samsung MLC, YMTC и т.д.).
- Выделение Vendor Specific Commands (VSC): Описать логику обхода фильтров драйверов Windows (какие именно недокументированные команды или последовательности сигналов отправляются для перевода контроллера в режим выдачи Flash ID).
- Полная текстовая строка сигнатуры флеш-памяти (Flash ID в шестнадцатеричном виде).
Способ визуального оформления интерфейса, язык вывода и структура самого текстового отчета остаются на усмотрение Исполнителя. В приоритете — стопроцентная корректность извлечения ключевых данных.
5. Порядок тестирования и критерии приемки работы Критерии успешного выполнения задания:
- Предоставленный исходный код на языке C/C++ компилируется без ошибок и критических предупреждений (warnings) стандартными компиляторами под целевую архитектуру ОС Windows (MSVC или MinGW).
- Скомпилированная программа запускается в ОС Windows, успешно отправляет запросы к накопителю, не вызывает зависаний системы или критических ошибок (BSOD).
- Текстовая информация, выводимая программой Исполнителя (модель контроллера, вендор памяти, строка сигнатуры Flash ID и другое), по содержанию полностью совпадает с текстовым отчетом оригинальной утилиты Вадима Очкина для данного накопителя.
Регламент взаимодействия и тестирования в зависимости от наличия оборудования
В зависимости от наличия целевых накопителей у Исполнителя и Заказчика, процесс разработки, валидации и оплаты каждого конкретного контроллера делится на три сценария:
- Сценарий А (Оборудование есть у Исполнителя): Исполнитель самостоятельно выполняет полный цикл анализа, написания кода и его натурного тестирования на своем физическом накопителе. Заказчику передается проверенное решение. Проверка на стороне Заказчика носит подтверждающий характер (в течение 1 рабочего дня), после чего этап оплачивается в размере 100%.
- Сценарий Б (Оборудование есть только у Заказчика): Исполнитель восстанавливает логику утилиты методом статического анализа и передает исходный код Заказчику. Заказчик компилирует код и тестирует утилиту на своем физическом стенде.
- Срок тестирования и отправки фидбека Заказчиком — до [например: 2] рабочих дней.
- При возникновении ошибок Исполнитель устраняет их по предоставленным текстовым логам.
- Оплата в размере 100% осуществляется после подтверждения корректного парсинга данных на оборудовании Заказчика.
- Сценарий В (Оборудование отсутствует у обеих сторон — «Слепой реверс»): Исполнитель восстанавливает алгоритмы отправки команд и структуры парсинга ответов исключительно на основе анализа бинарного кода оригинальной программы в декомпиляторе.
- Критерием выполнения задания является логическая полнота кода и отсутствие ошибок при его компиляции компиляторами MSVC или MinGW.
- Заказчик выплачивает [например: 60%] от стоимости данного этапа сразу после успешной проверки компиляции предоставленного C-кода.
- Остальная сумма в размере [например: 40%] резервируется и выплачивается Исполнителю как бонус после того, как Заказчик физически приобретет данный накопитель и подтвердит работоспособность утилиты на практике.
- Гарантийные обязательства Исполнителя по исправлению скрытых багов для этого контроллера активируются в момент подключения Заказчиком реального физического устройства.
