Aplikacje, artefakty i raportowanie

Aplikacje innych firm w większości przypadków generują najbogatsze źródła dowodów. Każda aplikacja przechowuje dane na swój sposób, ale pewne schematy się powtarzają.

• Bazy danych SQLite przechowujące wiadomości, historię i metadane.
• Listy właściwości (plist) w systemie iOS oraz XML shared_prefs w systemie Android, służące do przechowywania ustawień i stanu.
• Obiekty Protobuf / JSON osadzone w kolumnach baz danych.
• Foldery pamięci podręcznej i multimediów zawierające miniatury i załączniki.

Zadaniem jest konsekwentne parsowanie tych danych, przypisanie ich użytkownikowi i czasowi oraz przedstawienie ich w sposób możliwy do obrony.

Aplikacje do przesyłania wiadomości są częstym źródłem dowodów. Każda z nich przechowuje główny magazyn wiadomości oraz tabele kontaktów i grup.

• WhatsApp (Android): msgstore.db (wiadomości), wa.db (kontakty).
• Signal: baza SQLCipher zaszyfrowana; klucz znajduje się w keystore/keychain.
• Telegram: cache4.db z zawartością zakodowaną w formacie protobuf.

Należy zrekonstruować rozmowę WhatsApp na podstawie magazynu wiadomości:

Niektóre aplikacje szyfrują własne bazy danych za pomocą SQLCipher (np. Signal i niektóre aplikacje bankowe). Nie można ich otworzyć za pomocą zwykłego sqlite3.

• Klucz jest zwykle przechowywany w platformowym keystore/keychain i można go odzyskać tylko na podstawie odpowiednio głębokiej ekstrakcji.
• Po odzyskaniu klucza należy otworzyć bazę za pomocą SQLCipher PRAGMA przed wykonaniem zapytań.

Otwieranie bazy SQLCipher po odzyskaniu klucza:

Bazy danych aplikacji często ukrywają dane strukturalne w kolumnach typu BLOB jako protobuf, plist lub JSON. Widoczne kolumny przedstawiają tylko część informacji.

• Obiekty BPLIST (binarne listy właściwości Apple) można dekodować za pomocą plistlib lub plutil.
• Obiekty Protobuf można dekodować za pomocą protoc lub blackboxprotobuf.

Należy przekonwertować binarny obiekt plist wyodrębniony z kolumny:

Dowody lokalizacji łączą osobę z miejscem i czasem, dlatego należy obchodzić się z nimi ze szczególną starannością.

• Znaczniki GPS EXIF zdjęć, historia wyszukiwania w aplikacji map oraz kafelki w pamięci podręcznej.
• Ważne lokalizacje systemu iOS (pamięć podręczna routined), historia lokalizacji systemu Android oraz logi Wi-Fi i sieci komórkowych.

Należy odróżnić miejsce, w którym znajdowało się urządzenie od miejsca, którego użytkownik jedynie szukał. Należy wyodrębnić dane GPS EXIF ze zdjęcia:

Nowoczesne aplikacje synchronizują dane między urządzeniami, dlatego dane z urządzenia mogą być niekompletne lub zduplikowane.

• Wiadomość usunięta z telefonu może nadal znajdować się na połączonym tablecie lub w sesji internetowej.
• Metadane synchronizacji mogą wskazywać, które urządzenie utworzyło wiadomość.

Podczas analizy należy odnotować przypisanie danych do urządzenia, a po dane z chmury lub urządzenia towarzyszącego sięgać wyłącznie na podstawie odrębnego, właściwego upoważnienia prawnego. Nigdy nie należy zakładać, że zabezpieczony telefon zawiera kompletny zapis.

Zanim artefakt trafi do raportu, należy zweryfikować go na trzy sposoby.

• Źródło: należy potwierdzić dokładny plik/tabelę/kolumnę, z którego pochodzi.
• Dekodowanie: należy sprawdzić epokę znacznika czasu i znaczenie pola, najlepiej w odniesieniu do wiarygodnej wiadomości referencyjnej.
• Potwierdzenie: należy porównać artefakt z drugim artefaktem, np. wpisem w rejestrze połączeń odpowiadającym danemu kontaktowi.

Artefakt, którego nie można niezależnie potwierdzić lub precyzyjnie przypisać do źródła, należy oznaczyć jako niskiej wiarygodności, a nie przedstawiać jako fakt.

Zbiorcza oś czasu łączy zdarzenia z wielu artefaktów w jeden chronologiczny widok, znormalizowany do UTC.

• Należy połączyć wiadomości, połączenia, użycie aplikacji, lokalizacje i zdarzenia systemowe.
• Każdy wiersz należy oznaczyć źródłowym artefaktem, aby zapewnić możliwość prześledzenia pochodzenia danych.

Narzędzia takie jak log2timeline/plaso lub skrypty analityczne tworzą takie zestawienia. W ujęciu koncepcyjnym każdy wiersz zawiera czas, zdarzenie i pochodzenie:

Raport kryminalistyczny musi umożliwiać niezależnemu ekspertowi odtworzenie i zweryfikowanie wykonanych prac. Standardowe sekcje obejmują:

• Podsumowanie — zakres, upoważnienie i najważniejsze ustalenia.
• Przetworzone dowody — urządzenia, identyfikatory i łańcuch dowodowy.
• Metodyka — narzędzia, wersje, dokładne polecenia i hashe.
• Ustalenia — artefakty wraz ze wskazaniem źródeł.
• Wnioski — interpretacja wyraźnie oddzielona od surowych faktów.

Każde twierdzenie powinno dać się prześledzić do źródła z hashem oraz udokumentowanego etapu.

Wiarygodność raportu zależy od oddzielenia obserwacji od interpretacji.

• Fakt: wiersz 482 w sms.db zawiera tekst X z datą Y (UTC).
• Interpretacja: może to sugerować, że użytkownik planował spotkać się w lokalizacji Z.

Fakty należy przedstawiać neutralnie, a wnioski oznaczać jako interpretacje, uwzględniając także alternatywne wyjaśnienia. Nadmierna pewność, np. stwierdzenie zamiaru na podstawie jednej wiadomości, podważa wiarygodność całego raportu i może zostać zakwestionowana w sądzie.

Urządzenia mobilne przechowują bardzo prywatne dane. Osoby zajmujące się ich analizą muszą działać w granicach prawa i etyki.

• Należy działać wyłącznie w ramach zatwierdzonego zakresu (warunków nakazu lub zgody).
• Należy ograniczać dostęp do nieistotnych danych prywatnych.
• Należy zachować obiektywizm — raportować także dowody odciążające, a nie tylko obciążające.
• Wyodrębnione dane należy chronić z taką samą starannością jak oryginalne urządzenie.

Rzetelna etyka nie jest opcjonalna — to ona sprawia, że dowody cyfrowe są wiarygodne i dopuszczalne w postępowaniu sądowym.

Potrafią już Państwo przekształcić surowe ekstrakcje w raport, którego można bronić.

• Dane aplikacji to SQLite + plist/XML + protobuf/JSON blobs; bloby należy jawnie dekodować.
• Zaszyfrowane magazyny (SQLCipher) wymagają kluczy uzyskanych podczas głębokiej ekstrakcji.
• Z dowodami dotyczącymi lokalizacji należy obchodzić się ostrożnie; trzeba odróżniać potwierdzoną obecność od samego wyszukania.
• Należy uwzględniać synchronizację między urządzeniami i pozyskiwać dane z chmury wyłącznie na podstawie odpowiedniego upoważnienia.
• Przed uwzględnieniem informacji w raporcie należy zweryfikować źródło, dekodowanie i potwierdzenie.
• Należy zbudować znormalizowaną do UTC zbiorczą oś czasu, uporządkować raport tak, aby można było odtworzyć analizę, oraz zachować oddzielenie faktów od opinii.
• Należy działać w ramach upoważnionego zakresu i postępować etycznie — to właśnie sprawia, że dowody są dopuszczalne.