Attraversare l'agonia o la lunga storia di un tentativo di recupero dei dati

Era il 2019. Il nostro laboratorio ha ricevuto un'unità QUANTUM FIREBALL Plus KA da 9.1 GB piuttosto insolita. Secondo il proprietario, il guasto dell'unità si era verificato nel 2004 a causa di un guasto all'alimentatore, che aveva portato con sé l'hard disk e altri componenti del PC. Successivamente, numerose officine hanno tentato di riparare l'unità e recuperare i dati, ma senza successo. Alcune promettevano una soluzione economica, ma non hanno mai risolto il problema; altre erano troppo costose e il cliente si è rifiutato di recuperare i dati. Alla fine, l'unità è stata portata in diversi centri di assistenza. È stata smarrita diverse volte, ma grazie all'impegno proattivo del proprietario nel registrare le informazioni da vari adesivi sull'unità, è riuscito a farsi restituire l'hard disk da diversi centri di assistenza. I problemi non sono passati inosservati; numerose tracce di saldatura sono rimaste sulla scheda controller originale ed era anche evidente la mancanza di elementi SMD (guardando al futuro, dirò che questo è il minore dei problemi di questa unità).

Attraversare l'agonia o la lunga storia di un tentativo di recupero dei dati
Riso. 1 HDD Quantum Fireball Plus KA 9,1GB

Il primo passo è stato cercare nell'archivio del donatore il vecchio gemello di questo drive con una scheda controller funzionante. Una volta completata questa ricerca, è stato possibile eseguire una diagnostica approfondita. Dopo aver controllato gli avvolgimenti del motore per eventuali cortocircuiti e averne verificato l'assenza, abbiamo installato la scheda del drive donatore sul drive paziente. Abbiamo alimentato e sentito il normale suono dell'albero che girava, abbiamo superato il test di calibrazione con il caricamento del firmware e, dopo pochi secondi, il drive ha segnalato tramite i suoi registri di essere pronto a rispondere ai comandi dall'interfaccia.

Attraversare l'agonia o la lunga storia di un tentativo di recupero dei dati
Fig. 2 Gli indicatori DRD DSC indicano la disponibilità ad accettare comandi.

Eseguiamo il backup di tutte le copie dei moduli firmware. Eseguiamo un controllo di integrità dei moduli firmware. Non ci sono problemi di lettura dei moduli, ma l'analisi dei report rivela alcune anomalie.

Attraversare l'agonia o la lunga storia di un tentativo di recupero dei dati
Fig. 3. Tabella delle zone.

Prestiamo attenzione alla tabella di distribuzione delle zone e notiamo che il numero di cilindri è 13845.

Attraversare l'agonia o la lunga storia di un tentativo di recupero dei dati
Fig. 4 Lista P (lista primaria – elenco dei difetti introdotti durante il ciclo produttivo).

Notiamo il numero estremamente basso di difetti e la loro posizione. Esaminiamo il registro di occultamento dei difetti di fabbrica (60 ore) e lo troviamo vuoto, senza alcuna voce. Ciò suggerisce che qualche centro di assistenza precedente potrebbe aver manomesso l'area di servizio dell'unità, sovrascrivendo accidentalmente o intenzionalmente un modulo diverso o cancellando l'elenco dei difetti dall'originale. Per verificarlo, creiamo un'attività in Data Extractor con le opzioni "crea copia settore per settore" e "crea traduttore virtuale" abilitate.

Attraversare l'agonia o la lunga storia di un tentativo di recupero dei dati
Fig. 5 Parametri dell'attività.

Dopo aver creato l'attività, esaminiamo le voci nella tabella delle partizioni nel settore zero (LBA 0)

Attraversare l'agonia o la lunga storia di un tentativo di recupero dei dati
Fig. 6 Master boot record e tabella delle partizioni.

C'è una singola voce (16 byte) all'offset 0x1BE. Il tipo di file system sulla partizione è NTFS, l'offset all'inizio è 0x3F (63) del settore e la dimensione della partizione è 0x011309A3 (18.024.867) settori.
Nell'editor di settore, aprire LBA 63.

Attraversare l'agonia o la lunga storia di un tentativo di recupero dei dati
Fig. 7 Settore di avvio NTFS

In base alle informazioni nel settore di avvio della partizione NTFS, si può affermare quanto segue: la dimensione del settore adottata nel volume è di 512 byte (la parola 0x0200 (512) è scritta all'offset 0x0B), il numero di settori in un cluster è 8 (il byte 0x08 è scritto all'offset 0x0D), la dimensione del cluster è 512x8=4096 byte, il primo record MFT si trova all'offset 6.291.519 settori dall'inizio del disco (all'offset 0x30 la parola quadrupla 0x00 00 00 00 00 0C 00 00 (786.432) è il numero del primo cluster MFT. Il numero del settore viene calcolato utilizzando la formula: numero del cluster * numero di settori in un cluster + offset all'inizio della partizione 786.432* 8+63= 6.291.519).
Passiamo al settore 6 291 519.

Attraversare l'agonia o la lunga storia di un tentativo di recupero dei dati
Fig. 8

Tuttavia, i dati contenuti in questo settore sono completamente diversi dal record MFT. Sebbene ciò indichi una possibile traduzione errata dovuta a un elenco di difetti errato, non la dimostra. Per verificarlo ulteriormente, leggeremo il disco 10.000 settori alla volta in entrambe le direzioni, relativi al settore 6.291.519. Quindi, cercheremo espressioni regolari nei dati letti.

Attraversare l'agonia o la lunga storia di un tentativo di recupero dei dati
Fig. 9 Prima registrazione MFT

Nel settore 6.291.551 troviamo il primo record MFT. La sua posizione differisce da quella calcolata di 32 settori, e segue un gruppo continuo di 16 record (da 0 a 15). Inseriamo la posizione del settore 6.291.519 nella tabella degli spostamenti, spostandola in avanti di 32 settori.

Attraversare l'agonia o la lunga storia di un tentativo di recupero dei dati
Fig. 10

Il record n. 16 dovrebbe trovarsi all'offset 12.551.431, ma troviamo degli zeri invece di un record MFT. Effettuiamo una ricerca simile nell'area circostante.

Attraversare l'agonia o la lunga storia di un tentativo di recupero dei dati
Fig. 11 Voce MFT 0x00000011 (17)

Viene rilevato un frammento MFT di grandi dimensioni, a partire dal record numero 17 (53.646 record) con un offset di 17 settori. Per la posizione 12.155.431, inseriamo un offset di +17 settori nella tabella degli offset.
Dopo aver determinato le posizioni spaziali dei frammenti MFT, possiamo concludere che non si tratta di un errore casuale o di frammenti MFT scritti con offset errati. La teoria che coinvolge un traduttore errato può essere considerata confermata.
Per localizzare ulteriormente i punti di spostamento, stabiliremo l'offset massimo possibile. Per fare ciò, determineremo lo spostamento del marcatore di fine partizione NTFS (la copia del settore di avvio). Nella Figura 7, all'offset 0x28, la parola quadrupla rappresenta il valore della dimensione della partizione: 0x00 00 00 00 01 13 09 A2 (18.024.866) settori. Sommando l'offset della partizione dall'inizio del disco alla sua lunghezza, si ottiene l'offset del marcatore di fine NTFS di 18.024.866 + 63 = 18.024.929. Come previsto, la copia del settore di avvio richiesta non è stata trovata in quel punto. Una ricerca nell'area circostante ha rivelato uno spostamento crescente di +12 settori rispetto all'ultimo frammento MFT.

Attraversare l'agonia o la lunga storia di un tentativo di recupero dei dati
Fig. 12 Copia del settore di avvio NTFS

Ignoriamo l'altra copia del settore di avvio all'offset 18.041.006, poiché non è rilevante per la nostra partizione. In base a precedenti indagini, è stato determinato che la partizione contiene inclusioni provenienti dai settori 61, "emerse" durante la traduzione, che hanno spostato i dati.
Eseguiamo una lettura completa dell'unità, che lascia 34 settori non letti. Sfortunatamente, è impossibile garantire in modo affidabile che tutti i settori siano difetti rimossi dalla P-list, ma è consigliabile considerare la loro posizione durante ulteriori analisi, poiché in alcuni casi sarà possibile determinare in modo affidabile i punti di shift con precisione a livello di settore, piuttosto che a livello di file.

Attraversare l'agonia o la lunga storia di un tentativo di recupero dei dati
Fig. 13 Statistiche di lettura del disco.

Il nostro prossimo compito è determinare la posizione approssimativa degli spostamenti (fino al file in cui si sono verificati). Per farlo, analizzeremo tutti i record MFT e costruiremo catene di posizione dei file (frammenti di file).

Attraversare l'agonia o la lunga storia di un tentativo di recupero dei dati
Fig. 14. Catene di posizioni di file o loro frammenti.

Successivamente, spostandoci da un file all'altro, cerchiamo il punto in cui l'intestazione del file prevista cambia in qualcos'altro e l'intestazione desiderata appare con un offset positivo. Man mano che affiniamo questi offset, popoliamo la tabella. Una volta popolata, oltre il 99% dei file non subirà alcun danno.

Attraversare l'agonia o la lunga storia di un tentativo di recupero dei dati
Fig. 15. Elenco dei file utente (il cliente ha dato il consenso alla pubblicazione di questo screenshot)

Per identificare spostamenti specifici nei singoli file, si potrebbe svolgere un lavoro aggiuntivo e, data la struttura del file, si potrebbero trovare inclusioni di dati non correlati al file. Tuttavia, per questo compito, questa soluzione non si è rivelata economicamente conveniente.

P.S. Vorrei rivolgermi anche ai miei colleghi che hanno già avuto a che fare con questo disco. Vi prego di prestare attenzione quando lavorate con il firmware del dispositivo e di eseguire il backup dei dati di servizio prima di apportare modifiche. Inoltre, vi prego di evitare di peggiorare intenzionalmente il problema se non siete riusciti a raggiungere un accordo con il cliente in merito al lavoro da svolgere.

Pubblicazione precedente: Salvataggio delle partite o recupero dei dati da un disco rigido Seagate ST3000NC002-1DY166 in funzione

Fonte: habr.com

Aggiungi un commento