„Czy da się odzyskać plik?” brzmi prosto, lecz łączy kilka różnych pytań. Czy zachowały się bajty treści, metadane wpisu, miniatura, wcześniejsza wersja, rekord w bazie, kopia w chmurze, klucz pozwalający odszyfrować nośnik albo jedynie ślad, że obiekt kiedyś istniał? Odpowiedź zależy nie tylko od czasu od usunięcia. Decydują system plików, typ pamięci, aktywność urządzenia, TRIM i garbage collection, szyfrowanie, snapshoty, synchronizacja, retencja dostawcy oraz sposób zabezpieczenia.

Artykuł opisuje warsztat operacyjny: od rozpoznania warstw przez wybór najmniej niszczącej akwizycji po walidację i raport. Nie zawiera metod łamania zabezpieczeń ani obchodzenia kontroli dostępu. Dostęp do kluczy, kont i usług musi mieć podstawę prawną oraz być dokumentowany tak samo jak pozyskanie samych danych.

Najpierw zdefiniuj obiekt odzyskania

Plik widoczny użytkownikowi jest tylko jedną reprezentacją. Może odpowiadać rekordowi katalogu, zestawowi ekstentów, wpisowi w bazie, obiektowi chmurowemu lub pakietowi złożonemu z wielu zasobów. Aplikacja może wyświetlać wiadomość odtworzoną z bazy, załącznika i danych konta, choć żaden z tych elementów nie jest osobnym „plikiem wiadomości”.

Pytanie powinno wskazywać oczekiwany wynik: pełną treść, fragment, nazwę i ścieżkę, czas istnienia, hash znanej kopii, wersję historyczną, relację z kontem albo dowód operacji usunięcia. Każdy wynik ma inny próg i inne źródła. Brak treści nie wyklucza odzyskania metadanych, a odnalezienie fragmentu nie dowodzi, że użytkownik widział kompletny obiekt.

Osiem warstw utraty widoczności

Obiekt może zniknąć z interfejsu aplikacji, indeksu wyszukiwania, bazy aplikacji, katalogu systemu plików, mapy alokacji, logicznej przestrzeni bloków, fizycznych komórek pamięci albo konta chmurowego. Między warstwami działają cache, dzienniki, kopie, synchronizacja i retencja. „Usunięty” na jednej warstwie może nadal być aktywny na innej.

Mapa warstw powinna obejmować urządzenie, wolumen, system plików, profil, aplikację, bazę, usługę i repliki. Dla każdej zapisuje się mechanizm usunięcia, spodziewane artefakty, zegar oraz procesy mogące nadpisać lub wyczyścić dane. Dopiero ta mapa pozwala ustalić kolejność czynności.

Stan urządzenia zmienia strategię

Wyłączony nośnik magnetyczny, uruchomiony laptop z odblokowanym BitLockerem i telefon z aktywną sesją chmurową są trzema różnymi sytuacjami. Wyłączenie może chronić przed nadpisaniem, ale utracić klucze w pamięci i stan odblokowania. Pozostawienie systemu włączonego podtrzymuje dostęp, lecz procesy tła mogą wykonywać TRIM, synchronizować usunięcia i rotować logi.

Decyzję live/dead uzasadnia się bilansem ryzyk, nie przyzwyczajeniem laboratorium. Dokumentuje się ekran, zasilanie, połączenia, stan szyfrowania, zalogowane profile, zamontowane wolumeny, aktywne usługi i możliwe zdalne zarządzanie. Szczegółową procedurę miejsca opisuje Zabezpieczenie urządzenia i stanu dowodowego.

Usunięcie na poziomie aplikacji

Aplikacja może ustawić flagę deleted, przenieść rekord do kosza, ukryć go filtrem, usunąć odwołanie albo wykonać fizyczne porządkowanie bazy później. Mechanizm zależy od wersji. Trzeba zachować pliki bazy, dzienniki WAL lub rollback journal, cache, konfigurację, indeksy, pliki załączników i identyfikatory synchronizacji.

Interpretacja wymaga schematu i testu na porównywalnej wersji. Pusty rekord może oznaczać usunięcie, migrację, niepełną synchronizację lub niezainicjalizowane pole. Narzędzie, które pokazuje rekord jako „deleted”, powinno ujawnić, na jakiej cesze to oparło. Etykieta parsera nie zastępuje walidacji surowych stron i relacji.

Kosz nie jest nieprzydzieloną przestrzenią

Przeniesienie do kosza zwykle zachowuje aktywną treść i dodaje metadane pozwalające odtworzyć pierwotną nazwę, ścieżkę lub czas. Opróżnienie kosza uruchamia kolejny mechanizm systemu plików. Nie należy łączyć obu zdarzeń ani zakładać, że czas pliku w katalogu kosza jest czasem pierwotnego usunięcia.

Kosz może być lokalny dla wolumenu, użytkownika, udziału sieciowego lub aplikacji. W chmurze ma własny okres retencji i reguły administratora. Analiza porównuje artefakty wpisu, log aktywności i stan obiektu, ponieważ interfejs może wyświetlać czas inny niż API lub dziennik audytu.

Co robi system plików

Klasyczne usunięcie najczęściej zwalnia nazwę i rekord alokacji, a dane bloków mogą pozostać do ponownego użycia. Nie jest to jednak uniwersalna obietnica odzysku. System może natychmiast aktualizować metadane, skracać plik, wykonywać copy-on-write, szyfrować każdy ekstent osobnym kluczem lub przekazywać urządzeniu informację o zwolnieniu.

Przed próbą odzysku identyfikuje się system, jego wersję i opcje montowania. Obraz surowy analizowany bez zrozumienia puli, warstwy szyfrowania albo thin provisioning może zawierać przestrzeń, której znaczenie jest inne niż „nieprzydzielona przez użytkownika”.

NTFS: MFT, bitmapa i dzienniki

W NTFS rekord MFT przechowuje atrybuty pliku; mała treść może być rezydentna, większa wskazuje runy danych. Po usunięciu rekord i klastry mogą zostać oznaczone jako wolne, a następnie ponownie wykorzystane niezależnie. Stan numeru sekwencji rekordu pomaga odróżniać kolejne użycia tego samego slotu.

USN Change Journal rejestruje zdarzenia tworzenia, zmiany i usuwania obiektów, ale jest ograniczany rozmiarem i przycinany. $LogFile` służy spójności transakcji NTFS i nie jest pełnym dziennikiem treści użytkownika. MFT, `$Bitmap, USN, log, indeksy katalogowe, VSS, LNK i miniatury należy korelować, a nie traktować jako wymienne kopie.

APFS: copy-on-write, klony i snapshoty

APFS jest projektowany dla flash, używa copy-on-write metadanych, współdzielenia przestrzeni, klonów oraz snapshotów. Zmiana może tworzyć nowe bloki zamiast nadpisania w miejscu, lecz współdzielone ekstenty i alokacja całego kontenera komplikują pojęcie „wolnego miejsca wolumenu”. Snapshot może zachować wcześniejszy stan metadanych i danych mimo braku pliku w bieżącym widoku.

Obecność snapshotu nie gwarantuje retencji konkretnego obiektu; zależy od chwili utworzenia i późniejszego usunięcia snapshotu. Klon nie jest niezależną pełną kopią wszystkich bloków. Analiza powinna zachować strukturę kontenera, role wolumenów, snapshoty, identyfikatory obiektów i wersję APFS oraz odróżnić wolumen systemowy od danych użytkownika.

ext4 i JBD2

ext4 używa inode'ów, extentów i bitmap alokacji. JBD2 chroni spójność transakcji, lecz w domyślnym trybie data=ordered dziennikowane są przede wszystkim metadane; tryby data=journal i data=writeback dają inne zachowanie. Dziennik nie jest zatem automatycznie kopią treści każdego usuniętego pliku.

Opcje montowania, delayed allocation, fast commits i zewnętrzny journal wpływają na dostępne ślady. Montowanie nieczysto odłączonego obrazu może odtworzyć journal i zmienić stan. Kopię bada się w sposób kontrolowany, zachowując stan przed replay; jeśli narzędzie dokonuje odtworzenia logicznego, wynik i zmiany muszą być osobnym produktem.

Inne systemy i urządzenia

ReFS, XFS, Btrfs, ZFS, exFAT, F2FS i systemy mobilne mają różne modele metadanych, snapshotów, sum, copy-on-write oraz discard. Nie wolno przenosić wprost heurystyk NTFS. System może dodatkowo działać na obrazie sparse, wirtualnym dysku, wolumenie logicznym, macierzy lub zasobie sieciowym.

Jeżeli parser nie obsługuje danej wersji, wynik „brak usuniętych” jest nieważny. Należy zachować surowy materiał, sprawdzić sygnatury i cechy superbloku, porównać przynajmniej dwa narzędzia lub wykonać test znanej prawdy. Nieznany stan oznacza ograniczenie, nie zero.

HDD: nadpisanie i remapowanie

Na klasycznym dysku magnetycznym treść zwolnionych sektorów bywa czytelna do nadpisania, ale kontroler może remapować uszkodzone sektory, cache może zmieniać kolejność zapisu, a dyski SMR mają dodatkową translację stref. Widok LBA udostępniany hostowi nie musi odpowiadać pełnemu fizycznemu nośnikowi.

Powodzenie zależy od faktycznego przydziału i aktywności po usunięciu. Popularny mit o laboratoryjnym odczytywaniu wielu dawnych warstw po zwykłym nadpisaniu nie powinien być podstawą opinii. Wniosek opiera się na tym, co zostało odczytane i zwalidowane, nie na spekulacji o niedostępnym stanie fizycznym.

SSD, flash i warstwa translacji

Pamięć flash nie nadpisuje komórki tak jak HDD. Kontroler mapuje logiczne adresy na strony fizyczne, wyrównuje zużycie, scala bloki i wykonuje garbage collection. Nadmiarowa przestrzeń oraz remapowanie są zwykle niewidoczne przez standardowy interfejs. Dwa egzemplarze tego samego modelu mogą różnić się firmware i zachowaniem.

Obraz logicznych LBA nie odsłania automatycznie dawnych stron FTL. Próby ingerencji sprzętowej wymagają specjalistycznej walidacji i mogą nie odtworzyć mapowania lub danych zaszyfrowanych przez kontroler. Raport powinien wyjaśnić, czy badano widok hosta, czy również pamięć fizyczną, i jak odtworzono translację.

TRIM, discard i UNMAP

TRIM lub UNMAP informuje warstwę niższą, że określone bloki logiczne nie są już potrzebne. Microsoft opisuje disabledeletenotify jako sterowanie powiadomieniem o klastrach zwolnionych przez usunięcie; dla NTFS TRIM jest domyślnie włączony, o ile administrator go nie wyłączy. ext4 może wysyłać discard podczas zwalniania albo okresowo.

Powiadomienie nie jest tym samym co natychmiastowe fizyczne wyzerowanie, ale połączenie discard i garbage collection może szybko usunąć treść z widoku. Stan ustawienia systemu nie dowodzi, że komenda dotarła do konkretnego urządzenia ani kiedy kontroler przetworzył bloki. Potrzebne są typ nośnika, stos sterowników, interfejs, logi i test porównawczy.

Garbage collection i czas po usunięciu

Po wydaniu discard kontroler może sprzątać w tle nawet bez nowych plików użytkownika. Dalsze zasilanie urządzenia bywa więc czynnikiem utraty. Z drugiej strony natychmiastowe odłączenie aktywnego, odszyfrowanego systemu może utracić jedyny praktyczny dostęp do danych. Nie istnieje jedna reguła dla wszystkich urządzeń.

Plan dokumentuje przewidywany mechanizm, stan szyfrowania i ryzyko procesów tła. W laboratorium nie uruchamia się systemu źródłowego „żeby sprawdzić kosz”, jeśli można pracować na kopii lub kontrolowanym snapshotcie. Każde dodatkowe zasilenie i montowanie jest rejestrowane.

Nieprzydzielona przestrzeń i slack

Unallocated oznacza bloki niewskazane jako przydzielone przez badaną warstwę systemu plików. Nie przesądza, że zawierają dawny plik ani że są dostępne fizycznie. File slack może obejmować pozostałość w ostatnim przydzielonym klastrze, ale zachowanie zależy od sposobu zapisu, zerowania i narzędzia odczytu.

Fragment znaleziony w slack lub unallocated wymaga atrybucji. Sygnatura i treść mogą wskazywać typ, lecz nazwa, właściciel, czas i pełna długość mogą być nieznane. Położenie w obrazie nie zawsze łączy fragment z konkretnym profilem, zwłaszcza przy współdzielonej przestrzeni i systemach copy-on-write.

File carving

Carving wyszukuje struktury treści bez aktywnego wpisu katalogowego. Najlepiej działa dla formatów z rozpoznawalnym nagłówkiem, stopką i spójną strukturą, gorzej dla fragmentacji, kompresji, szyfrowania i baz danych. Zbieżność sygnatury może dać fałszywy obiekt, a odzysk do pierwszej stopki — obciąć lub połączyć kilka plików.

Walidacja obejmuje parser formatu, rozmiar, wewnętrzne sumy lub indeksy, dekodowanie i porównanie z fragmentami sąsiednimi. Carved file otrzymuje identyfikator położenia i metodę. Nie dziedziczy nazwy ani czasu z luźno sąsiadującego rekordu bez wykazania relacji alokacyjnej.

Dzienniki i ślady pośrednie

Nawet gdy treść zniknęła, mogą pozostać nazwa, hash, identyfikator obiektu, czas, rozmiar, ścieżka, wpis indeksu, miniatura, lista ostatnich plików, log antywirusa, kopia wydruku lub zdarzenie synchronizacji. Takie ślady potwierdzają różne fakty. Miniatura nie dowodzi posiadania oryginału w chwili zabezpieczenia, a wpis ostatniego pliku nie zawsze oznacza jego otwarcie przez człowieka.

Tworzy się tabelę twierdzenie–artefakt–mechanizm–alternatywa. Wniosek o wcześniejszym istnieniu może być mocny mimo braku treści, ale wniosek o zawartości wymaga źródła, które ją zachowało. Hash znanego pliku ma wartość tylko po ustaleniu algorytmu, zakresu hashowania i wiarygodności bazy referencyjnej.

Bazy SQLite, WAL i freelist

SQLite może przechowywać rekordy w stronach aktywnych, freelist, rollback journal i pliku WAL. Checkpoint oraz vacuum zmieniają szanse odzysku. Fragment starego rekordu może przetrwać bez części pól albo z wartościami z innego okresu. Dekodowanie wymaga schematu, typu kodowania, rozmiaru stron i wersji aplikacji.

Nie łączy się rekordów z bazy głównej i WAL wyłącznie po numerze wiersza, jeśli identyfikatory mogły być ponownie użyte. Oś transakcji i numer ramki pomagają ustalić wersję. Eksperyment na kopii aplikacji powinien odtworzyć tworzenie, usunięcie, synchronizację i vacuum, aby sprawdzić zachowanie parsera.

Snapshoty i kopie lokalne

VSS, snapshot APFS, Btrfs/ZFS, backup obrazowy i historia plików mogą zachować różne momenty. Snapshot logicznie utrzymuje stan bloków, ale może współdzielić dane i zostać automatycznie usunięty pod presją miejsca. Backup może wykluczać cache, dane tymczasowe lub klucze.

Inwentaryzuje się snapshoty przed ich zamontowaniem, zachowuje identyfikatory, czas utworzenia i zależności. Odzyskana wersja jest przypisana do konkretnego punktu, nie do „komputera ogólnie”. Porównanie wersji powinno odróżniać zmianę treści, metadanych i samego mechanizmu backupu.

Synchronizacja nie jest kopią zapasową

Usługa synchronizacji może szybko propagować usunięcie na wszystkie urządzenia. Często zachowuje kosz lub wersje, lecz retencja zależy od planu, polityki administratora i typu obiektu. Lokalny placeholder może zawierać tylko metadane, a pełna treść znajdować się u dostawcy lub w cache innego urządzenia.

Mapa synchronizacji obejmuje identyfikator konta i tenant, rooty, selective sync, status pliku, wersje klienta, urządzenia, log audytu i zasady retencji. Nie uruchamia się klienta bez kontroli, ponieważ może pobrać, usunąć albo zaktualizować materiał. Dostęp przez API powinien zachować odpowiedź surową i paginację.

Chmura i retencja dostawcy

Dostawca może posiadać obiekt aktywny, soft-deleted, wersję, kopię odpornościową, log audytu albo tylko metadane rozliczeniowe. Dostępność techniczna nie oznacza, że dane podlegają wydaniu w danym trybie. Żądanie powinno nazywać usługę, konto, tenant, obiekt, zakres czasu, wersje, kosz, logi i format.

Wytyczne SWGDE zalecają ustalenie metody pozyskania, zachowanie lokalnych danych obok chmurowych, żądanie formatu oryginalnego i czytelnego, weryfikację zakresu produkcji oraz hashy lub podpisu dostawcy. Brak rekordu w eksporcie użytkownika nie dowodzi braku w systemie dostawcy; zakres endpointu i retencję trzeba opisać.

Preservation przed pełnym pozyskaniem

Gdy treść może wygasnąć, szybkie zabezpieczenie zachowania danych u dostawcy bywa ważniejsze niż natychmiastowa pełna analiza. Preservation powinno obejmować właściwe konto, usługę, typ danych i czas oraz zostać wysłane do właściwego podmiotu. Nie gwarantuje ono jednak, że dostawca posiadał określoną treść w chwili żądania.

Rejestruje się treść, podstawę, czas wysłania, potwierdzenie, okres obowiązywania i późniejsze przedłużenia. Osobno dokumentuje się produkcję oraz jej kompletność. Preservation nie zastępuje legalnego instrumentu uzyskania danych i nie powinno być przedstawiane jako kopia dowodowa.

Szyfrowanie: trzy osobne pytania

Trzeba ustalić, czy dane są zaszyfrowane w spoczynku, czy wolumen jest obecnie odblokowany i czy istnieje legalnie dostępny materiał kluczowy. Samo oznaczenie „BitLocker” albo „FileVault” nie mówi, czy badany produkt jest ciphertextem, logicznym eksportem z aktywnego systemu czy obrazem odszyfrowanego urządzenia blokowego.

Raport rozdziela metodę ochrony, stan podczas zabezpieczenia i sposób uzyskania plaintextu. Hash ciphertextu i hash obrazu logicznego są różnymi punktami integralności. Odszyfrowanie jest transformacją wymagającą logu, wersji narzędzia, identyfikacji klucza i zachowania wejścia.

BitLocker

BitLocker chroni wolumen i może używać TPM, PIN-u, klucza startowego lub hasła odzyskiwania. Microsoft opisuje odzyskiwanie jako przywrócenie dostępu, gdy zwykły mechanizm odblokowania nie działa; informacje odzyskiwania mogą być przechowywane m.in. w Microsoft Entra ID albo AD DS zależnie od konfiguracji organizacji.

Na aktywnym systemie ustala się stan ochrony, identyfikator wolumenu, protectory i źródło materiału odzyskiwania bez niepotrzebnej zmiany konfiguracji. Nie wyłącza się ochrony ani nie rozpoczyna pełnego deszyfrowania bez uzasadnienia. Logiczną akwizycję z odblokowanego wolumenu zestawia się, gdy możliwe, z zachowanym obrazem warstwy zaszyfrowanej.

FileVault i Apple Data Protection

Na współczesnym Macu FileVault korzysta z hierarchii kluczy powiązanej ze sprzętem i poświadczeniem; Apple silicon oraz układy T2 wykorzystują Secure Enclave. APFS wspiera szyfrowanie wolumenów, a na urządzeniach Apple Data Protection może stosować klucze pliku lub ekstentu i klasy dostępności. Fizyczne wyjęcie pamięci nie daje prostego plaintextu.

Stan zalogowania, typ sprzętu, wersja systemu, FileVault, recovery key i tokeny użytkowników są krytyczne. Apple podaje, że usunięcie niezbędnego materiału kryptograficznego może zapewniać szybkie wymazanie. Odczyt przypadkowych bloków po takim zdarzeniu nie oznacza odzyskania treści, jeśli klucze stały się niedostępne.

LUKS, fscrypt i szyfrowanie aplikacyjne

W Linuxie pełny wolumen może chronić LUKS/dm-crypt, katalog lub pliki — fscrypt, a aplikacja własny kontener. Warstwy mogą się nakładać. Odblokowany mapper urządzenia jest innym źródłem niż zaszyfrowana partycja, a klucz aplikacji może nadal być potrzebny po odszyfrowaniu wolumenu.

Dokumentuje się nagłówek, UUID, sloty kluczy, parametry KDF i stan mappera bez publikowania sekretów w raporcie ogólnym. Kopia nagłówka może być niezbędna dla przyszłej analizy, lecz materiał kluczowy wymaga oddzielnej ochrony i kontroli dostępu.

Android FBE i klucze klas danych

W Androidzie file-based encryption pozwala różnym plikom używać różnych kluczy i rozdzielać dane dostępne przed oraz po odblokowaniu użytkownika. Stan Direct Boot, profil służbowy, Secure Element/TEE i wersja systemu wpływają na dostęp. „Telefon jest włączony” nie oznacza, że wszystkie klasy danych są odszyfrowane.

Reboot może zmienić stan z after-first-unlock na before-first-unlock i utracić praktyczny dostęp do części danych. Z kolei utrzymywanie połączeń zwiększa ryzyko wipe. Strategię ustala wykwalifikowany zespół, uwzględniając narzędzie, model i wersję, a wnioski ogranicza do klas faktycznie pozyskanych.

Klucze i poświadczenia jako osobny materiał

Klucz odzyskiwania, token sesyjny, plik keychain, konfiguracja MDM i koperta klucza są odrębnymi dowodami. Ich pochodzenie, zakres i ważność muszą być znane. Hasło zapisane w notatce może być nieaktualne; token może dawać dostęp tylko do części usługi; klucz może odpowiadać innemu wolumenowi.

Materiał przechowuje się z silniejszą kontrolą niż zwykłe kopie robocze. Raport może wskazywać identyfikator lub źródło bez ujawnienia sekretu. Każde użycie jest logowane, ponieważ może zmienić stan konta, wygenerować alert albo stworzyć nową sesję.

Cryptographic erase i sanitization

NIST SP 800-88 Rev. 2 definiuje sanitization jako uczynienie dostępu do danych niewykonalnym dla założonego poziomu wysiłku i zastąpił w 2025 r. Revision 1. Cryptographic erase niszczy lub zmienia klucz chroniący dane, zamiast nadpisywać każdy blok. Jego skuteczność zależy od poprawnej implementacji i objęcia wszystkich kopii klucza oraz danych.

Z punktu widzenia odzysku mogą pozostać ciphertext, metadane lub repliki, choć treść jest praktycznie niedostępna. Nie utożsamia się komunikatu „reset zakończony” z zwalidowanym purge. Trzeba znać model urządzenia, wersję firmware, komendę, status, zakres i ewentualne obszary nieobjęte.

RAID, pule i thin provisioning

Obraz pojedynczego dysku z macierzy może zawierać fragmenty stripe'ów, parzystość i stare konfiguracje, lecz nie być samodzielnym systemem plików. Kolejność dysków, poziom RAID, rozmiar stripe, offset i historia przebudów są potrzebne do rekonstrukcji. Kontroler może szyfrować, buforować i remapować dane.

W thin provisioning zwolnienie przestrzeni może propagować UNMAP przez kilka warstw: gość, wirtualny dysk, hypervisor, LUN i macierz. Snapshot na jednej warstwie może zachować blok mimo zwolnienia na innej. Inwentaryzuje się cały stos i nie uruchamia automatycznej przebudowy na oryginałach.

Wirtualne dyski i snapshoty maszyn

VHDX, VMDK, QCOW2 i podobne formaty mogą mieć bazę, differencing disks, snapshoty, mapy sparse i wewnętrzne sumy. Usunięty plik w gościu może wystąpić w aktualnym dysku, warstwie rodzica, snapshotcie, backupie hypervisora lub datastore. Sam eksport aktywnej maszyny może spłaszczyć historię.

Zachowuje się deskryptory, łańcuch zależności, identyfikatory, konfigurację VM i czasy hosta. Rekonstrukcję wykonuje się na kopii, sprawdzając zgodność parent UUID i kolejność. Pełną metodykę środowisk zwirtualizowanych powinien prowadzić odrębny moduł, ponieważ odzysk pliku jest tylko jednym z jego pytań.

NAS, udziały sieciowe i urządzenia pośrednie

Plik widziany przez SMB lub NFS może fizycznie znajdować się w macierzy NAS, snapshotcie, puli deduplikowanej albo tierze chmurowym. Stacja robocza zachowuje cache, skróty i poświadczenia, lecz zwykle nie ujawnia pełnego mechanizmu usunięcia po stronie serwera. Kosz sieciowy może działać według polityki udziału, a nie klienta.

Pozyskanie obejmuje konfigurację udziału, mapowanie ścieżek, tożsamość serwera, system plików, snapshoty, logi dostępu, wersję firmware i warstwę RAID. Nie wyłącza się urządzenia wielodyskowego bez planu, jeśli utrata cache lub klucza mogłaby pogorszyć stan. Eksport przez interfejs administracyjny jest produktem logicznym i nie zastępuje automatycznie warstwy blokowej.

Obiekty chmurowe, wersje i delete markers

W object storage klucz obiektu nie jest ścieżką systemu plików, a „usunięcie” może utworzyć delete marker zamiast skasować poprzednią wersję. Retencja, object lock, legal hold, lifecycle rules, replikacja między regionami i klasy archiwalne wpływają na dostęp. Lista bieżących obiektów może ukrywać wersje historyczne.

Żądanie lub eksport powinny obejmować version ID, ETag lub sumę, klasę storage, metadane, znaczniki usunięcia, historię lifecycle i logi API. ETag nie zawsze jest hashem treści, zwłaszcza przy multipart upload i szyfrowaniu. Przywrócenie z archiwum tworzy operację i koszt, które trzeba odróżnić od pierwotnego obiektu.

Kompresja, sparse i deduplikacja

Skompresowany system plików lub format może rozdzielić logiczny plik na jednostki, których nie da się odzyskać przez prostą sygnaturę. Plik sparse zawiera logiczne zakresy zerowe bez odpowiadających im bloków, a deduplikacja pozwala wielu obiektom wskazywać wspólny chunk. Usunięcie jednego odwołania nie musi zwolnić danych, dopóki istnieją inne referencje.

Rekonstrukcja wymaga metadanych mapujących chunki, słownika kompresji i integralności magazynu. Carving po surowych blokach może zwrócić skompresowane segmenty bez pełnego pliku. Wielokrotne referencje do tego samego chunku nie dowodzą, że użytkownik posiadał kilka identycznych kopii; są cechą mechanizmu przechowywania.

Archiwa i zaszyfrowane kontenery

ZIP, 7z, kontener aplikacji lub zaszyfrowany vault może zawierać własny katalog, czasy i sumy. Usunięty plik wewnątrz archiwum jest innym przypadkiem niż usunięcie całego archiwum. Niektóre aktualizacje tworzą nowy kontener, inne modyfikują strukturę; pozostałości mogą wystąpić w pliku tymczasowym albo starej wersji.

Analiza zachowuje kontener jako całość i odnotowuje, czy możliwe było uwierzytelnione odszyfrowanie. Błąd hasła, uszkodzenie nagłówka i nieobsługiwany algorytm nie są tym samym. Odzysk pojedynczego plaintextu z cache aplikacji nie potwierdza, że aktualna wersja zaszyfrowanego kontenera zawierała go w chwili zabezpieczenia.

Tożsamość treści i wersji

Hash identycznych bajtów pozwala wiązać kopie, ale zmiana metadanych osadzonych, kodowania, kompresji albo kontenera daje inny wynik mimo tej samej treści postrzeganej przez człowieka. Perceptual hash może wyszukiwać podobne obrazy lub multimedia, lecz nie jest dowodem identyczności bitowej i ma własne kolizje oraz progi.

Raport rozdziela identyczność bitową, równoważność zdekodowanej treści i podobieństwo. Dla dokumentu można porównać tekst, zasoby i historię rewizji; dla bazy — rekordy oraz transakcje. Nie przypisuje się czasu lub autora jednej wersji innej tylko dlatego, że wyświetlają ten sam obraz.

Priorytetyzacja odzysku

Nie każda przestrzeń wymaga natychmiastowego pełnego carvingu. Priorytet wynika z pytania, ulotności, prawdopodobnych warstw i kosztu utraty. Najpierw zabezpiecza się stan, klucze, wygasającą retencję i unikalne repliki, następnie produkty pozwalające odtwarzać analizę. Triage nie powinien niszczyć możliwości późniejszej pełnej akwizycji.

Plan zapisuje, dlaczego pominięto lub odłożono określone źródło. Wstępny podgląd i indeks służą do decyzji, ale negatywny wynik triage nie zamyka sprawy. Gdy zakres jest selektywny, kryteria wyszukiwania, formaty, okresy i profile muszą zostać zachowane dla kontroli kompletności.

Pamięć RAM i dane ulotne

RAM może zawierać klucze, odszyfrowane fragmenty, otwarte dokumenty, cache aplikacji i mapy zamontowanych zasobów. Akwizycja pamięci zmienia system i wymaga znanego narzędzia, miejsca docelowego oraz logu. Nie gwarantuje znalezienia kompletnego klucza ani możliwości ponownego zamontowania wolumenu.

Wynik pamięci łączy się z procesem, czasem i strukturą właściwą dla wersji systemu. Ciąg bajtów pasujący długością do klucza nie jest nim bez walidacji. Jeżeli dostępny wolumen jest już odblokowany, logiczny lub blokowy produkt z tej warstwy może być bardziej niezawodny niż późniejsza próba ekstrakcji sekretu.

Kolejność akwizycji

Kolejność wynika z ulotności i ryzyka utraty. Może obejmować dokumentację stanu, pamięć i informacje o szyfrowaniu, dane logiczne z odblokowanej warstwy, snapshot, obraz urządzenia, eksport aplikacji i żądanie do chmury. Nie istnieje sztywna lista, ponieważ wykonanie jednego kroku może zmniejszać wartość innego.

Szczegółowe rodzaje produktów, formaty, skróty i walidację opisuje Akwizycja, obraz bitowy i integralność. Tutaj kryterium jest dodatkowe: produkt musi zachować warstwy, na których może przetrwać usunięta lub odszyfrowana reprezentacja.

Master, kopia robocza i eksperyment

Obraz master pozostaje niezmieniony. Montowanie, journal replay, naprawa, deszyfrowanie, carving i rekonstrukcja bazy odbywają się na kopiach lub produktach pochodnych. Każdy ma manifest rodzica, hash, parametry i log. Narzędzie nie może zapisywać odzyskanych plików do badanego wolumenu.

Eksperyment na urządzeniu porównawczym nie jest dowodem, że konkretny egzemplarz zachował się identycznie, ale pozwala sprawdzić mechanizm i parser. Zapisuje się model, firmware, system, ustawienia, sekwencję czynności, czasy i wynik, a różnice wobec dowodu omawia jawnie.

Walidacja narzędzia odzyskującego

Narzędzie testuje się na danych znanej prawdy obejmujących pliki ciągłe i fragmentowane, małe rezydentne, Unicode, sparse, skompresowane, szyfrowane, sklonowane, usunięte przed i po snapshotcie oraz poddane TRIM. Sprawdza się zarówno odzyski prawidłowe, jak i fałszywe dodatnie.

Porównanie dwóch programów nie gwarantuje niezależności, jeśli używają tej samej biblioteki. Wynik krytyczny weryfikuje się w surowych strukturach lub niezależnym parserem. Zachowuje się wersję narzędzia, modułu, sygnatur carvingu i ustawienia, ponieważ aktualizacja może zmienić wynik.

Kompletność i wnioski ujemne

„Nie odnaleziono” jest prawidłowe tylko w granicach zbadanych produktów, metod i klas danych. Nie powinno być zamieniane na „plik nigdy nie istniał” ani „został bezpowrotnie usunięty”, jeśli nie zbadano snapshotów, urządzeń zsynchronizowanych, chmury lub kluczy. Niewspierany system także nie daje wyniku ujemnego.

Raport podaje pokrycie: jakie wolumeny, profile, okresy, snapshoty, bazy, przestrzenie i usługi przeszukano; jakie formaty rozpoznawano; jakie były luki. Dla każdego braku wskazuje, czy jest zgodny z usunięciem, szyfrowaniem, brakiem produkcji, nadpisaniem lub nigdy nieistniejącym obiektem.

Oś życia obiektu

Najlepszy wynik rzadko jest jednym odzyskanym plikiem. Buduje się oś: utworzenie, zapis, synchronizacja, otwarcie, modyfikacja, snapshot, usunięcie aplikacyjne, opróżnienie kosza, zwolnienie bloków, TRIM, usunięcie repliki i odzysk. Każde zdarzenie wskazuje zegar i mechanizm.

Sprzeczne czasy są analizowane, nie uśredniane. mtime, czas wpisu MFT, rekord USN, czas wersji chmurowej i data serwera mogą opisywać inne czynności. Oś oddziela czas zdarzenia od czasu rejestracji i czasu pozyskania.

Atrybucja do użytkownika

Odzyskanie obiektu z profilu nie dowodzi, kto go utworzył, pobrał, widział ani usunął. Potrzebne są sesje, uprawnienia, synchronizacja, źródło, aplikacja i urządzenia współdzielone. Automatyczny cache może powstać bez świadomej czynności, a malware może tworzyć lub usuwać pliki.

Wnioski układa się stopniowo: obiekt był reprezentowany na nośniku; należał do struktury profilu; aplikacja zarejestrowała zdarzenie; konto było aktywne; istnieją ślady interakcji; określona osoba kontrolowała sesję. Każdy poziom ma alternatywy i nie dziedziczy pewności poprzedniego automatycznie.

Raport

Raport opisuje pytanie, stan urządzenia, warstwy, źródła, akwizycje, transformacje i mechanizmy usunięcia lub szyfrowania. Dla odzyskanego obiektu podaje położenie, metodę, stopień kompletności, walidację formatu, hash i relacje z metadanymi. Fragmenty są nazywane fragmentami.

Osobno przedstawia wersje i repliki, klucze lub stan odblokowania, wpływ TRIM/GC, ograniczenia narzędzi i wnioski ujemne. Reprodukcja powinna być możliwa bez ujawniania sekretów w publicznej części opinii. Zrzut ekranu interfejsu jest ilustracją, nie jedynym zapisem wyniku.

Lista kontrolna

  1. Zdefiniuj, czy poszukujesz treści, metadanych, wersji, śladu istnienia czy czynności usunięcia.
  2. Zmapuj urządzenie, wolumen, system plików, aplikację, bazę, konto i repliki.
  3. Udokumentuj stan live/dead, szyfrowanie, sesje, połączenia i możliwe procesy tła.
  4. Ustal typ nośnika, kontroler, firmware, TRIM/discard, thin provisioning i snapshoty.
  5. Zabezpiecz material kluczowy oraz dane ulotne tylko w legalnym, kontrolowanym trybie.
  6. Zachowaj surowe produkty i wykonuj replay, deszyfrowanie oraz odzysk na kopiach.
  7. Zbadaj aktywny widok, kosz, metadane usunięte, unallocated, slack, journal i carving.
  8. Dodaj bazy, WAL, cache, miniatury, indeksy, snapshoty, backupy i historię wersji.
  9. Zabezpiecz retencję chmurową i zweryfikuj zakres produkcji dostawcy.
  10. Waliduj parser i narzędzie na przypadkach znanej prawdy oraz wynikach negatywnych.
  11. Zbuduj oś życia obiektu z rozdzieleniem zegarów i mechanizmów.
  12. Oddziel obecność artefaktu od interakcji, kontroli konta i działania osoby.
  13. Raportuj kompletność, fragmentację, pochodzenie, niepewność i niewspierane warstwy.

Źródła

Granice metody

Nie ma uczciwego uniwersalnego procentu odzysku. Wynik zależy od konkretnego stosu i zdarzeń po usunięciu. Brak danych może być rezultatem skutecznego czyszczenia, utraty klucza, retencji, niepełnej akwizycji albo ograniczenia narzędzia. Obecność bajtów może z kolei nie pozwalać ustalić nazwy, czasu i użytkownika.

Najwyższą wartość ma analiza, która potrafi wskazać warstwę, mechanizm i granicę każdego twierdzenia. „Odzyskano pełną wersję z konkretnego snapshotu” jest mocniejsze i bardziej kontrolowalne niż „program znalazł usunięty plik”, nawet jeśli oba zdania odnoszą się do tej samej treści.