Recuperar a partição LUKS após sobrescrever os primeiros bytes do contêiner LUKS? Sistema ainda em alta!

Question

Eu tenho uma partição de dados de 1,5 TB, da qual eu acidentalmente substituí alguns bytes no começo, devido a um erro de digitação como:

ssh somewhere command | dd of=/dev/sda3     // should have used quotes here, dd was executed locally by mistake!

/ dev / sda3 possui um contêiner LUKS para a partição ext4 de 1,5 TB com dados importantes.

Quando notei o problema, suspendi e matei o dd; deveria ter escrito menos de 4K.

Existe uma maneira de recuperar os dados? O computador não foi reinicializado desde então, todos os dados perdidos ainda podem estar na RAM? O que o primeiro (digamos) 4k de um contêiner LUKS contém?

A partição ainda está montada, mas mostra erros como

[1157706.786897] EXT4-fs error (device dm-4): htree_dirblock_to_tree:896: inode #2: block 9249: comm ls: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2791782547, rec_len=44529, name_len=90

ao tentar acessá-lo.

Por favor, ajude!

Obrigado!

PS: Fiz mais alguns testes e parece que mais dados foram sobrescritos do que apenas 4K :-( Mas ainda uma porcentagem muito pequena dos dados de 1,5 TB! Ainda posso despejar dados da região não contaminada? talvez pesquisar com um ferramenta de recuperação ext4 (se existir uma boa) em um dump do / dev / mapper / cr_sda3 - isso ainda funcionaria?

    

Answer 1

Primeiro: execute dmsetup table --showkeys . Salve a saída desse local em algum lugar seguro - essa grande cadeia hexadecimal longa é a atual chave de criptografia (chave mestra) usada para proteger seus dados. O LUKS funciona (simplificando aqui) criptografando essa chave com sua (s) senha (s), portanto, tenha em mente que o comprometimento dessa chave significa o fim do jogo - uma mudança de frase secreta não ajudará. Você tem que limpar e recriar a partição LUKS. No entanto, essa mesma propriedade significa que, mesmo com um cabeçalho LUKS completamente destruído, você pode usar essa "tabela" (incluindo a chave) para ler seus dados.

A linha que você está procurando (e pode haver muitas linhas, o LVM também usa o Device Mapper) é assim. Exceto que em vez de um monte de 0s, você terá dígitos hexadecimais aleatórios (os 0s são o que você obtém sem --showkey):

Zia-swap_crypt: 0 11714560 crypt aes-xts-plain64 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0 253:1 0

(Você faz o primeiro acima porque é rápido. Se a energia acabar, a máquina trava, etc. você pode usá-la para recuperar seus dados. Sem ela, seus dados seriam irrecuperáveis.)

Você quer manter toda a linha. Melhor ainda, toda a saída. Você pode alimentar essa linha de volta para dmsetup para restaurar a tabela e, assim, seu acesso aos dados, mesmo sem o cabeçalho LUKS).

Em seguida, copie uma imagem do dispositivo descriptografado em algum lugar. O dispositivo descriptografado é o nome que você vê na saída dmsetup acima; no meu caso /dev/mapper/Zia-swap_crypt . É o mesmo que você colocaria em /etc/fstab ou passaria para mount .

Agora, você pode copiar seus dados do sistema em execução (por exemplo, com tar ) ou, se isso falhar, tentar um fsck para reparar o sistema de arquivos. (Então copie os dados).

Você pode usar essa chave para criar um novo cabeçalho LUKS, e isso deve funcionar - ou apenas reinicializá-lo e começar de novo.

No futuro, faça uso de cryptsetup luksHeaderBackup .