1. Cel pracy Wydzielenie interfejsu programowania aplikacji (API) do interakcji z kontrolerami SSD/NVMe z dostarczonego zestawu narzędzi konsolowych (Phison, Silicon Motion, Realtek, Maxiotek, Marvell, JMicron itd.). Wynikiem ma być działający kod w języku C/C++ lub dokładna dokumentacja struktur do odtworzenia logiki zapytań do dysków.
W rzeczywistości, napisanie podobnych narzędzi było jednym z wariantów mojej możliwej pracy dyplomowej, ale wybrałem prostszy temat, a zainteresowanie pozostało. Niestety, sam nie mam czasu, aby się w tym zorientować, chociaż okresowo wracam do tego tematu, również dlatego, że nie lubię niedokończonych projektów. Teraz mam dość czekania, aż sam się z tym uporam.
2. Obiekt analizy Zestaw plików wykonywalnych (PE, x86/x64) narzędzi rodziny *_flash_id. Programy są ogólnodostępnymi narzędziami diagnostycznymi autorstwa Wadima Oczkina (vlo). Realizują one zapytania do dysków SSD za pośrednictwem standardowych sterowników systemu Windows w celu uzyskania informacji technologicznych (Flash ID, parametry oprogramowania).
3. Wymagania techniczne dotyczące realizacji
- Język programowania: Czysty C / C++ (bez użycia zewnętrznych bibliotek i frameworków). Kod musi być napisany przejrzyście.
- Użycie skryptów PowerShell, platform .NET (C#) lub Pythona i innych do finalnego rozwiązania nie jest mile widziane.
- Analiza inicjalizacji urządzenia: Określić, z jakimi parametrami wywoływana jest funkcja CreateFile (jakie flagi dostępu i nazwy urządzeń są używane, np. \.\PhysicalDriveX, \.\ScsiX:, \.\ChangerX).
- Przechwytywanie i dokumentowanie IOCTL: Znaleźć wszystkie wywołania DeviceIoControl, które są używane do wysyłania poleceń do kontrolera dysku.
- Rekonstrukcja struktur danych:
- Ustalić dokładne wartości dwIoControlCode (np. SMART_RCV_DRIVE_DATA, IOCTL_SCSI_PASS_THROUGH_DIRECT, IOCTL_ATA_PASS_THROUGH lub kody specyficzne dla dostawcy).
- Całkowicie odtworzyć układ bajtów (strukturę) bufora wejściowego (lpInBuffer) dla każdego krytycznego wywołania.
- Odtworzyć układ bufora wyjściowego (lpOutBuffer) dla poprawnej interpretacji odpowiedzi dysku.
- Mechanizm interakcji z urządzeniem: Program powinien bezpośrednio wywoływać funkcje Windows API (CreateFile, DeviceIoControl) przez standardowe struktury systemowe sterowników (IOCTL_SCSI_PASS_THROUGH_DIRECT, IOCTL_ATA_PASS_THROUGH, SMART_RCV_DRIVE_DATA lub kody specyficzne dla dostawcy).
- Wymagania dotyczące funkcjonalności programu i parsowania danych Wykonawca powinien samodzielnie zbadać nie tylko parametry wysyłania poleceń, ale także strukturę odpowiedzi kontrolera. Opracowywane narzędzie powinno wykonywać automatyczne parsowanie otrzymanego surowego bufora pamięci i wyświetlać w konsoli (lub pliku tekstowym) zorganizowane informacje tekstowe:
- Dokładny model / typ testowanego kontrolera SSD.
- Producent i typ zainstalowanej pamięci flash (np. Micron 96L TLC, Samsung MLC, YMTC itd.).
- Wydzielenie poleceń specyficznych dla dostawcy (VSC): Opisać logikę omijania filtrów sterowników Windows (jakie dokładnie niedokumentowane polecenia lub sekwencje sygnałów są wysyłane, aby przełączyć kontroler w tryb wydawania Flash ID).
- Pełny tekstowy ciąg sygnatury pamięci flash (Flash ID w formacie szesnastkowym).
Sposób wizualnego formatu interfejsu, język wyjścia i struktura samego raportu tekstowego pozostają do decyzji Wykonawcy. Priorytetem jest stuprocentowa poprawność wydobycia kluczowych danych.
5. Procedura testowania i kryteria akceptacji pracy Kryteria pomyślnego wykonania zadania:
- Dostarczony kod źródłowy w języku C/C++ kompiluje się bez błędów i krytycznych ostrzeżeń (warnings) standardowymi kompilatorami pod docelową architekturę systemu Windows (MSVC lub MinGW).
- Skompilowany program uruchamia się w systemie Windows, pomyślnie wysyła zapytania do dysku, nie powodując zawieszeń systemu ani krytycznych błędów (BSOD).
- Informacje tekstowe wyświetlane przez program Wykonawcy (model kontrolera, dostawca pamięci, ciąg sygnatury Flash ID itd.), co do treści całkowicie pokrywają się z raportem tekstowym oryginalnego narzędzia Wadima Oczkina dla danego dysku.
Regulamin interakcji i testowania w zależności od dostępności sprzętu
W zależności od dostępności docelowych dysków u Wykonawcy i Zamawiającego, proces opracowywania, walidacji i płatności za każdy konkretny kontroler dzieli się na trzy scenariusze:
- Scenariusz A (Sprzęt jest u Wykonawcy): Wykonawca samodzielnie wykonuje pełny cykl analizy, pisania kodu i jego testowania na swoim fizycznym dysku. Zamawiającemu przekazywane jest zweryfikowane rozwiązanie. Weryfikacja po stronie Zamawiającego ma charakter potwierdzający (w ciągu 1 dnia roboczego), po czym etap jest opłacany w wysokości 100%.
- Scenariusz B (Sprzęt jest tylko u Zamawiającego): Wykonawca odtwarza logikę narzędzia metodą analizy statycznej i przekazuje kod źródłowy Zamawiającemu. Zamawiający kompiluje kod i testuje narzędzie na swoim fizycznym stanowisku.
- Termin testowania i przesyłania feedbacku przez Zamawiającego — do [na przykład: 2] dni roboczych.
- W przypadku wystąpienia błędów Wykonawca je usuwa na podstawie dostarczonych logów tekstowych.
- Płatność w wysokości 100% następuje po potwierdzeniu poprawnego parsowania danych na sprzęcie Zamawiającego.
- Scenariusz C (Sprzęt nie jest dostępny po obu stronach — „Ślepy rewers”): Wykonawca odtwarza algorytmy wysyłania poleceń i struktury parsowania odpowiedzi wyłącznie na podstawie analizy kodu binarnego oryginalnego programu w dekompilatorze.
- Kryterium wykonania zadania jest logiczna kompletność kodu i brak błędów przy jego kompilacji kompilatorami MSVC lub MinGW.
- Zamawiający wypłaca [na przykład: 60%] wartości tego etapu od razu po pomyślnej weryfikacji kompilacji dostarczonego kodu C.
- Reszta kwoty w wysokości [na przykład: 40%] jest rezerwowana i wypłacana Wykonawcy jako bonus po tym, jak Zamawiający fizycznie zakupi dany dysk i potwierdzi działanie narzędzia w praktyce.
- Gwarancje Wykonawcy dotyczące usuwania ukrytych błędów dla tego kontrolera aktywują się w momencie podłączenia przez Zamawiającego rzeczywistego fizycznego urządzenia.
