Záchrana smazných dat z RAID0 v notebooku

Smazaná dat v notebooku a RAIDem 0

Firemní notebook Dell Vostro 5502 (Intel Core i5-1135G7, chipset HM470) využíval dva OEM SSD Samsung PM991 512 GB připojené přes Intel RST do softwarového RAID 0. Systém Windows 10 Pro byl plně šifrován BitLockerem s klíčem uloženým v TPM 2.0; v UEFI byly aktivní Secure Boot, Boot Guard a UEFI Boot Path Security. Na konci běžné směny zaměstnanec bez oprávnění vymazal data (Shift+Delete bez použití koše). Nepoužil žádný nástroj na bezpečný přepis smazaných souborů. Notebook pak zůstal další tři dny v provozu - proběhly aktualizace Office, indexace MS Search a běžná uživatelská činnost. Poté firemní IT oddělení zjistilo ztrátu souborů a pokusilo se o samostanou logickou obnovu nástroji na záchranu dat LIve CD Linux; ty však neviděly nejen původní soubory ale ani interní SSD. Následně byl stroj vypnut a doručen k diagnostice.

Přijaté zařízení a diagnostika

Notebook jsme otevřeli v ESD prostředí a vzhledem k uživatelsky vlídnému chování firmy Dell jsme měli  okamžitý přístup  k M.2 slotům.  Další postup byl následující, i když ne zcela rutinní. Bylo třeba:

1. Prvním zjištěním bylo že jsou osazený oba sloty M2. Po konzultaci se zákazníkem a podporou Dell jsme zjistili, že je zařízení dodáno v konfiguraci RAID 0 2x 515GB (zjistit konfiguraci bychom mohli sami, ale ideální je mít maximum vstupních informací). To není ideální. Čeká nás tedy, vzhledem k okolnostem velmi obtížná záchrana dat na RAID poli.
2. Vyjmout oba disky a přečíst je individuálně v režimu NVMe Passthrough, aby nedošlo k dalším zápisům.
3. Zaznamenat metadata Intel RST (Offset 0x0B s DTL - Disk Topology Layout) potvrzující stripe 128 kB a sekvenci disků (Disk 0 = PM991-A, Disk 1 = PM991-B).
4. Vytvořit bitové obrazy obou SSD pomocí PC-3000  (NVMe HW-imager) s parametrem Disable TLER a Ignore CRC pro stabilní čtení při opotřebení bloků. Odezva byla bez chyb; SMART hlásil pouze 6 procent opotřebení NAND.

Kontrola hexadecimálních dumpů potvrdila, že TRIM příkazy byly provedeny téměř okamžitě po mazání - typické pro Windows 10 na NVMe. Trimované oblasti nesly vzorek 00 00 00 00 v souvislých rozsazích. To indikovalo, že FTL mapování uvolnilo logické LBAs a FW řadiče je následně "přemapoval" na volné bloky.

Vlastní práce na záchraně - postup  

Rekonstrukce RAIDu

• Pomocí modulu Data Extractor RAID Edition jsme vytvořili virtuální pole se základním nastavením: velikost stripe 128 kB, disk-order [0, 1], start offset 0 B.
• Kontrolním čtením jsme identifikovali BitLocker podpis FVE-FS na sektoru 0x4000 (ale až po de-stripingu).

Dekryptování svazku

Zákazník naštěstí uložil BitLocker Recovery Key v Azure AD. Po importu klíče a zadání správného GUID jsme disk dešifrovali v read-only módu. Souborový systém NTFS byl konzistentní; MFT ukazoval 18 247 záznamů s atributem 'file_deleted'.

Snaha o obnovení souborů které jsou smazané

Algoritmy NTFS Undelete (R-Studio Technician, UFS Explorer Professional) procházely MFT a vyhledávaly nezačleněné Clusters Runs. Výsledek:

Analýza volných clusterů ukázala > 92 % lokalit vyplněno nulami. Třídenní provoz znamenal cca 47 GiB nového zápisu, který ve stripe 0/1 způsobil plošné přepisování - na SSD disku Samsung PM991 funkce garbage-collection migruje data poměrně agresivně, takže reálné přepsání dat po logickém výmazu proběhne i na fyzických NAND blocích.

Forenzní carve & Pattern Search - poslední možnost

Na virtualizované diskové pole jsme následně spustili utilitu Photorec 7.2 custom build s NVMe no-trim heuristikou (Photorec obecně vykazuje podle našich zkušeností vynikajících výsledků v případech, kdy není možné  zachránit data nealokovaná v souborovém systému)  a kontrolní regex look-ahead na uživatelem specifikované firemní šablony. Intenzivní "carving" přinesl několik fragmentů XML z DOCX, bohužel nečitelných. Bez zachování fragmentační logiky NTFS RAID0 nelze tyto fragmenty složit.

Výsledek a doporučení

Hlavní příčina neúspěchu: kombinace TRIM, FTL wear-levelingu NVMe SSD a třídenního provozu vedla k fyzickému přepisu bloků dříve, než se k nám notebook dostal. V RAID 0 navíc v tomto konkrétním případě každý 128 kB stripe zapisuje střídavě na oba disky, takže i krátké zápisy operačního systému přepisují logicky souvislé soubory ve dvou fyzických zařízeních najednou. V tomto případě byla záchrana dat na notebooku i přes velké množství odvedené práce neúspěšná. Zákazník se tedy musel smířit s tím, že o data definitivně přišel. My jsme z důvodu neúspěchu práci na záchraně dat neúčtovali. 

Doporučení vycházející z tohoto "nevyřešeného" případu

1. Okamžitě vypnout zařízení (!) po zjištění smazání dat, která jsou vymazaná omylem. Platí na jakémkoliv paměťovém zařízení. Na systémových discích je to naprosto zásadní.
2. Uvažovat o RAID 1 místo RAID 0 na notebooku, pokud je vůbec nutné diskové pole používat. Vzhledem k velikostem a rychlosti aktuálně dostupných SSD považujeme za běžných okolností použití RAID za nesmyslné. Riziko poškození RAID pole je poměrně vysoké a benefity rozhodně nepřevažují nad rizikem.
3. Pokud je aktivované šifrování BitLocker, pak důrazně dbát na uchovávání a dostupnosti obnovovacího klíče.
4. Mít externí verzi záloh (VSS, File History, OneDrive Versioning) - oddělenou od primárního disku. Ale v zásadě je lepší jakékoliv zálohování než žádné. Z naší zkušenosti je již běžné, že v korporátním sektoru nelze udržovat jakákoliv firemní data na notebooku nebo PC. Ty fungují v zásadě jako terminály pro vzdálené virtualizované prostředí.
5. Zvážit Endpoint DLP pro blokaci lokálních mazání / šifrování citlivých dat.