Caminhando pela agonia ou pela longa história de uma tentativa de recuperação de dados

Foi em 2019. Nosso laboratório recebeu um drive QUANTUM FIREBALL Plus KA com capacidade de 9.1GB, o que não é muito comum em nossa época. Segundo o proprietário do drive, a falha ocorreu em 2004 devido a uma falha na fonte de alimentação, que levou consigo o disco rígido e outros componentes do PC. Depois houve visitas a vários serviços com tentativas de reparar o disco e restaurar dados, que não tiveram sucesso. Em alguns casos prometeram que seria barato, mas nunca resolveram o problema, em outros foi muito caro e o cliente não quis restaurar os dados, mas no final o disco passou por vários centros de atendimento. Ele foi perdido várias vezes, mas graças ao fato de o proprietário ter se preocupado em registrar antecipadamente as informações de vários adesivos no disco, ele conseguiu garantir que seu disco rígido fosse devolvido por alguns centros de serviço. As caminhadas não passaram sem deixar rastros, vários vestígios de solda permaneceram na placa controladora original, e a falta de elementos SMD também foi sentida visualmente (olhando para frente, direi que este é o menor dos problemas deste drive).

Caminhando pela agonia ou pela longa história de uma tentativa de recuperação de dados
Arroz. 1 HDD Quantum Fireball Plus KA 9,1 GB

A primeira coisa que tivemos que fazer foi procurar no arquivo de doadores por um irmão gêmeo tão antigo desta unidade com uma placa controladora funcionando. Quando esta busca foi concluída, tornou-se possível realizar extensas medidas de diagnóstico. Depois de verificar se há curto-circuito nos enrolamentos do motor e certificar-se de que não há curto-circuito, instalamos a placa do inversor doador no inversor do paciente. Aplicamos energia e ouvimos o som normal do eixo girando, passando por um teste de calibração com carregamento do firmware, e após alguns segundos o drive informa por meio de registros que está pronto para responder aos comandos da interface.

Caminhando pela agonia ou pela longa história de uma tentativa de recuperação de dados
Arroz. 2 indicadores DRD DSC indicam prontidão para receber comandos.

Fazemos backup de todas as cópias dos módulos de firmware. Verificamos a integridade dos módulos de firmware. Não há problemas com a leitura dos módulos, mas a análise dos relatórios mostra que existem algumas estranhezas.

Caminhando pela agonia ou pela longa história de uma tentativa de recuperação de dados
Arroz. 3. Tabela de zonas.

Prestamos atenção à tabela de distribuição zonal e notamos que o número de cilindros é 13845.

Caminhando pela agonia ou pela longa história de uma tentativa de recuperação de dados
Arroz. 4 Lista P (lista primária – lista de defeitos introduzidos durante o ciclo de produção).

Chamamos a atenção para o número muito pequeno de defeitos e sua localização. Examinamos o módulo de log de ocultação de defeitos de fábrica (60h) e descobrimos que ele está vazio e não contém uma única entrada. Com base nisso, podemos supor que em um dos centros de serviço anteriores, algumas manipulações podem ter sido feitas na área de serviço do drive, e acidentalmente ou intencionalmente um módulo estranho foi gravado, ou a lista de defeitos no original um foi limpo. Para testar essa suposição, criamos uma tarefa no Data Extractor com as opções “criar cópia setor por setor” e “criar tradutor virtual” habilitadas.

Caminhando pela agonia ou pela longa história de uma tentativa de recuperação de dados
Arroz. 5 Parâmetros de tarefa.

Depois de criada a tarefa, olhamos as entradas da tabela de partição no setor zero (LBA 0)

Caminhando pela agonia ou pela longa história de uma tentativa de recuperação de dados
Arroz. 6 Registro mestre de inicialização e tabela de partição.

No deslocamento 0x1BE existe uma única entrada (16 bytes). O tipo de sistema de arquivos na partição é NTFS, deslocado para o início dos setores 0x3F (63), tamanho da partição 0x011309A3 (18) setores.
No editor de setor, abra o LBA 63.

Caminhando pela agonia ou pela longa história de uma tentativa de recuperação de dados
Arroz. 7 setor de inicialização NTFS

De acordo com as informações do setor de boot da partição NTFS, podemos afirmar o seguinte: o tamanho do setor aceito no volume é de 512 bytes (a palavra 0x0 (0) é escrita no deslocamento 0200x512B), o número de setores no cluster é 8 (o byte 0x0 é gravado no deslocamento 0x08D), o tamanho do cluster é 512x8=4096 bytes, o primeiro registro MFT está localizado em um deslocamento de 6 setores do início do disco (em um deslocamento de 291x519 palavra quádrupla 0x30 0 00 00 00 00C 00 0 (00) número do primeiro cluster MFT. O número do setor é calculado pela fórmula: Número do cluster * número de setores no cluster + deslocamento até o início da seção 00* 786+432= 786).
Vamos passar para o setor 6.

Caminhando pela agonia ou pela longa história de uma tentativa de recuperação de dados
Fig. 8

Mas os dados contidos neste sector são completamente diferentes dos registos da MFT. Embora isto indique uma possível tradução incorreta devido a uma lista de defeitos incorreta, não prova esse fato. Para verificar ainda mais, leremos o disco em 10 setores em ambas as direções em relação a 000 setores. E então procuraremos expressões regulares no que lemos.

Caminhando pela agonia ou pela longa história de uma tentativa de recuperação de dados
Arroz. 9 Primeira gravação MFT

No setor 6 encontramos o primeiro registro MFT. Sua posição difere da calculada em 291 setores, seguindo-se continuamente um grupo de 551 registros (de 32 a 16). Vamos inserir a posição do setor 0 na tabela de turnos e avançar 15 setores.

Caminhando pela agonia ou pela longa história de uma tentativa de recuperação de dados
Fig. 10

A posição do registro nº 16 deveria estar no deslocamento 12, mas encontramos zeros lá em vez do registro MFT. Vamos realizar uma busca semelhante na área circundante.

Caminhando pela agonia ou pela longa história de uma tentativa de recuperação de dados
Arroz. 11 Entrada MFT 0x00000011 (17)

Um grande fragmento de MFT é detectado, começando com o registro número 17 com comprimento de 53 registros) com um deslocamento de 646 setores. Para a posição 17, coloque um deslocamento de +12 setores na tabela de deslocamentos.
Tendo determinado a posição dos fragmentos MFT no espaço, podemos concluir que isso não parece uma falha aleatória e gravação de fragmentos MFT em deslocamentos incorretos. Uma versão com tradutor incorreto pode ser considerada confirmada.
Para localizar ainda mais os pontos de deslocamento, definiremos o deslocamento máximo possível. Para fazer isso, determinamos o quanto o marcador final da partição NTFS (cópia do setor de inicialização) é deslocado. Na Figura 7, no deslocamento 0x28, a palavra quádrupla é o valor do tamanho da partição de 0x00 00 00 00 01 13 09 A2 (18) setores. Vamos adicionar o deslocamento da própria partição desde o início do disco ao seu comprimento e obteremos o deslocamento do marcador NTFS final 024 + 866= 18.Como esperado, a cópia necessária do setor de inicialização não estava lá. Ao pesquisar a área circundante, encontrou-se um deslocamento crescente de +024 setores em relação ao último fragmento MFT.

Caminhando pela agonia ou pela longa história de uma tentativa de recuperação de dados
Arroz. 12 Cópia do setor de inicialização NTFS

Ignoramos a outra cópia do setor de inicialização no deslocamento 18, pois não está relacionado à nossa partição. Com base nas atividades anteriores, constatou-se que dentro do trecho há inclusões de 041 setores que “apareceram” na transmissão, o que ampliou os dados.
Realizamos uma leitura completa do drive, que deixa 34 setores não lidos. Infelizmente, é impossível garantir com segurança que todos eles são defeitos removidos da lista P, mas em uma análise mais aprofundada é aconselhável levar em consideração sua posição, pois em alguns casos será possível determinar com segurança os pontos de mudança com uma precisão do setor, e não do arquivo.

Caminhando pela agonia ou pela longa história de uma tentativa de recuperação de dados
Arroz. 13 Estatísticas de leitura de disco.

Nossa próxima tarefa será estabelecer as localizações aproximadas das mudanças (com a precisão do arquivo em que ocorreram). Para fazer isso, verificaremos todos os registros MFT e construiremos cadeias de locais de arquivos (fragmentos de arquivos).

Caminhando pela agonia ou pela longa história de uma tentativa de recuperação de dados
Arroz. 14 Cadeias de localização de arquivos ou seus fragmentos.

A seguir, passando de arquivo em arquivo, procuramos o momento em que haverá outros dados em vez do cabeçalho do arquivo esperado, e o cabeçalho desejado será encontrado com um certo deslocamento positivo. E à medida que refinamos os pontos de mudança, preenchemos a tabela. O resultado do preenchimento será superior a 99% dos arquivos sem danos.

Caminhando pela agonia ou pela longa história de uma tentativa de recuperação de dados
Arroz. 15 Lista de arquivos do usuário (o consentimento foi recebido do cliente para publicar esta captura de tela)

Para estabelecer mudanças de pontos em arquivos individuais, você pode realizar trabalhos adicionais e, se conhecer a estrutura do arquivo, encontrar inclusões de dados que não estão relacionados a ele. Mas nesta tarefa não era economicamente viável.

PS Gostaria também de me dirigir aos meus colegas, em cujas mãos este disco esteve anteriormente. Tenha cuidado ao trabalhar com firmware do dispositivo e faça backup dos dados do serviço antes de alterar qualquer coisa, e não agrave deliberadamente o problema se você não conseguir concordar com o cliente sobre o trabalho.

Publicação anterior: Salvando partidas ou recuperando dados de um HDD Seagate ST3000NC002-1DY166

Fonte: habr.com

Adicionar um comentário