Dwie godziny różnicy: jak badać chronologię wiadomości

Założenia przykładu

To fikcyjny scenariusz dydaktyczny, a nie opis zlecenia ani wyniku pracy dla klienta. Zrzut ekranu pokazuje godzinę 14:10, a rekord z aplikacji — 12:10. Nie znamy jeszcze sposobu zapisu czasu, konfiguracji urządzenia ani ustawień eksportu. Sama różnica nie uzasadnia wniosku o manipulacji.

Plan weryfikacji

Najpierw należy ustalić pochodzenie obu zapisów i zabezpieczyć dostępny materiał wraz z dokumentacją czynności. Następnie sprawdza się, czy pole oznacza wysłanie, odbiór, synchronizację czy modyfikację. Kolejnym krokiem jest sprawdzenie jednostki, strefy czasowej i reguł konwersji. Dla daty, w której w Polsce obowiązuje UTC+02:00, godzina 12:10 UTC odpowiada 14:10 czasu lokalnego. To hipoteza do sprawdzenia, nie domyślne wyjaśnienie każdego przypadku.

Wniosek powinien mieć granice

Jeżeli format pola i ustawienia eksportu potwierdzają tę konwersję, różnicę może wyjaśniać prezentacja tego samego czasu. Nie wynika z tego automatycznie autentyczność całej rozmowy ani autorstwo wiadomości. Pomocne są inne zachowane ślady i porównanie dostępnych źródeł. Gdy pozostaje tylko zrzut ekranu, zakres weryfikacji może być znacznie węższy. W raporcie należy opisać, czego nie można było sprawdzić.

Powiązanie z metodyką

NIST SP 800-101 Rev. 1 omawia etapy zabezpieczania, pozyskiwania, analizy i raportowania danych mobilnych. To publikacja z 2014 r., a nie bieżąca lista możliwości narzędzi ani gwarancja dostępu do współczesnego telefonu.

Hipotezy należy zapisać przed wyborem wyjaśnienia

W przykładzie różnicy dwóch godzin można rozważyć odmienne strefy prezentacji, ustawienie zegara, inny typ zdarzenia lub błędne odczytanie pola. To hipotezy robocze, a nie rozpoznanie przyczyny. Proponowana procedura polega na porównaniu oryginalnych wartości i znaczenia pól oraz na sprawdzeniu ustawień eksportu. Dopiero później należy dokonywać przeliczeń.

Nie wystarcza dopasować jedną datę przez dodanie dwóch godzin. Regułę trzeba sprawdzić na innych rekordach, szczególnie jeśli badany okres obejmuje zmianę czasu. Jeśli korekta działa tylko dla wybranego zdarzenia, może być pozornym dopasowaniem. W opinii należy pokazać zakres, w którym reguła została sprawdzona.

Tabela robocza chronologii

Dla każdego istotnego zapisu warto zachować identyfikator, źródło, oryginalny czas, nazwę pola, zastosowaną regułę i wynik normalizacji. Odrębna kolumna powinna wskazywać, czy chodzi o wysłanie, odebranie, zapis na urządzeniu czy eksport. Tak przygotowane zestawienie ułatwia kontrolę przez osobę, która nie korzysta z tego samego programu.

Załóżmy edukacyjnie, że raport pokazuje 10:15, a zrzut ekranu 12:15. Jeśli ustalono, że pierwsza wartość jest w UTC, a druga odpowiada UTC+02:00 w analizowanym dniu, oba zapisy mogą odnosić się do tego samego momentu. Bez ustalenia tych warunków różnica pozostaje niewyjaśniona. Sam zrzut ekranu nie ujawnia wszystkich danych potrzebnych do takiego porównania.

Jak przedstawić niepewność i zakres ustalenia?

Odpowiedź może brzmieć: „po uwzględnieniu udokumentowanej strefy oba zapisy odpowiadają temu samemu momentowi”, ale nie powinna automatycznie rozszerzać się na tożsamość autora lub prawdziwość treści wiadomości. Są to odrębne zagadnienia. W razie braku informacji o zegarze można wskazać jedynie kolejność w obrębie danego źródła albo zakres możliwych interpretacji.

Ten przykład pokazuje sposób rozumowania, nie wynik rzeczywistej ekspertyzy. Metodykę dokumentowania pozyskania i raportowania omawia NIST SP 800-101 Rev. 1, rozdz. 5–7. [1] Dodatkowym kontekstem jest materiał o bazie komunikatora i pliku WAL.