Skip to content

Poškozený šifrovaný kontejner VeraCrypt, LUKS nebo BitLocker: Obnovení vestavěného záhlaví zálohovaného svazku

Tísňová čísla se v jednotlivých zemích liší. Tato stránka používá 911, číslo pro Spojené státy a Kanadu. Mnoho dalších zemí používá číslo 112, 999 nebo jiné číslo. Najděte číslo pro vaši zemi.

Zadáním 100% správného šifrovacího hesla do a VeraCrypt souborový kontejner nebo oddíl, Linux LUKS (dm-crypt) svazek, Windows BitLocker pohon, nebo a Cryptomator cloudový trezor - zasáhnout pouze Operation failed due to one or more of the following: Incorrect password / Not a valid volume,Device /dev/nvme0n1p3 is not a valid LUKS device, nebo Windows vyzve k rozdělení disku s dotazem "Musíte naformátovat disk v jednotce D:, než ji budete moci použít" - spustí okamžitý strach. Proč dochází k náhodnému výpadku napájení, nucenému odpojení USB Quick Format / diskpart clean, nebo jeden vadný sektor při posunutí bajtů 0 způsobit, že celý 2terabajtový šifrovaný disk odmítne platné heslo? Protože šifrování disku na úrovni bloku (XTS-AES-256(VMK / Volume Master Key)**. Pokud prvních 512 bajtů až 131 072 bajtů (128 KB) svazku, který byl přepsán náhodnou inicializací tabulky oddílů nebo poškozen zhnědnutím, primární hlavička je pryč. Naštěstí obě VeraCrypt a BitLocker automaticky vloží kompletní, identické záhlaví druhého záložního svazku na konec svazku, a pokud některý počítač stále má (nebo nedávno měl) svazek připojený v paměti RAM, AES Hlavní klíč lze vyřezat přímo z nestálé paměti. Pokud je vaše uzamčení způsobeno zapomenutým 48místným obnovovacím klíčem BitLocker nebo resetováním základní desky TPM na neporušeném záhlaví, přejděte na našeho doprovodného průvodce na Uzamčení klíče pro obnovení šifrování BitLocker, FileVault a LUKS a resetování TPM. Pokud fyzický disk kliká nebo přestává být offline, poraďte se selhání pevného disku a obnova dat, nebo pokud jste omylem naformátovali nezašifrovaný oddíl, viz náhodné smazání souboru, naformátování disku a obnovení fotografií. Pokud toto selhání šifrování ovlivní kritickou nemocniční infrastrukturu, pohotovostní odeslání nebo incident s aktivním vydíráním, zavolejte na místní tísňové číslo (911 ve Spojených státech a Kanadě, 112 po celé Evropské unii, 999 ve Spojeném království) nebo se podívejte do našeho mezinárodního adresáře tísňová čísla.

Udělejte to teď

  1. Ihned ZASTAVTE a NIKDY neklikejte na „Formátovat disk“, „Inicializovat disk“ (GPT/MBR)“ nebo běžet chkdsk / fsck přímo na nepřipojeném nezpracovaném zařízení: Když Windows nebo macOS nerozpoznají šifrované VeraCrypt, LUKSnebo BitLocker oddílu (protože hlavičky VeraCrypt jsou záměrně nerozeznatelné od náhodného šumu a postrádají magickou signaturu prostého textu), operační systém zobrazí dialogové okno s textem "Inicializovat disk" nebo "Formátovat disk." Kliknutím na Inicializovat (GPT) přepíše sektory LBA 0 skrz 33 (Bytes 0 to 17,408) na začátku disku a na posledním 33 sektory na samém konci disku - zničení jak primární hlavičky VeraCrypt, tak vestavěné hlavičky zálohy jediným kliknutím.
  2. Než uděláte cokoliv jiného, zkontrolujte, zda je zašifrovaný svazek STÁLE připojen (nebo zda je počítač v režimu hibernace/pozastaven), abyste mohli extrahovat hlavní šifrovací klíč z paměti RAM: Pokud došlo k vymazání záhlaví svazku z disku, zatímco je kontejner stále připojený a otevřený na vašem počítači (nebo pokud soubor virtuálního počítače/hibernace hiberfil.sys / /dev/mem existuje od doby, kdy byl otevřen), NEODPOJUJTE, nezamykejte ani nerestartujte počítač. Okamžitě zkopírujte každý jednotlivý soubor z připojeného disku a vypište paměť jádra (dmsetup table --showkeys na Linuxu LUKSnebo aeskeyfind / Passware / Volatility na výpisech paměti RAM) k extrahování živého obsahu 512-bit XTS-AES Master Key.
  3. Klonujte poškozený kontejner šifrovaného souboru (.hc / .tc) nebo pomocí fyzického oddílu bit po bitu ddrescue PŘED kliknutím na „Obnovit záhlaví svazku“: Nikdy neupravujte poškozený originál .hc soubor nebo oddíl na svém místě. Zkopírujte .hc kontejneru na druhý disk nebo image poškozeného oddílu (sudo ddrescue -d -r3 /dev/sdb1 /mnt/backup/encrypted_clone.img /mnt/backup/mapfile.log) a proveďte všechny obnovy záhlaví a testovací připojení výhradně proti klonu.
  4. Při použití VeraCrypt (nebo dědictví TrueCrypt), zaškrtněte políčko označené "Use backup header embedded in volume" uvnitř Mount Options právě teď: Každý svazek VeraCrypt (jak kontejnery souborů, tak svazky oddílů/zařízení) ukládá své Primární záhlaví v bajtech 0 do 65,535 (první 64 KB) a automaticky zapíše identickou šifrovanou zálohovací hlavičku do LAST 65,536 bajtů (64 KB) na samém konci svazku (nebo na offsetu Volume_Size - 131,072 pokud existuje oblast skrytého svazku). Jednoduše klikněte na Možnosti připojení -> zaškrtnout "Use backup header embedded in volume" -> klikněte na OK obejde zničené přední záhlaví a připojí celý disk za 3 sekundy.
  5. Při použití BitLocker v systému Windows a primární spouštěcí sektor (-BOOT-) byl vymazán náhodným rychlým formátováním nebo smazáním diskového oddílu, spusťte repair-bde skenování disku na 3 redundantní záhlaví metadat BitLocker: BitLocker se nespoléhá na jediné záhlaví v sektoru 0; zapíše tři nadbytečné 64 kilobajty -FVE-FS- Bloky metadat šifrování celého svazku rozeseté po celém oddílu (Offset 1, Offset 2a Offset 3). Běh repair-bde D: E: -pw (nebo -rp 48-digit-key) automaticky vyhledá přeživší -FVE-FS- blok metadat uprostřed jednotky a dešifruje celý svazek na záchranný disk.
  6. Pokud používáte Linux LUKS2 (cryptsetup), prohledejte prvních 16 megabajtů oddílu na sekundární záhlaví JSON (SKB2) nebo vyřezat LUKS magické bajty (4c 55 4b 53 ba be) pokud se hranice oddílu posunula: Moderní LUKS2 ukládá dvě redundantní binární+JSON metadata záhlaví: Primární záhlaví na odsazení 0x0000 (LUKS\xba\xbe) a sekundární záhlaví (SKB2\xba\xbe) při odsazení 0x4000 (16,384 bytes / 16 KB, nebo vyšší v závislosti na zarovnání klávesové drážky). Pokud byl vynulován pouze sektor 0, LUKS2 lze opravit pomocí sekundární hlavičky.

Danger

Proč jeden poškozený bajt uvnitř 128 KB Šifrovaná oblast Keyslot zničí celý svazek, pokud nemáte záložní hlavičku - zatímco poškozený bajt v datové oblasti poškodí pouze 16 bajtů: Moderní šifrování disku (VeraCrypt, LUKS, BitLocker) používá XTS-AES-256 režim. - V oblasti dat: Každý 512-byte nebo 4,096-byte sektor disku je šifrován nezávisle (16-byte šifrovací bloky AES). Pokud se na vašem pevném disku objeví vadný sektor při velikosti 500 gigabajtů, pouze jeden 4 KB fragment souboru je poškozen; zbývajících 99,9999 procent vašeho disku se dešifruje normálně. - V záhlaví hlasitosti (First 128 KB): Vaše heslo projde PBKDF2-HMAC-SHA512 nebo Argon2id pouze k dešifrování Hlavního klíče (VMK) uložené v záhlaví. Pokud dojde k přepsání nebo ztrátě **primárního záhlaví i záložního záhlaví, dokonce ani superpočítač národního státu nedokáže dešifrovat datovou oblast, i když své heslo znáte nazpaměť, protože vaše heslo odemyká pouze náhodný 512bitový hlavní klíč, který byl uložen v této hlavičce.


Rozhodovací strom: obnovení poškozeného svazku VeraCrypt, LUKS, BitLocker nebo Cryptomator

Použijte tento přesný diagnostický vývojový diagram k výběru správné cesty obnovy bez přepsání přežívajících hlaviček zálohy:

flowchart TD
    Start["Šifrovaný svazek odmítá správné heslo nebo zobrazuje „RAW / neformátovaný“"] --> StillMounted{"Je zašifrovaný svazek STÁLE připojen k libovolnému běžícímu počítači (nebo byl počítač během připojení v režimu spánku)?"}

    StillMounted -->|"ANO: Svazek je otevřený nebo hibernovaný"| ExtractRAM["KRITICKÁ PRIORITA: Okamžitě zkopírujte všechny otevřené soubory a vypište RAM / klíče jádra (tabulka dmsetup --showkeys na Linuxu; Vypište hiberfil.sys / RAM na Windows)"]

    StillMounted -->|"NE: Svazek je odpojen / uzamčen"| CloneFirst["KROK 1: Vytvořte klon sektoru bit za bit pomocí ddrescue (nikdy se nedotýkejte původního disku nebo souboru .hc)"]

    CloneFirst --> Platform{"Která šifrovací platforma je poškozená?"}

    Platform -->|"VeraCrypt nebo TrueCrypt (.hc, .tc, oddíl nebo systémový disk)"| VeraPath["1. Klikněte na 'Možnosti připojení' -> Zaškrtněte 'Použít záhlaví zálohy vložené do svazku' -> Připojit pouze pro čtení. 2. V případě úspěchu spusťte na klonu 'Nástroje -> Obnovit záhlaví svazku'. 3. Pokud byl kontejner souboru zkrácen, vložte soubor zpět na původní velikost bajtů, abyste zarovnali koncové záhlaví"]

    Platform -->|"Linux LUKS1 / LUKS2 (dm-crypt)"| LuksPath["1. Zkontrolujte, zda se počáteční sektor oddílu posunul pomocí Hex Scan pro 'LUKS\\xba\\xbe' (4c 55 4b 53 ba be). 2. U LUKS2 zaškrtněte sekundární záhlaví 'SKB2\\xba\\xbe' na Offset 0x4000 (16 kB). 3. Obnovte externí zálohu záhlaví pomocí cryptsetup luksHeaderRestore"]

    Platform -->|"Windows BitLocker (jednotka OS nebo datová jednotka)"| BitPath["1. Naskenujte oddíl na podpis metadat '-FVE-FS-' (3 redundantní kopie uložené na disku). 2. Spusťte 'repair-bde Source: TargetDrive: -rp RecoveryKey' nebo použijte Dislocker / UFS Explorer k analýze přežívajícího bloku metadat FVE"]

    Platform -->|"Cryptomator Cloud Vault (d/ Directory + masterkey.cryptomator)"| CryptoPath["1. Obnovte masterkey.cryptomator z automatického masterkey.cryptomator.bkup nebo z historie cloudových verzí (30denní historie souborů na OneDrive/Dropbox/Google Drive). 2. Spusťte Cryptomator Health Check a obnovte osiřelé soubory šifrovaného textu"]

Fáze 1: Jak skutečně fungují šifrovaná záhlaví svazku na disku (Anatomie s bajtovým posunem)

Před pokusem o jakoukoli opravu zkontrolujte přesné rozložení bajtů VeraCrypt, LUKS, BitLockera Cryptomator Chcete-li zjistit, proč vaše heslo selhalo a kde se na vašem disku nachází redundantní záloha:

Šifrovací systém Kde žije Primární záhlaví (Posun bajtů) Kde na disku žije Redundantní záložní záhlaví Magický podpis v hexu (můžete ho vyřezat?)
VeraCrypt & TrueCrypt (standardní nebo skrytý objem) - Standardní záhlaví: Bajty 0 do 65,535 (0x00000 do 0x0FFFF, 64 KB).
- Hidden Volume Header: Bajty 65,536 do 131,071 (0x10000 do 0x1FFFF, 64 KB).
- Skutečná šifrovaná datová oblast: Začíná na byte 131,072 (128 KB).
100% vestavěný na konci svazku:
- Záložní standardní záhlaví: Nachází se v posledním 131,072 do 65,536 bajtů (End - 128 KB do End - 64 KB).
- Záložní skrytá hlavička: Nachází se v úplně posledním 65,536 bajtů (End - 64 KB do End).
NONE (Záměrně Anti-Forensic). Každý bajt hlavičky VeraCrypt je zašifrován pomocí XTS-AES / Serpent / Twofish takže to vypadá jako čistě náhodný šum (entropy around 7.999 bits/byte). Pouze dešifrování pomocí hesla odhalí magický řetězec ASCII VERA (0x56 0x45 0x52 0x41) při dešifrovaném byte offsetu 64.
VeraCrypt Systémová jednotka (Windows Boot Encryption) Uloženo v posledním 512 bajtů první stopy (Posun bajtů 31,744, Sektor 62 na starší verzi MBR) nebo uvnitř EFI Konfigurace zavaděče oddílu VeraCrypt. Full Backup Header vestavěný na konci šifrovaného systému Windows C: systémový oddíl a navíc na VeraCrypt Rescue Disk .iso / USB. Dešifrovaný offset 64 = VERA (nebo TRUE na starší verzi TrueCrypt).
Linux LUKS2 (cryptsetup) - Primární binární + záhlaví JSON: Bajty 0 do 16,383 (0x0000 do 0x3FFF, 16 KB).
- Oblast Keyslots: Začíná za oběma záhlavími (obvykle 32 KB do 16 MB).
- Sekundární binární + hlavička JSON: Ukládá se bezprostředně po primární hlavičce na Byte Offset 16,384 (0x4000, 16 KB - nebo 0x8000 / 0x10000 pro větší metadata JSON).
- Poznámka: Na rozdíl od VeraCrypt, LUKS2 neduplikuje 256 KB anti-forenzní klíčový materiál na konci disku.
- Primární magie v 0x0000:LUKS\xba\xbe (4c 55 4b 53 ba be).
- Sekundární magie v 0x4000:SKB2\xba\xbe (53 4b 42 32 ba be).
Windows BitLocker (NTFS / FAT32 / exFAT) Boot sektor ve společnosti Byte 0 obsahuje -FVE-FS- (Windows ⅞/10/11) nebo MSWIN4.1 s ukazateli na tři bloky metadat FVE. TŘI Hotové 64 KB Kopie -FVE-FS- Záhlaví metadat svazku (obsahující VMK a FVEK Chrániče kláves) jsou rozptýleny po oddílu (typicky jeden blízko začátku, jeden blízko středu a jeden na konci oddílu). Řetězec ASCII v otevřeném textu -FVE-FS- (2d 46 56 45 2d 46 53 2d) na začátku každého ze 3 bloků metadat.
Cryptomator (Cloudové šifrování souborů po souboru) Uloženo v malém textovém souboru JSON s názvem masterkey.cryptomator (plus vault.cryptomator) v kořenové složce vašeho trezoru. Automaticky zapisuje masterkey.cryptomator.bkup ve stejné složce A každý poskytovatel cloudu (Dropbox, Google Drive, OneDrive, iCloud) uchovává 30denní historii verzí z masterkey.cryptomator. Standardní prostý text JSON ("scryptSalt", "primaryMasterKey", "hmacMasterKey").

Fáze 2: Obnova krok za krokem pro VeraCrypt (a Legacy TrueCrypt)

1. Okamžitá montáž pomocí Embedded Backup Volume Header

Když a VeraCrypt přepážka popř .hc kontejner souborů je zasažen náhodným rychlým formátováním systému Windows, přepsáním tabulky oddílů (fdisk / diskpart), nebo vadný sektor na začátku jednotky, první 64 KB je poškozen - ale záložní záhlaví sedí v posledním 128 KB na konci svazku je stále 100 procent neporušený.

Po vytvoření a. postupujte přesně podle těchto kroků ddrescue klon vašeho oddílu nebo zkopírování vašeho .hc soubor: 1. Otevřete VeraCrypt, klikněte na Vybrat soubor (pro výběr klonovaného .hc soubor) nebo Vybrat zařízení (pro výběr klonovaného oddílu, např. \Device\Harddisk2\Partition1 nebo /dev/sdb1) a vyberte nepoužívané písmeno jednotky (Z:). 2. Klikněte na Připojit. 3. V dialogovém okně hesla: - Zadejte své Heslo, PIM (pokud je použito) a Soubory klíčů (pokud je použito). - Klikněte na Mount Options... tlačítko ve spodní části okna hesla. - Zaškrtněte OBĚ z těchto políček: - [x] Mount volume as read-only (Zabraňuje systému Windows/macOS v úpravě jakýchkoli poškozených struktur souborového systému uvnitř dešifrovaného svazku během záchrany) - [x] Use backup header embedded in volume - Klikněte na OK pro připojení. 4. Pokud se svazek úspěšně připojí (nebo se připojí jako a RAW písmeno jednotky Z: protože vnitřní NTFS/FAT32/exFAT boot sektor v byte 131,072 byl také označen): - Li Z: se normálně otevře v Průzkumníku souborů: Zkopírujte 100 procent souborů Z: okamžitě na bezpečnou jízdu. - Li Z: se připojí ve VeraCrypt (zobrazeno ve slotu VeraCrypt), ale Windows říká "Z: is not accessible / The volume does not contain a recognized file system": NEZOUFEJTE. To znamená, že Vaše šifrování VeraCrypt je 100 procent odemčeno a pouze vnitřní NTFS / exFAT / ext4 superblok uvnitř prvních několika megabajtů dešifrovaného svazku byl poškozen. Udržujte svazek připojený ve VeraCrypt jako Z: (nebo /dev/mapper/veracrypt1 na Linuxu) a spusťte TestDisk,DMDE,UFS Explorer nebo PhotoRec přímo proti dešifrované virtuální jednotce VeraCrypt (Z: / /dev/mapper/veracrypt1) - všechny vaše dešifrované soubory budou okamžitě obnoveny. 5. Trvalá oprava hlavičky primárního svazku na vašem klonu: - Jakmile jsou vaše soubory bezpečně zálohovány, můžete natrvalo opravit poškozené přední záhlaví na klonu svazku kliknutím na Nástroje hlasitosti -> Obnovit záhlaví svazku -> Obnovit záhlaví svazku ze zálohy vložené do svazku a zadáním hesla.

2. Co když a VeraCrypt .hc Byl souborový kontejner zkrácen nebo změněna velikost během cloudové synchronizace nebo selhání disku?

Počkat: proč by "Use backup header embedded in volume" selhat na a .hc kontejner souborů? - Protože VeraCrypt najde vložené záhlaví zálohy hledáním Exact_File_Size - 131,072 bytes (0x20000 bajtů od konce souboru). - Pokud kopie USB není úplná, rsync přerušení nebo selhání souborového systému zkráceno nebo připojeno dokonce 1 bajt navíc na konec vašeho .hc kontejneru, VeraCrypt hledá nesprávný bajtový offset na konci souboru. - Jak zkontrolovat a opravit nesouosost .hc kontejner souboru: - Každá platná velikost souboru kontejneru VeraCrypt MUSÍ být přesným násobkem 512 bajtů. Zkontrolujte přesnou velikost vašeho bajtu .hc soubor (ls -l container.hc nebo stat -c %s container.hc). - Pokud je primární záhlaví na Byte 0 je stále neporušený (protože k poškození došlo na konci souboru během přerušení přenosu), jednoduše založte .hc soubor s nulami pomocí truncate -s na kopii souboru až do dalšího násobku 1,048,576 bajtů (1 MB) - například pokud by to bylo a 10 GB kontejner, který byl odříznut u 9.4 GB, běhat truncate -s 10G container_copy.hc - a připojte normálně pomocí Primary Header v režimu pouze pro čtení.

3. Co když někdo smaže tabulku oddílů (fdisk / diskpart clean), takže nevíte, na kterém sektoru se oddíl VeraCrypt spustil?

Protože hlavičky VeraCrypt obsahují nula magických bajtů prostého textu, standardní skenery oddílů (TestDisk) nevidí, kde začíná nebo končí odstraněný oddíl VeraCrypt. - Jak najít přesný počáteční sektor ztraceného oddílu VeraCrypt (TestCrypt / VeraCrypt Volume Finder): 1. Téměř všechny oddíly vytvořené od roku 2010 jsou zarovnány na 1-Megabajt (1 MiB = 2,048 512bajtové sektory = 1,048,576 bajtů) hranice (konkrétně začínající na Sector 2048 pro první oddíl nebo na přesný 2048-sektorový násobek). 2. Ještě lepší: zatímco primární záhlaví žije na začátku oddílu, záložní záhlaví žije na posledním 128 KB na konec oddílu (který je téměř vždy zarovnán přímo proti konci fyzického disku nebo začátku dalšího oddílu). 3. Použijte nástroj s otevřeným zdrojovým kódem TestCrypt nebo krátký Python pyveracrypt / cryptsetup --type tcrypt smyčka, která testuje vaše známé heslo proti všem 1 MiB (2,048-sector) hraniční posun v obrazu disku (losetup -o $((offset * 1048576)) -r -f disk.img), dokud vaše heslo nerozšifruje VERA kouzelná hlavička.


Fáze 3: Obnova krok za krokem pro Linux LUKS1 a LUKS2 (dm-crypt)

1. Diagnostika poškozené LUKS záhlaví (hexdump kontrola)

Bootování z Linux Live USB (SystemRescue nebo Ubuntu Live), udělat a ddrescue obrázek oddílu a prohlédněte si první 32 KB oddílu bez úpravy jediného bajtu:

sudo head -c 32768 /dev/nvme0n1p3 | hexdump -C | head -n 40
- Jaké zdravé LUKS2 hlavička vypadá takto: - Offset 0x00000000: 4c 55 4b 53 ba be 00 02 (LUKS.. následuje verze 0x0002). - Offset 0x00001000 (4,096 bytes): Plaintext JSON metadata popisující "keyslots", "segments", "digests"a "config" (včetně přesných bajtových offsetů a šifrovací šifry aes-xts-plain64). - Offset 0x00004000 (16,384 bytes):53 4b 42 32 ba be 00 02 (SKB2.. - Sekundární binární LUKS2 + hlavička JSON.).

2. Upevnění a LUKS2 oddíl, když Sector 0 (Primary Header) byl vymazán uživatelem wipefs, mkswapnebo špatný sektor

Li wipefs nebo zbloudilý zápis vynuloval první 4 KB (Offset 0x0000), cryptsetup luksOpen může selhat - pokud cryptsetup opraví primární záhlaví z neporušeného sekundárního záhlaví (SKB2) v 0x4000: 1. Vyzkoušejte, zda cryptsetup repair může automaticky znovu sestavit primární záhlaví (LUKS\xba\xbe) z neporušeného sekundárního záhlaví (SKB2\xba\xbe) na vašem klonovaném obrázku:

sudo cryptsetup repair /mnt/backup/luks_clone.img
2. Co když byla oblast metadat JSON poškozena, ale binární materiál Keyslot (0x8000 do 0x40000) je stále neporušený? - Protože LUKS2 ukládá svou konfiguraci v pro člověka čitelném prostém textu JSON at 0x1000 a 0x5000, můžete extrahovat přežívající text JSON (dd if=luks_clone.img bs=1 skip=20480 count=12288 | strings), zrekonstruovat čistý LUKS2 záhlaví na fiktivním souboru přesně stejné verze (Ubuntu 22.04/24.04 výchozí na aes-xts-plain64, 512-bit klíč, argon2id, offset dat 16777216 / 16 MiB) a transplantujte neporušenou oblast binárního slotu (dd od 0x8000 do 16 MiB) do rekonstruovaného záhlaví.

3. Nalezení a LUKS záhlaví, když tabulka oddílů (GPT/MBR) byl smazán nebo posunut

Pokud jste omylem smazali LUKS oddíl v fdisk / gparted nebo naformátujte celý disk pomocí nové tabulky oddílů, the LUKS\xba\xbe hlavička je často stále zcela nedotčená na svém původním bajtovém offsetu (obvykle 1 MiB = byte 1,048,576, nebo hned po EFI a /boot oddíly): 1. Naskenujte celý nezpracovaný disk na 6bajtový LUKS magický podpis (4c 55 4b 53 ba be):

sudo LC_ALL=C grep -a -b -o $'\x4c\x55\x4b\x53\xba\xbe' /dev/nvme0n1
2. Předpokládejme grep výstupy 1074790400:LUKS... Rozdělit 1074790400 podle 512 (= Sector 2099200). 3. Namapujte zařízení se zpětnou smyčkou pouze pro čtení počínaje tímto přesným bajtovým offsetem a odemkněte své LUKS hlasitost okamžitě, aniž byste se dotkli tabulky oddílů:
sudo losetup -o 1074790400 --read-only -f --show /dev/nvme0n1
sudo cryptsetup open --readonly /dev/loop0 rescued_luks
sudo mount -o ro /dev/mapper/rescued_luks /mnt/rescue

4. Extrahování LUKS Hlavní klíč (VMK) ze spuštěného nebo hibernovaného systému Linux

Pokud a LUKS hlavička na disku je 100 procent zničena (například někdo spustil dd if=/dev/zero of=/dev/nvme0n1p3 bs=1M count=20), okamžitě zkontrolujte, zda systém Linux stále má /dev/mapper/... otevřeno: 1. Pokud systém stále běží s namapovaným svazkem, NEREBOTUJTE. Vytiskněte nezpracovaný hexadecimální hlavní klíč (VMK) přímo z jádra dm-crypt tabulka:

sudo dmsetup table --target crypt --showkeys
(Vytištěný 5. sloupec je nezpracovaných 64 bajtů / 128 hexadecimálních znaků AES-XTS Hlavní klíč.) 2. S tímto hexadecimálním hlavním klíčem uloženým do textového souboru (master.key), můžete znovu postavit zcela nový LUKS záhlaví s novým heslem na vašem klonovaném obrázku kdykoli:
xxd -r -p master_hex.txt > master.key
sudo cryptsetup luksFormat --master-key-file master.key /mnt/backup/luks_clone.img


Fáze 4: Obnova krok za krokem pro Windows BitLocker (repair-bde & -FVE-FS- Vyřezávání metadat)

Když a BitLocker-encrypted disk je omylem rychle zformátován, inicializován nebo trpí sektorem 0 poškození, Průzkumník souborů Windows zobrazuje jednotku jako RAW nebo Unallocated a poklepáním na něj se již nezobrazí výzva k zadání hesla/klíče pro obnovení nástroje BitLocker.

1. Proč BitLocker téměř vždy přežije rychlý formát nebo sektor 0 otřít

Když BitLocker zašifruje soubor NTFS, FAT32nebo exFAT svazku, vytvoří na disku tři identické, samostatné 64kB bloky metadat, z nichž každý začíná 8bajtovým podpisem ASCII -FVE-FS- (2d 46 56 45 2d 46 53 2d): - Kopírovat 1: Nachází se poblíž začátku oddílu (obvykle v rámci prvních několika set megabajtů). - Kopírovat 2 a Kopírovat 3: Nachází se o desítky nebo stovky gigabajtů hlouběji uvnitř oddílu. - Rychlé formátování Windows přepíše pouze úplný začátek oddílu (spouštěcí sektor a začátek oddílu $MFT), ponechte Kopírovat 2 a Kopii 3 z -FVE-FS- Blok metadat BitLocker (který obsahuje váš zašifrovaný hlavní klíč svazku VMK a šifrovací klíč plného svazku FVEK) 100 procent neporušené.

2. Pomocí vestavěného systému Microsoft repair-bde.exe nástroj k dešifrování poškozeného svazku BitLocker

  1. Otevřete Příkazový řádek správce (cmd.exe) v systému Windows 10/11 (nebo bootování z USB pro obnovení systému Windows).
  2. Připojte druhý prázdný externí pevný disk (E:) dostatečně velký, aby pojal dešifrovaný oddíl.
  3. Spustit repair-bde ke skenování poškozené jednotky BitLocker (D:) za všechny přeživší -FVE-FS- blok metadat a zapište do něj dešifrovaný svazek E::
  4. Pokud odemykáte pomocí 48místného hesla pro obnovení nástroje BitLocker:
    repair-bde D: E: -rp 111111-222222-333333-444444-555555-666666-777777-888888 -LogFile C:\repair_log.txt
    
  5. Pokud odemykáte jednotku USB BitLocker-To-Go pomocí uživatelského hesla:
    repair-bde D: E: -pw -LogFile C:\repair_log.txt
    
  6. Jednou repair-bde dokončí dešifrování sektorů na E:, je-li vnitřní NTFS boot sektor nebo začátek $MFT byl poškozen dřívějším rychlým formátováním, spustit DMDE,UFS Explorer nebo TestDisk proti nyní dešifrované jednotce E:.

Fáze 5: Obnova krok za krokem pro Cryptomator Cloudové trezory (masterkey.cryptomator)

Na rozdíl od VeraCrypt, LUKSa BitLocker (které šifrují celý obraz disku blok po bloku), Cryptomator šifruje jednotlivé soubory ve struktuře složek (d/XX/XXXXXXXXXXXXXXXXXXXXXXXX.c9r) navržený pro Dropbox, Disk Google, OneDrive a iCloud.

1. Upevnění "Invalid Masterkey / Vault Config" nebo Chybí masterkey.cryptomator

Každý trezor Cryptomator závisí na dvou malých souborech JSON v kořenové složce úložiště: vault.cryptomator (ve kterém je uložena konfigurace trezoru JWT a kombinace šifry) a masterkey.cryptomator (který ukládá vaše scrypt-zabalený 256bitový hlavní klíč šifrování a 256bitový HMAC Hlavní klíč). - Oprava 1: Obnovit z masterkey.cryptomator.bkup: Pokaždé, když úspěšně odemknete trezor Cryptomator, Cryptomator automaticky zapíše ověřenou záložní kopii s názvem masterkey.cryptomator.bkup hned vedle masterkey.cryptomator. Pokud dojde k poškození konfliktu synchronizace s cloudem masterkey.cryptomator (zerobajtový soubor nebo částečný JSON), jednoduše zkopírujte masterkey.cryptomator.bkup do masterkey.cryptomator. - Oprava 2: Použijte 30denní historii verzí souborů vašeho poskytovatele cloudu: Přihlaste se do webového rozhraní Disku Google (Manage versions), Dropbox (Version history) nebo OneDrive (Version history), klikněte pravým tlačítkem masterkey.cryptomator a vault.cryptomatora obnovte verzi z doby před poškozením. - Oprava 3: Spusťte vestavěný Cryptomator "Health Check" zachránit osiřelé .c9r soubory: Pokud se váš trezor odemkne pomocí vašeho hesla, ale složky vypadají prázdné, protože chyba synchronizace s cloudem poškodila dir.c9s adresář-ukazatel, klikněte na Vault Options -> Health Check v Cryptomatoru. Health Check kontroluje každý d/XX/ podsložka pro osiřelé zašifrované .c9r soubory, jejichž odkaz na nadřazený adresář se zlomil a automaticky rekonstruuje Cryptomator_Recovery složka v odemčeném trezoru obsahující všechny vaše zachráněné soubory.

Tip

Proveďte tento 30sekundový preventivní úkol na všech svých neporušených šifrovaných discích ještě dnes (Export External Header Backup): Nikdy se nespoléhejte pouze na hlavičky na disku. - In VeraCrypt: Připojte nebo vyberte svůj svazek -> klikněte na Nástroje hlasitosti -> Záhlaví svazku -> uložte 128 KB záložní soubor binární hlavičky (my_drive_header.bak) na flash disk nebo cloudové úložiště. - In Linux LUKS: Spustit sudo cryptsetup luksHeaderBackup /dev/nvme0n1p3 --header-backup-file $HOME/luks_header_backup.bin a uložte luks_header_backup.bin mimo zařízení. - In BitLocker: Spustit manage-bde -protectors -get C: a uložte si své 48místné heslo pro obnovení a binární kód .BEK Soubor obnovovacího klíče (manage-bde -protectors -add C: -RecoveryKey E:\) na samostatný USB flash disk.


Regionální čísla tísňového volání a protokoly agentur

Zatímco poškozený zašifrovaný kontejner na osobním počítači je nouzovou událostí při obnově technických dat, šifrovací výluky ovlivňující nemocnice, obecní infrastrukturu, právní odhalení podléhající soudnímu příkazu nebo regulované osobní údaje (GDPR / HIPAA) může vyžadovat formální hlášení incidentu:

  • Spojené státy a Kanada:
  • Nouzová bezpečnost života / Výpadek kritické infrastruktury: Vytočte 911 pokud selhání šifrované databáze ovlivní péči o pacienta nebo kontroly fyzické bezpečnosti.
  • ** Agentura pro kybernetickou bezpečnost a bezpečnost infrastruktury (CISA) (Spojené státy americké)**: Pokud bylo poškození hlavičky svazku způsobeno destruktivním stěračem nebo cíleným útokem ransomwaru LUKS / BitLocker / VeraCrypt hlavičky, nahlaste se ihned na CISA at 1-844-Say-CISA (1-844-729-2472) a FBI Internet Crime Complaint Center (ic3.gov).
  • HIPAA / Regulovaná dostupnost dat: Podle amerického ministerstva zdravotnictví a sociálních služeb (HHS) Úřad pro občanská práva (OCR) pokyny, trvalá ztráta přístupu k nezálohovaným šifrovaným elektronickým chráněným zdravotním informacím (ePHI) kvůli korupci nebo ransomwaru vyžaduje posouzení podle pravidel HIPAA Breach & Contingency Plan (45 C.F.R. § 164.308(a)(7)).
  • Spojené království:
  • Pohotovostní služby: Vytočte 999 (nebo 101 pro jiné než nouzové policejní hlášení).
  • Úřad komisaře pro informace (ICO) - Porušení dostupnosti GDPR ve Spojeném království: Podle článku 32 a článku 33 GDPR ve Spojeném království je trvalá náhodná ztráta dostupnosti osobních údajů (jako je neobnovitelný zašifrovaný svazek bez zálohy) klasifikována jako porušení zabezpečení osobních údajů a může vyžadovat oznámení ICO (0303 123 1113) do 72 hodin.
  • Evropská unie:
  • Pohotovostní služby: Vytočte 112 ve všech členských státech EU.
  • ENISA a národní úřady pro ochranu údajů (DPAs): Sledujte Evropský výbor pro ochranu údajů (EDPB) Pokyny 9/2022 o oznámení o narušení osobních údajů týkající se ztráty dostupnosti při zničení kryptografických klíčů nebo hlaviček svazků bez zálohy.
  • Austrálie a Nový Zéland:
  • Pohotovostní služby: Vytočte 000 v Austrálii nebo 111 na Novém Zélandu.
  • Australské centrum kybernetické bezpečnosti (ACSC): Volejte 1300 CYBER1 (1300 292 371) pro podnikovou nebo vládní pomoc při kryptografických incidentech.
  • Indie a Asie a Tichomoří:
  • Pohotovostní služby: Vytočte 112 v Indii (nebo 1930 pro případy kybernetické kriminality; podnikové incidenty, na které se vztahuje CERT-In směr musí být nahlášen do 6 hodin incident@cert-in.org.in).

Často kladené otázky

Proč VeraCrypt říká „Nesprávné heslo nebo není svazek VeraCrypt“, když jsem si 100% jistý, že je moje heslo správné?

Protože svazky VeraCrypt jsou navrženy tak, aby byly k nerozeznání od náhodného šumu (věrohodné popření), VeraCrypt ne uložit hlavičku ve formátu prostého textu s nápisem „Jsem svazek VeraCrypt“. Místo toho, když kliknete na Připojit, VeraCrypt vezme vaše heslo a odvodí dešifrovací klíč záhlaví přes PBKDF2, dešifruje prvních 512 bajtů svazku a zkontroluje, zda bajtů 64 do 67 dešifrovaného výstupu hláskujte slovo ASCII VĚRA (a předat a CRC-32 kontrolní součet). Zda jste zadali špatné heslo nebo prvních 512 bajtů souboru/oddílu bylo přepsáno chybou disku nebo nástrojem pro vytváření oddílů Windows, dešifrované bajty se nehláskují VĚRA - takže VeraCrypt zobrazuje přesně stejnou chybovou zprávu pro oba. Montáž vždy vyzkoušejte pomocí Možnosti připojení -> Použít záhlaví zálohy vložené do svazku nejprve zkontrolovat.

Pokud jsem omylem spustil „Rychlé formátování“ na disku VeraCrypt nebo BitLocker ve Windows, jsou všechny moje soubory pryč?

Ne - 99 procent vašich zašifrovaných souborů je stále nedotčených, pokud jste okamžitě přestali zapisovat na disk. A Windows Rychlé formátování pouze zapíše nový nezašifrovaný NTFS nebo exFAT spouštěcí sektor a prázdná hlavní tabulka souborů ($ MFT) v prvních několika megabajtech oddílu. Na a VeraCrypt oddíl, který vymaže primární záhlaví na Byte 0, ale ponechává Embedded Backup Header na samém konci oddílu zcela nedotčené. Jakmile připojíte oddíl VeraCrypt v režimu pouze pro čtení pomocí vložené hlavičky zálohy (nebo spusťte oprava-bde na a BitLocker oddíl pomocí svého přežívajícího středu/konce -FVE-FS- bloky metadat), můžete dešifrovaný virtuální svazek skenovat pomocí TestDisk, DMDEnebo Průzkumník UFS obnovit celý strom složek přes sekundární $MFTMirr nebo zbývající $ MFT evidence.

Má Linux LUKS (cryptsetup) mají na konci disku vloženou hlavičku zálohy, jako to dělá VeraCrypt?

Ne - a to je zásadní rozdíl, který musí znát každý uživatel Linuxu. Dědictví LUKS1 má na začátku oddílu pouze jednu hlavičku a jednu sadu klíčů (nulové hlavičky zálohy na disku). Moderní LUKS2 (výchozí od Ubuntu 20.04 / RHEL 8 / Debian 10) ukládá Záhlaví sekundárních binárních a JSON metadat (SKB2\xba\xbe) při posunutí bajtů 0x4000 (16 kB) hned za primárním záhlavím na 0x0000 - což vám ušetří i kdyby jen sektor 0 byl vymazán tím utěrky - ale LUKS2 NEDOPULUJE zašifrovaný materiál slotu pro klíče (0x8000 do 16 MB) na konci disku. Pokud prvních 2 až 16 megabajtů a LUKS oddíl jsou přepsány a svazek není aktuálně otevřen v paměti RAM, jediný způsob, jak obnovit disk, je z externího souboru vytvořeného předem pomocí cryptsetup luksHeaderBackup.

Co když se můj svazek VeraCrypt připojí se záhlavím zálohy, ale systém Windows říká: „Před použitím je třeba disk naformátovat na jednotce Z:“?

NEKLEPEJTE na Formát. Místo toho oslavte: skutečnost, že VeraCrypt připojil svazek k písmenu jednotky Z: dokazuje, že vaše heslo bylo přijato a 512-bit XTS-AES Master Key nyní aktivně dešifruje celý disk v reálném čase. Windows si stěžují pouze proto, že vnitřní první sektor souborového systému (umístěný v byte offset 131 072 oddílu) byl také poškozen tím, co poškodilo vaši primární hlavičku VeraCrypt. Nechte svazek připojený jako Z: ve VeraCrypt (v režimu pouze pro čtení), otevřete DMDE, TestDisknebo Průzkumník UFSa vyberte připojený virtuální disk Z: (ne surový fyzický disk.). Obnovovací software okamžitě přečte vaše dešifrované soubory a zkopíruje je do bezpečí.

Mohu obnovit svazek VeraCrypt nebo LUKS, pokud si pamatuji 90 % svého hesla (např. znám základní slova, ale zapomněl jsem, které symboly nebo čísla jsem napsal velkými písmeny)?

Ano, pokud je záhlaví svazku (nebo záhlaví zálohy) neporušené a znáte strukturu svého hesla. Na rozdíl od ztráty hlavičky hlavního klíče (což je náhodný 512bitový klíč, který nelze nikdy vynutit hrubou silou), lze částečně zapamatované lidské heslo prolomit offline pomocí Hashcat s vlastním pravidlem nebo útokem masky proti extrahovaným bajtům záhlaví: for VeraCrypt, extrahujte první 512 bajtů primárního záhlaví (dd if=container.hc of=vc.hash bs=512 počet=1nebo extrahovat bajty Konec - 131072 pro záhlaví zálohy) a spusťte hashcat -m 13721 (pro SHA-512 + AES); pro LUKS, extrahujte první 2 MB do 16 MB záhlaví a použití hashcat -m 14600 (LUKS1) popř -m 29511 / 29541 (LUKS2).

Jak zjistím, zda mám SSD TRIM příkaz zničil můj poškozený šifrovaný kontejner?

Pokud je váš šifrovaný svazek a kontejner souborů (.hc) sedíte na aktivním SSD a omylem jste smazali .hc soubor (a OS vydal inline TRIM), nepřidělené bloky mohou být vynulovány. Pokud je však váš šifrovaný svazek a raw šifrovaný oddíl nebo celý disk (`VeraCrypt` hostovaný na zařízení, `LUKS`nebo `BitLocker`), řadič SSD nemá ponětí, které šifrované sektory jsou „volné“, pokud připojení souborového systému aktivně neposlalo vyřadit / TRIM příkaz přes šifrovací vrstvu (ve skutečnosti VeraCrypt blokuje TRIM standardně na nesystémových svazcích pro kryptografické zabezpečení a Linux LUKS bloky TRIM průchozí pokud povolit-zahodit byl výslovně přidán /etc/crypttab).


Související průvodci


Zdroje a oficiální pokyny

  • Národní institut pro standardy a technologie (NIST) (Spojené státy americké): Zvláštní publikace 800-38E: Doporučení pro provozní režimy blokové šifry: The XTS-AES Režim pro důvěrnost na úložných zařízeních a SP 800-111: Průvodce technologiemi šifrování úložiště.
  • IDRIX (veracrypt.fr): Oficiální technická dokumentace VeraCrypt - Specifikace objemového formátu, rozložení bajtů s posunem primárních a vestavěných záložních záhlaví (Bytes 0-65535 vs End-131072) a Postupy obnovy záhlaví.
  • Red Hat & The cryptsetup / LUKS Projekt (gitlab.com/cryptsetup/cryptsetup): LUKS2 Specifikace formátu na disku (primární LUKS\xba\xbe a sekundární SKB2\xba\xbe Binární/JSON architektura záhlaví a luksHeaderBackup Protokoly).
  • Microsoft Learn (learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/): Technický přehled BitLocker Drive Encryption, redundantní -FVE-FS- Ověření metadat a repair-bde Reference příkazového řádku.
  • Skymatic GmbH (docs.cryptomator.org): Bezpečnostní architektura kryptomatu (scrypt odvození hlavního klíče, masterkey.cryptomator.bkup Specifikace obnovy a kontroly stavu úložiště).