Soffrire o la lunga storia di un tentativo di recupero dati

Eravamo nel 2019. Nella nostra laboratorio è arrivato un disco rigido QUANTUM FIREBALL Plus KA da 9.1GB, non proprio comune per i nostri tempi. Secondo il proprietario, il guasto si era verificato nel lontano 2004 a causa di un alimentatore difettoso, che aveva danneggiato il disco rigido e altri componenti del PC. Successivamente, ci sono stati vari tentativi di riparazione e recupero dei dati, senza successo. In alcuni posti promettevano un lavoro economico, ma non risolvevano il problema; in altri, il prezzo era troppo alto e il cliente aveva deciso di non procedere. Così, il disco ha passato diverso tempo in vari centri di assistenza. È stato smarrito più volte, ma grazie al fatto che il proprietario aveva annotato le informazioni sulle varie etichette del disco, è riuscito a riavere il suo disco rigido da alcuni centri. Questi passaggi hanno lasciato molte tracce di saldature sulla scheda originale del controllore e si notava anche una mancanza di elementi SMD (anticipando, dirò che questo è il minore dei problemi per questo disco rigido).

Soffrire o la lunga storia di un tentativo di recupero dati
Fig. 1 HDD Quantum Fireball Plus KA 9,1GB

Per prima cosa, è stato necessario cercare un donatore nella banca dati di dischi simili, per trovare un 'gemello' di questo disco con una scheda del controllore funzionante. Una volta completata questa ricerca, è stato possibile effettuare procedure diagnostiche dettagliate. Controllando le bobine del motore per verificare cortocircuiti, e accertandosi della loro assenza, abbiamo montato la scheda dal disco donatore al disco paziente. Colleghiamo l'alimentazione e sentiamo un normale suono di avvio, il superamento del test di calibrazione con il caricamento del firmware, e dopo pochi secondi il disco comunica di essere pronto a ricevere comandi dall'interfaccia.

Soffrire o la lunga storia di un tentativo di recupero dati
Fig. 2 Gli indicatori DRD DSC mostrano che è pronto ad accettare comandi.

Riserviamo tutte le copie dei moduli del firmware. Eseguiamo un controllo di integrità dei moduli del firmware. Non ci sono problemi nella lettura dei moduli, ma l'analisi dei rapporti mostra alcune stranezze.

Soffrire o la lunga storia di un tentativo di recupero dati
Fig. 3. Tabella delle zone.

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

Soffrire o la lunga storia di un tentativo di recupero dati
Fig. 4 P-list (lista primaria – elenco dei difetti registrati durante il ciclo di produzione).

Notiamo un numero sorprendentemente basso di difetti e la loro localizzazione. Controlliamo il modulo di log dei difetti di fabbrica (60h) e scopriamo che è vuoto e non contiene alcuna registrazione. A questo punto possiamo ipotizzare che in uno dei centri di assistenza precedenti siano state fatte manipolazioni con la zona di servizio del disco, e che per errore o intenzionalmente sia stato registrato un modulo estraneo, oppure sia stato cancellato l'elenco dei difetti originale. Per verificare questa ipotesi, creiamo un'attività nel Data Extractor attivando le opzioni "creare una copia settoriale" e "creare un traslatore virtuale".

Soffrire o la lunga storia di un tentativo di recupero dati
Fig. 5 Parametri dell'attività.

Creata l'attività, consultiamo le registrazioni nella tabella delle partizioni nel settore zero (LBA 0)

Soffrire o la lunga storia di un tentativo di recupero dati
Fig. 6 Record di avvio principale e tabella delle partizioni.

All'offset 0x1BE troviamo l'unico record (16 byte). Il tipo di file system nella partizione è NTFS, l'offset d'inizio è 0x3F (63) settori, la dimensione della partizione è 0x011309A3 (18.024.867) settori.
Nell'editor degli settori apriamo LBA 63.

Soffrire o la lunga storia di un tentativo di recupero dati
Fig. 7 Settore di avvio NTFS

Dalle informazioni nel settore di avvio NTFS della partizione possiamo dedurre: la dimensione del settore accettata nel volume è 512 byte (all'offset 0x0B è registrata la parola 0x0200 (512)), il numero di settori in un cluster è 8 (all'offset 0x0D è registrato il byte 0x08), 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 un quadruplo di parole 0x00 00 00 00 00 0C 00 00 (786.432) numero del primo cluster MFT. Il numero del settore è calcolato con la formula: numero del cluster * numero di settori nel cluster + offset d'inizio della partizione 786.432 * 8 + 63 = 6.291.519).
Passiamo al settore 6.291.519.

Soffrire o la lunga storia di un tentativo di recupero dati
Fig. 8

Ma i dati contenuti in questo settore non assomigliano affatto a un record MFT. Ciò indica che potrebbe esserci stata una traduzione errata a causa di un difetto nella lista difettosa, ma non lo dimostra. Per ulteriori verifiche procederemo a leggere il disco in entrambe le direzioni a partire da 10.000 settori rispetto al settore 6.291.519. E dopo faremo una ricerca con espressioni regolari nei dati letti.

Soffrire o la lunga storia di un tentativo di recupero dati
Fig. 9 Primo record MFT

Nel settore 6 291 551 troviamo il primo record MFT. La sua posizione rispetto a quella calcolata è diversa di 32 settori, e segue un gruppo continuo di 16 record (da 0 a 15). Aggiungeremo alla tabella degli spostamenti la posizione del settore 6 291 519 spostandolo in avanti di 32 settori.

Soffrire o la lunga storia di un tentativo di recupero dati
Fig. 10

La posizione del record n. 16 dovrebbe corrispondere allo spostamento 12 551 431, ma lì troviamo degli zeri, anziché un record MFT. Effettueremo una ricerca analoga nei dintorni.

Soffrire o la lunga storia di un tentativo di recupero dati
Fig. 11 Record MFT 0x00000011 (17)

Si trova un ampio frammento MFT, che inizia con il record numero 17 e contiene 53 646 record, con uno spostamento di 17 settori. Per la posizione 12 155 431 imposteremo uno spostamento di +17 settori nella tabella degli spostamenti.
Dopo aver determinato la posizione dei frammenti MFT nello spazio, possiamo concludere che non sembra un guasto casuale e che la registrazione dei frammenti MFT avviene con uno spostamento non corretto. La versione con traduttore non corretto può essere considerata confermata.
Per ulteriori localizzazioni dei punti di spostamento, stabiliremo lo spostamento massimo possibile. A tal fine, determineremo quanto è stato spostato il marcatore finale della partizione NTFS (copia del settore di avvio). Nell'immagine 7, allo spostamento 0x28, la parola quadrupla è il valore della dimensione della partizione 0x00 00 00 00 01 13 09 A2 (18 024 866) settori. Aggiungendo lo spostamento della partizione dall'inizio del disco alla sua lunghezza, otteniamo lo spostamento del marcatore finale NTFS 18 024 866 + 63 = 18 024 929. Ci aspettavamo che lì non ci fosse la copia necessaria del settore di avvio. Effettuando una ricerca nei dintorni, è stata trovata con uno spostamento crescente di +12 settori rispetto all'ultimo frammento MFT.

Soffrire o la lunga storia di un tentativo di recupero dati
Fig. 12 Copia del settore di avvio NTFS

Ignoriamo un'altra copia del settore di avvio allo spostamento 18 041 006, poiché non è pertinente alla nostra partizione. A seguito delle operazioni precedenti, è stato stabilito che all'interno della partizione ci sono inclusioni di 61 settori «apparentemente» presenti nella traduzione, che hanno espanso i dati.
Eseguiamo una lettura completa del dispositivo, il cui risultato mostra 34 settori non letti. Purtroppo, non possiamo garantire con certezza che tutti siano difetti rimossi dalla P-list, ma nell'analisi successiva è utile considerare la loro posizione, poiché in alcuni casi sarà possibile determinare con precisione i punti di spostamento fino al settore e non al file.

Soffrire o la lunga storia di un tentativo di recupero dati
Fig. 13 Statistiche di lettura del disco.

Il nostro prossimo compito sarà quello di determinare i luoghi approssimativi degli spostamenti (fino al file in cui si sono verificati). Per questo, scanneremo tutti i record MFT e costruiremo le catene di posizionamento dei file (frammenti di file).

Soffrire o la lunga storia di un tentativo di recupero dati
Fig. 14 Catene di posizionamento dei file, o dei loro frammenti.

Procedendo da file a file, cerchiamo a partire da quale momento, invece dell'intestazione prevista del file, ci saranno altri dati, e la necessaria intestazione verrà trovata con uno spostamento positivo. Man mano che definiamo i punti di spostamento, riempiamo la tabella. Il risultato del suo riempimento sarà oltre il 99% dei file senza danni.

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

Per stabilire spostamenti puntuali in singoli file, è possibile eseguire ulteriori lavori e, conoscendo la struttura del file, individuare inclusioni di dati non pertinenti. Tuttavia, in questo caso, non è stato economicamente conveniente.

P.S. Vorrei anche rivolgermi ai colleghi che hanno avuto questo disco in mano in precedenza. Per favore, fate attenzione quando lavorate con il firmware dei dispositivi e riservate i dati di servizio prima di fare qualsiasi modifica, e non aggravate intenzionalmente il problema se non riuscite a concordare con il cliente sull'esecuzione dei lavori.

Pubblicazione precedente: Risparmiare sui fiammiferi o recupero dati da un HDD Seagate ST3000NC002-1DY166 che scricchiola

Fonte: habr.com

Acquista hosting affidabile per siti web con protezione DDoS, server VPS VDS 🔥 Acquista hosting affidabile per siti web con protezione DDoS, server VPS VDS | ProHoster