Dzielenie się wiedzą, mnoży ją. Dzisiaj chciałbym w tym duchu podzielić się analizą plików o rozszerzeniu .XPA, zawierających nagrania z monitoringu CCTV. To dość leciwy format firmy Pelco, obecnie będącej częścią Motorola Solutions Company, mimo to nadal czasem przyjdzie się z nim zmierzyć informatykom śledczym.
Pliki te stanowią natywny format eksportu z urządzeń firmy Pelco – Digital Sentry (DS). Producent nie publikuje specyfikacji binarnej formatu .XPA (układu nagłówków, indeksów, tzw. „magic bytes” itp.). Jako środowisko referencyjne do odtwarzania i obsługi eksportów plików, wskazywane są narzędzia DS ControlPoint/DS Media Player. Format ten opisany jest jako „raw video”. Przy czym w dokumentacji Pelco trafia się rozróżnienie wielkości liter (np. „XPA = video for DigitalSentry; xpa = audio for DigitalSentry; XPA = audio for MasterControl; XPV = Video ; XPI = Index), co odzwierciedla różne role plików przy tym samym rozszerzeniu w rodzinach DS i MasterControl.
Teoretycznie .XPA w DS oznacza natywny strumień wideo a .xpa audio. Dokumentacja swoje a praktyka swoje, do badań trafiły nagrania o nazwach: mag dep 22-24.xpa, P-waga widok przod.xpa i podobne, wszystkie mają rozszerzenia zapisane małymi literami – jak to w systemach Windows bywa. Dobra praktyka, dołączanie playera od producenta do zgrywanych nagrań i tym razem okazała się bardzo pomocna. Do plików dołączony został program IMedia.exe (Integral Media Player 6.7.1.90). Wyszukano dodatkowo program na stronach producenta. Pobrano nowszą wersję, plik nazywa się IMedia.exe, natomiast po uruchomieniu prezentowana jest nazwa DS Media Player 7.17.136.11334.
W zakresie weryfikacji integralności i autentyczności pliku producent przewiduje własny mechanizm. Znajduje się on w programie, jest to funkcja „Authentication”. Po jej użyciu oprogramowanie weryfikuje, czy badany materiał jest oryginalny i niezmieniony. W przypadku programu IMedia funkcja „Options” -> „Authenticate Video” wyświetla komunikat o stanie autentyczności. Potwierdzenie wygląda jak na poniższym zrzucie.
Po wczytaniu do oprogramowania IMedia (takie samo zachowanie w obydwu programach) na nagraniu widoczna jest ramka wokół obrazu, w przypadku gdy jest ona koloru niebieskiego czas na nagraniu przeskakuje około 1 sekundę na klatkę, natomiast gdy jest ona koloru zielonego kolejne klatki są zmieniane co około 10 sekund. Zmiana trybu szybkości wyświetlania klatek związana jest z detekcją ruchu. Analiza obiektów na nagraniach oraz sekwencji ramek i zmian czasu wskazał, iż na badanych plikach zapisem steruje detekcja ruchu w trybie buforowanym. Po przekroczeniu zadanego progu system rozpoczyna zapis z krokiem ok. 1 sekundy – te fragmenty są oznaczone ramką w kolorze niebieskim. Gdy ruch ustaje, po krótkim okresie bez jego wykrycia system przełącza się na zapis co ok. 10 sekund, oznaczany ramką w kolorze zielonym. Kolorystyka pozwala odróżnić ciągłe sekwencje zdarzeniowe (niebieskie) od zapisów okresowych w braku ruchu (zielone). Materiał w odtwarzaczu wyświetlany jest poklatkowo, wraz z powyżej opisanymi zmianami szybkości rejestracji powoduje to wrażenie zaburzenia integralności temporalnej (czasowej).
Sygnatura pliku .XPA (magic bytes / file headers) 02 00 00 00 40 00 00 00 1C 00 00 00 B0 01 00 00 \x02\x00\x00\x00\x40\x00\x00\x00\x1C\x00\x00\x00\xB0\x01\x00\x00.
Na podstawie nagłówków 2 plików oraz danych wyświetlanych przez DS Media Player przygotowałem z wykorzystaniem LLM analizę nagłówka – poniżej.
Porządek bajtów (endianness) dla wartości liczbowych: LITTLE-ENDIAN. Offsety podawane są jako heksadecymalne pozycje w pliku.
Łańcuchy tekstowe:
- UTF-16LE – litery przedzielone 0x00 (np. 'P' = 0x50 0x00).
- ASCII – ciąg bez zer między znakami.
Znaczniki czasu: FILETIME (8 bajtów, liczba 100-ns od 1601-01-01 UTC).
Pierwsze 64 bajty mają stałą, spójną strukturę.
1) NAGŁÓWEK PIERWOTNY (0x0000–0x003F; 64 bajty)
-----------------------------------------------
Interpretacja 16 słów 32-bitowych (u32[0..15], little-endian):
Offset Pole Przykład (P-waga / mag dep) Znaczenie
------ ---------- -------------------------------- -----------------------------
0x0000 u32[0] 0x00000002 / 0x00000002 Wersja rekordu/formatu (=2)
0x0004 u32[1] 0x00000040 / 0x00000040 Długość nagłówka (=64 B)
0x0008 u32[2] 0x0000001C / 0x0000001C Flagi/typ (niejawne)
0x000C u32[3] 0x000001B0 / 0x000001B0 Parametr długości/offset wyrównany*
0x0010 u32[4] 0x074AE5F8 / 0x01134506 Licznik/czas producenta (nie epoch)
0x0014 u32[5] 0x00000000 / 0x00000000 Zarezerwowane
0x0018 u32[6] 0x00002BFE / 0x00000712 PRZYBLIŻONA liczba rekordów/klatek**
0x001C u32[7] 0x00000000 / 0x00000000 Zarezerwowane
0x0020 u32[8] 0x00000000 / 0x00000000 Zarezerwowane
0x0024 u32[9] 0x00000000 / 0x00000000 Zarezerwowane
0x0028 u32[10] 0x00000000 / 0x00000000 Zarezerwowane
0x002C u32[11] 0x00000000 / 0x00000000 Zarezerwowane
0x0030 u32[12] 0x00000000 / 0x00000000 Zarezerwowane
0x0034 u32[13] 0x00000000 / 0x00000000 Zarezerwowane
0x0038 u32[14] 0x00000000 / 0x00000000 Zarezerwowane
0x003C u32[15] 0x00000000 / 0x00000000 Zarezerwowane
u32[3] = 0x1B0 (432) koreluje z długością pierwszego bloku metadanych zaczynającego się od 0x0040, odpowiada to parametrowi długość/limit sekcji.
u32[6] odpowiada liczbie klatek raportowanej przez aplikację DS Media Player z różnicą kilku sztuk. Różnica może wynikać z indeksowania i/lub obecności ramek technicznych.
2) BLOK METADANYCH #1 (0x0040 …, typ=0x0003)
--------------------------------------------
Na pozycji 0x0040 występuje nagłówek 16-bitowy:
- 0x0040: u16 typ = 0x0003
- 0x0042: u16 długość = 0x01AC (428 B) → dotyczy treści następującej od 0x0044
Zawartość bloku (od 0x0044, w obrębie 428 bajtów):
- 0x0044: UTF-16LE – nazwa urządzenia/hosta, w badanych plikach: „PC2-00743”
- 0x00C4: ASCII – FQDN rejestratora: „pc2-00743.xxxxxxx.xxx.xxxxxx.xxx.pl” (zamaskowane przeze mnie dla bezpieczeństwa systemu)
3) BLOK METADANYCH #2 (po bloku #1; nazwa kanału + czas startu)
----------------------------------------------------------------
Po zakończeniu bloku #1 (0x0044 + 0x01AC = 0x01F0) pojawia się kolejny segment metadanych, w którym przechowywana jest nazwa kanału (UTF-16LE) oraz bezpośrednio po niej czas startu FILETIME.
Nazwa kanału (UTF-16LE):
- przykładowe `P - waga widok przod` w pliku „P-waga widok przod.xpa” → offset **0x0340**.
- przykładowe `Mag. depozytowy 1` w pliku „mag dep 22-24.xpa” → offset **0x0340**.
Czas rozpoczęcia nagrania (FILETIME, 8 bajtów, LE) – bezpośrednio po nazwie kanału:
- przykładowe „P-waga widok przod.xpa”: offset **0x0368** → bajty: **b0 87 de 9e 24 a5 ca 01**
= 2010-02-03 23:00:03.627 UTC = 2010-02-04 00:00:03.627 CET (klatka 0 w DS)
- przykładowe „mag dep 22-24.xpa”: offset **0x0362** → bajty: **b0 3c 25 dc 13 a5 ca 01**
= 2010-02-03 21:00:04.987 UTC = 2010-02-03 22:00:04.987 CET (klatka 0 w DS)
4) PODSUMOWANIE PÓL KLUCZOWYCH (lokalizacja → znaczenie → format)
------------------------------------------------------------------
0x0000 (u32): Wersja rekordu/formatu (=2) → DWORD LE
0x0004 (u32): Długość nagłówka (=64) → DWORD LE
0x0008 (u32): Flagi/typ (niejawne) → DWORD LE
0x000C (u32): Długość/metadane wyrównane → DWORD LE (wartość 0x1B0 ~ 432 B; por. 0x0042 = 0x01AC)
0x0010 (u32): Licznik/czas producenta → DWORD LE (nie jest to Unix epoch)
0x0018 (u32): Przybl. liczba klatek → DWORD LE (zbieżna z DS ± kilka)
0x0040 (u16): Typ bloku metadanych (=3) → WORD LE
0x0042 (u16): Długość bloku #1 (=0x01AC) → WORD LE
0x0044 (…) : Nazwa hosta (np. „PC2-00743”)→ UTF-16LE, null-terminated
0x00C4 (…) : FQDN rejestratora → ASCII, null-terminated
0x0340 (…) : Nazwa kanału/kamery → UTF-16LE, null-terminated
0x0362/0x0368: Czas startu nagrania → FILETIME (8 B, LE) = UTC; konwersja → CET (+1 h, luty 2010)
Rozmieszczenie obserwowanych pól jest stałe w badanych próbkach; wartości u32[3], u32[4], u32[6] są spójne z zaobserwowaną zawartością i tym, co prezentuje DS Media Player (nazwy, liczby klatek, czas startu).
Struktura całego pliku (po nagłówkach) zawiera dalej zapis ramek obrazu (jako sekwencje JPEG SOI/EOI).Kluczowa w analizie binarnej jest weryfikacja posiadanych danych materiału dowodowego, w tym informacji o nazwie kamery, czasie rozpoczęcia rejestracji i liczbie ramek. Weryfikacja zgodność tych parametrów w połączeniu z informacją z weryfikatora wewnętrznego playera zapewnia wysoki stopień zaufania do oryginalności plików. Nie mylić z pełnym zaufaniem – o to trudno w informatyce śledczej.
Dodatkowo w badanych plikach występują artefakty typowe dla niestabilnego toru wizyjnego oraz późniejszej kompresji w rejestratorze i w trakcie archiwizacji. Uwzględnienie i analiza poszczególnych typów błędów w tym uzasadnienie ich występowania jest istotnym składnikiem procesu analizy autentyczności, ale o tym w innym wpisie.
Warto przy tym zauważyć, iż materiał ma bardzo niską rozdzielczość (352×288 px). Teraz pozostaje Wam sobie wyobrazić jak to wpływa na możliwość oceny czynności wykonywanych przez zarejestrowane na nagraniach osoby oraz ich identyfikację, chociaż akurat tym to martwi się już biegła antropolog – Amanda Krać-Batyra 😉.
Źródła:
Dokumentacja dotycząca formatów.
Strona wsparcia producenta Pelco – tam znajdziecie program do odtwarzania.
Tomasz Sidor
październik, 2025 r.