3.7.2020 Občas se člověku stane, že se
uklepne a smaže něco, co vůbec smazat nechtěl. A pokud jako já nepoužíváte ve Windows Koš, tak máte
problém. Pokud si to hned uvědomíte a stihnete rychle zmáčknout RESET tlačítko, tak je určitá šance,
že se data z cache ještě nezapsala fyzicky na disk (pokud systém používá pro danou jednotku write-back
cache), ale můžete zas přijít o něco jiného. Mě se zrovna povedlo smazat jedno natočené video, které
jsem myslel, že už je právě zpracované a přitom jsem omylem smazal jiné. A o to jsem rozhodně nechtěl
přijít, tak jsem se ho pokusil obnovit z SD karty ve foťáku, kde jsem naštěstí nic nového nenafotil,
takže data by tam měla ležet nepřepsaná.
Operační systém při mazání soubor běžně nemaže celý jeho obsah, protože
by to u velkých souborů trvalo docela dlouho (na skutečné přemazání obsahu souboru existují
různé wipe utility). To však neplatí u moderních OS a SSD, kde se při mazání posílá i ATA příkaz
TRIM, který SSD oznamuje,
že se dané sektory uvolnily a interní logika je brzy smaže, aby mělo SSD dostatek prázdného místa a při
dalším zápisu se nemuselo zdržovat mazáním bloků FlashROM. Na paměťových kartách, USB klíčenkách a
klasických HDD se TRIM (zatím) nepoužívá. V případě souborového systému FAT16/32 (více o jeho fungování
zde) se v adresářové položce přepíše první znak názvu
souboru na speciální hodnotu E5h, která značí, že je adresářová položka
uvolněna pro další použití a dokud není přepsaná jinou, tak ji lze snadno obnovit. Zároveň se ale
ve FAT tabulce vymaže část spojového seznamu (cluster chain) příslušného souboru, což už je destruktivní
operace, kterou nelze vrátit zpět (např. u NTFS se záznam v MFT celý nemaže a tak je obnova jednodušší).
Adresářová položka obsahuje pouze číslo prvního clusteru, kde data souboru začínala. Pak velmi záleží
na velikosti daného souboru a stavu fragmentace souborového systému, resp. zda byl daný soubor uložen
na disku ve více nesouvislých fragmentech. K fragmentaci dochází přirozeně tím, jak přibývají nové a
mažou se staré soubory různých velikostí.
Pokud je soubor menší než samotný cluster, tak je obnova velmi jednoduchá,
neboť ono číslo clusteru známe z adresářové položky a také z ní víme i přesnou velikost souboru, takže
stačí cluster přečíst a oříznout zbytek. V mém případě ale mělo video cca 140 MB, což při dané
velikosti clusteru 8 kB znamenalo cca 17000 clusterů, které by v nejnepříznivějším případě mohly
tvořit 17000 nesouvislých úseků rozházených po celém disku. Je to jako když by vám někdo na zem rozsypal
několik krabic puzzlí a promíchal. Kousek obrázku na kostičce alespoň dává nějaké vodítko, ale kousek
binárního souboru se dost blbě určuje, kam má ve výsledku vlastně patřit. Postahoval jsem a vyzkoušel
celou řadu programů na obnovu souborů, ale žádný z nich si s fragmentací neporadil. Ve sloupci "hash"
jsou poslední 4 Byte MD5 hashe, z čehož je vidět, které programy obnovily soubor stejným způsobem.
V dalším sloupci je pak použitelná velikost videa, kterou z obnoveného souboru získal program
Recover MP4 1.92,
čili výsledek nic moc, cca 1 s videa. Ještě znovu upozorňuju, že je velmi důležité si po smazání
data nepřepsat. Tzn. obnovený soubor je třeba ukládat na jiný disk či oddíl, než kde jsou smazaná data.
U systémového disku, kde jede swap a Windows si něco zapisují na pozadí holt asi smůla. U přenosného
média není na škodu aktivovat ochranu proti zápisu, pokud taková možnost je (např. mechanický lock
přepínač u disket a SD karet). Pozor na to, že prašivé Windows 10 na připojeném disku ihned vytvoří
adresář System Volume Information. Naštěstí se to dá vypnout.
Dále jsem také vyzkoušel několik programů specializovaných na obnovu
poškozených video souborů a předhodil jsem jim image SD karty začínající prvním clusterem videosouboru.
Většina programů vyžaduje ještě nějaký nepoškozený vzorový videosoubor ve stejném formátu jako ten
poškozený. Docela dobře si vedl program Kernel Video Repair 20.3,
který obnovil asi 20 s videa, ale s různými kostičkovanými efekty a vynechanými částmi.
Nakonec mi tedy nezbylo nic než poctivá ruční práce v hexaeditoru s vydatnou
pomocí Recover MP4. Vycházel jsem z předpokladu, že fragmentů nebude zas tak mnoho (na kartu se ukládají
většinou cca 20 - 30 MB velké RAWy) a že FAT allocator postupoval od prvního volného clusteru lineárně
dále, takže na vyšších číslech clusterů budou pozdější části videa v nezměněném pořadí. Abych si práci alespoň
trochu usnadnil, udělal jsem si dump pouze neobsazených clusterů. Zhruba na polovině karty mám totiž stále
ještě nezpracované fotky a je tak lepší pracovat jen s cca 8GB image než 16GB. K tomu jsem použil linuxovou
utilitu blkls, která je součástí balíku
TSK (The Sleuth Kit)
a je i v repozitáři Debianu, takže jsem jej snadno nainstaloval příkazem apt-get install sleuthkit.
Obsahuje též utilitu pro obnovu smazaných souborů: tsk_recover -v -f fat32 -i raw /dev/sde1 /sddata,
ale videosoubor mezi obnovenými soubory chyběl. Dump všech nealokovaných clusterů do image souboru jsem
vytvořil příkazem blkls -A /dev/sde1 >/sddata/unallocated.bin.
Moje zrcadlovka kóduje natáčená videa kodekem
MPEG-4/H.264
s nekomprimovaným PCM zvukem v kontejneru Apple QuickTime (MOV).
V mém případě mají soubory celkem snadno rozeznatelnou hlavičku 00 00 00 1C ftypqt 0000qt.
Našel jsem si podle ní začátek videa a předchozí data odmazal. Dále jsem potřeboval najít nějakou opakující
se signaturu ve videu, podle které bych bezpečně odlišil videodata od jiných dat. Video má rozlišení
1920 x 1080, 30 FPS a ukládá se jako pravidelná sekvence: 1 plný IDR (Instantaneous Decoder Refresh) snímek
(velký cca 300 kB), 14 částečných P snímků (velkých cca 15 kB), opět 1 IDR snímek a 14 P snímků a
blok PCM audia (48 kB), tedy po vteřině videa vteřina zvuku. Před každým IDR snímkem se nachází 6-Bytová
sekvence 00 00 00 02 09 10 - první čtveřice Bytů je velikost NALU (Big Endian)
a další 2 Byte jsou typ NALU: Access Unit Delimiter (NAL Unit Type: 9).
Podobně před každým P snímkem je sekvence 00 00 00 02 09 30. Takže vyhledáváním
těchto sekvencí jsem byl schopen rozlišit, jestli se koukám na části videa nebo fotek.
Nejprve jsem Recover MP4 pustil na krátkém vzorovém videu, které jsem si
foťákem natočil, pomocí příkazu recover_mp4_x86.exe sample.mov --analyze.
Program si z něj vytvoří 2 hlavičkové soubory audio.hdr a video.hdr,
které mu pomůžou při obnově poškozeného videa dalším příkazem recover_mp4_x86.exe unallocated.bin result.mp4 result.wav --qt --pcmfix 5DD8
(přídavné parametry program sám vypíše po prvním kroku). Program pak vypisuje nalezené IDR a P snímky
a jejich offsety v daném souboru. Když narazí na nějaký problém (neznámá data), tak je buď přeskočí
(např. "warn: 0x08696ABF [0x71FF8] {01 FF}}, False positive AVC detection. Unexpected PCM block size 0x48d95ce. Ignoring!")
nebo skončí s chybou (např. "?big: 0x03DBD4F1 [0x 49FD54F] ??? {3D 2B BA C0 79 27}").
V takovém případě jsem se musel na daný offset podívat v hexaeditoru, najít podle Access Unit Delimiteru
kde video pokračuje dále, blok cizích dat z image vyříznout a spustit Recover MP4 znovu. Takto jsem postupně
pospojoval asi 20 fragmentů videa, dokud nebylo kompletní. Zde je ukázka výpisu Recover MP4:
Video se mi nepovedlo obnovit úplně bez chyby, bylo v něm pár rozkostkovaných
snímků. Otevřel jsem ho v Avidemuxu a tyto
poškozené snímky jsem vystříhal, přidal jsem obnovenou zvukovou stopu a 2-průchodově zkomprimoval do H.264
s nižším bitrate. Tak to byla typická ukázka pinožení, jak kvůli 1 vteřině nepozornosti vznikne práce na
mnoho hodin...