Era il 2019. Nella nostra laboratorio è arrivato un'unità di memoria QUANTUM FIREBALL Plus KA di 9,1 GB, piuttosto insolita per il nostro tempo. Secondo il proprietario, il guasto è avvenuto nel lontano 2004 a causa di un'unità di alimentazione difettosa, che ha portato anche al malfunzionamento del disco rigido e di altri componenti del PC. Successivamente ci sono stati tentativi di riparare l'unità e recuperare i dati in diversi centri di assistenza, senza successo. In alcuni luoghi promettevano prezzi bassi, ma non risolvevano il problema; in altri i costi erano troppo elevati e il cliente ha scelto di non procedere con il recupero dei dati. Alla fine, il disco ha attraversato innumerevoli centri di assistenza. È stato perso più volte, ma grazie al fatto che il proprietario ha provveduto a registrare le informazioni dalle varie etichette sull'unità, è riuscito a far recuperare il proprio disco rigido da alcuni centri di assistenza. Le peripezie non sono state senza traccia; sulla scheda originale del controller sono rimasti numerosi segni di saldatura e si avvertiva visivamente una carenza di componenti SMD (anticipando, dirò che questo è il minor problema di questa unità).
Fig. 1 HDD Quantum Fireball Plus KA 9,1 GB
Per prima cosa, è stato necessario cercare un gemello donatore così antico con una scheda del controller funzionante. Una volta completata questa missione, è stato possibile eseguire attività diagnostiche approfondite. Dopo aver verificato le bobine del motore per cortocircuiti e aver confermato che non ce ne fossero, installiamo la scheda dall'unità donatrice sull'unità paziente. Forniamo alimentazione e sentiamo un normale suono di rotazione dell'albero, completando il test di calibrazione con il caricamento del firmware, e dopo qualche secondo l'unità rapporta la sua prontezza a rispondere ai comandi dell'interfaccia.
Fig. 2 Le spie DRD DSC indicano prontezza ad accettare comandi.
Riserviamo tutte le copie dei moduli del firmware. Eseguiamo un controllo dell'integrità dei moduli del firmware. Non ci sono problemi nella lettura dei moduli, ma l'analisi dei rapporti mostra alcune stranezze.
Fig. 3. Tabella delle zone.
Prestate attenzione alla tabella di distribuzione delle zone, notiamo che il numero di cilindri è 13845.
Fig. 4 P-list (elenco primario – elenco dei difetti registrati durante il ciclo di produzione).
Attiriamo l'attenzione sul numero eccessivamente ridotto di difetti e sulla loro localizzazione. Esaminiamo il modulo di registrazione degli errori di fabbrica (60h) e scopriamo che è vuoto e non contiene alcuna registrazione. Sulla base di ciò, possiamo supporre che in uno dei precedenti centri di servizio siano state effettuate delle manipolazioni nell'area di servizio del disco, e che accidentalmente o intenzionalmente sia stato registrato un modulo di terzi, oppure sia stata pulita la lista dei difetti nell'originale. Per verificare questa ipotesi, creiamo un'attività in Data Extractor con le opzioni attivate "creazione di una copia settoriale" e "creazione di un traduttore virtuale".
Fig. 5 Parametri dell'attività.
Dopo aver creato l'attività, esaminiamo le registrazioni nella tabella delle partizioni nel settore zero (LBA 0).
Fig. 6 Principal Record di avvio e tabella delle partizioni.
Allo spostamento 0x1BE si trova l'unica registrazione (16 byte). Il tipo di file system nella partizione è NTFS, spostamento all'inizio 0x3F (63) settori, dimensione della partizione 0x011309A3 (18 024 867) settori.
Nell'editor di settori apriamo LBA 63.
Fig. 7 Settore di avvio NTFS.
Dalle informazioni nel settore di avvio NTFS della partizione possiamo affermare quanto segue: la dimensione del settore accettata nel volume è di 512 byte (allo spostamento 0x0B è registrata la parola 0x0200 (512)), il numero di settori nel cluster è 8 (allo spostamento 0x0D è registrato il byte 0x08), la dimensione del cluster è 512×8=4096 byte, la prima registrazione MFT si trova allo spostamento 6 291 519 settori dall'inizio del disco (allo spostamento 0x30 la parola quadrupla 0x00 00 00 00 00 0C 00 00 (786 432) è il numero del primo cluster MFT. Il numero di settore viene calcolato con la formula: Numero del cluster * numero di settori nel cluster + spostamento all'inizio della partizione 786 432 * 8 + 63 = 6 291 519).
Passiamo al settore 6 291 519.
Fig. 8
Ma i dati contenuti in questo settore non assomigliano affatto a una registrazione MFT. Questo indica una possibile errata traduzione a causa di una lista difetti non corretta, ma non dimostra questo fatto. Per ulteriori verifiche, eseguiremo la lettura del disco in entrambe le direzioni ogni 10 000 settori rispetto al settore 6 291 519. Poi eseguiremo la ricerca di espressioni regolari nei dati letti.
Fig. 9 Prima registrazione MFT
Nel settore 6 291 551 scopriamo la prima registrazione MFT. La sua posizione differisce da quella calcolata di 32 settori, e segue quindi un gruppo continuo di 16 registrazioni (da 0 a 15). Inseriamo nella tabella dei movimenti la posizione del settore 6 291 519 spostandolo in avanti di 32 settori.
Fig. 10
La posizione della registrazione n. 16 dovrebbe essere allo spostamento 12 551 431, ma lì troviamo degli zeri, invece della registrazione MFT. Effettueremo una ricerca simile nelle vicinanze.
Fig. 11 Registrazione MFT 0x00000011 (17)
Si scopre un grande frammento di MFT, che inizia con la registrazione numero 17 e ha una lunghezza di 53 646 registrazioni) con uno spostamento di 17 settori. Per la posizione 12 155 431 impostiamo uno spostamento di +17 settori nella tabella degli spostamenti.
Determinando la posizione dei frammenti MFT nello spazio, possiamo concludere che non sembra un guasto casuale e che i frammenti MFT sono stati registrati con spostamenti errati. L'ipotesi dell'errato traslatore può essere considerata confermata.
Per la futura localizzazione dei punti di spostamento, stabiliremo lo spostamento massimo possibile. Per questo, determiniamo quanto è spostato il marker finale della partizione NTFS (copia del settore di avvio). Nella figura 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 finale del marker NTFS 18 024 866 + 63= 18 024 929. Come previsto, non c'era la copia richiesta del settore di avvio. Effettuando la ricerca nelle vicinanze, è stata trovata con uno spostamento crescente di +12 settori rispetto all'ultimo frammento MFT.
Fig. 12 Copia del settore di avvio NTFS
Ignoriamo un'altra copia del settore di avvio con spostamento 18 041 006, poiché non è correlata alla nostra partizione. Sulla base delle attività precedenti è stato stabilito che all'interno della partizione ci sono inserimenti di 61 settori "emersi" nella traslazione, che hanno separato i dati.
Effettuiamo una lettura completa del supporto, il cui risultato è di 34 settori non letti. Sfortunatamente, non è possibile garantire con certezza che tutti siano difetti rimossi dalla P-list, ma nell'analisi successiva è preferibile tenere in considerazione la loro posizione, poiché in alcuni casi sarà possibile determinare accuratamente i punti di spostamento con precisione di settore, e non di file.
Fig. 13 Statistiche di lettura del disco.
La nostra prossima task sarà stabilire i punti di spostamento indicativi (con precisione al file in cui sono avvenuti). A tal fine, effettueremo una scansione di tutte le voci MFT e creeremo catene di posizionamento dei file (frammenti di file).
Figura 14 Catene di posizionamento dei file o dei loro frammenti.
In seguito, spostandoci da file a file, cerchiamo in quale punto invece dell'intestazione prevista del file ci saranno dati diversi, mentre l'intestazione necessaria verrà scoperta con uno spostamento positivo. E man mano che definiamo i punti di spostamento, completiamo la tabella. Il risultato della sua compilazione sarà oltre il 99% dei file senza danni.
Figura 15 Elenco dei file utente (è stata ricevuta l'autorizzazione dal cliente per pubblicare questo screenshot)
Per stabilire spostamenti puntuali in file singoli, si possono eseguire lavori supplementari e, conoscendo la struttura del file, identificare iniezioni di dati non pertinenti. Ma in questo compito non era economicamente fattibile.
P.S. Vorrei anche rivolgermi ai colleghi che hanno avuto questo disco tra le mani in precedenza. Per favore, siate cauti quando lavorate con il firmware dei dispositivi e fate un backup dei dati di servizio prima di apportare modifiche, oltre a non aggravare intenzionalmente il problema se non siete riusciti a concordare con il cliente l'esecuzione dei lavori.
Fonte: habr.com
