Curiosità su recupero dati SSD

[gpc]

nvme, 3000 mb/s
indicativamente
"Erase disk" con DiskGenius, riscrive ogni settore?
grazie

 

[Liupen]

Ma nel momento in cui il filesystem è vuoto, TRIM ha comunicato che quasi tutte (escluse le celle occupate dalle strutture base del nuovo file system, ma in talc aso sono già sovrascritte) le celle sono invalidate e non in uso, quindi a tutti gli effetti a meno di non modificare il controller o leggere direttamente le celle, sono effettivamente illeggibili e i dati sopra irrecuperabili

Ma li rende illeggibili.

Il discorso in generale sul TRIM è articolato e forse stiamo anche parlando di due cose diverse.
Tu sei sempre quello più "pratico" mentre io quello "teorico".

Cioè cosa è possibile recuperare con i software e cosa potrebbe riuscire a recuperare un centro DR?

Nel primo caso, come dici tu, TRIM elimina tutto ciò che si cancella (proprio il TRIM come comunicazione).
Infatti TRIM notifica al controller che i blocchi non sono più in uso, il controller SSD rimuove immediatamente i vari collegamenti sulla tabella o mappatura che indica quali dati sono collegati e in quale posizione sull'unità. Senza quei collegamenti i dati, non sono più leggibili.
Se fosse un HDD la precedente mappatura con i software si può recuperare ma qui parliamo di ssd, quindi sparisce proprio la mappatura attraverso una forzatura nella lettura "DZAT", "RZAT" o "DRZAT" (per i sata, ma nvme ha i corrispondenti) cioè la lettura dei blocchi cancellati con un valore predefinito dal produttore (ecco perchè per il recupero si necessita di strumenti hardware appositi che leggono il firmware del controller).

Spoiler: perchè?

Ciò succede perchè anche il gruppo di celle che costituiscono la cosiddetta Host Protect Area sono soggette a livellamento/garbage... tutto quello che succede nel resto dell'ssd.

Appunto, il fatto che la mappatura sia sparita, preclude il recupero agli strumenti software ma non hardware... ma c'è un MA.

Tieni presente quello che ho scritto, cioè che il TRIM non è un comando ma una comunicazione di dati e che è il Controller modifica ovviamente la mappatura, ma agisce sulle celle dopo un tot di tempo a seguito di quel imput con dei comandi di spostamento per prepararsi alla scrittura.
In questo lasso di tempo - tra ricezione del TRIM e esecuzione del Garbage Collection - agisce il centro di recupero dati, che modificherà come dici il controller per isolare i chip di celle nand.
Per fortuna i centri di DR in questo modo hanno una possibilità di avere successo.

Spoiler: ostacoli ulteriori al recupero

Le unità SSD con crittografia automatica richiedono un approccio completamente diverso, mentre le unità SSD che utilizzano controller di compressione non possono essere praticamente riprodotte con hardware di acquisizione off-chip.
E veniamo al 2024... come pubblicizza già Micron, il TRIM diventa obsoleto perchè nuovi algoritmi "intelligenti" permettono di mettere in relazione la tabella di mappatura e la struttura logica dell'ssd, agendo poi nel compattamento dei dati validi (quindi garbage collection) in autonomia; è un bene per gli ssd usati come device esterni, perche USB senza UASP erano privi del TRIM, con tutte le relative conseguenze, ma un TRIM interno vuol dire perdita di dati totale.

Trim (computing) - Wikipedia

en.wikipedia.org

Chris's Wiki :: blog/tech/SSDBlockDiscardHowSecure

Quello però che volevo farti notare è che, sostituendo un file system con un altro in un ssd, come scrivi anche tu, le celle su cui ha sovrascritto un os sono illeggibili (perchè riscritte) ma le altre, anche se trimmate (quindi come scrivi: le celle sono invalidate e non in uso) conserveranno il valore e saranno potenzialmente recuperabili per un DR con l'hardware giusto.

Se proprio si ha tempo e voglia, allora un bel
dd if=/dev/urandom /of=/dev/sdX bs=<SECTOR SIZE>

arrivando a portare al 100% l'occupazione di spazio del SSD, si ha certezza che ogni cella sia stata riscritta con dati random

Ma richiede un certo tempo, che normalmente reputo inutile, a meno proprio di sicurezza a livelli altissimi, in cui però già suppongo che i dati siano memorizzati criptati per cui ogni recupero non servirebbe comunque a nulla,

Sempre però meglio fare un secure erase o il corrispettivo per nvme (hdparm)

nvme, 3000 mb/s
indicativamente
"Erase disk" con DiskGenius, riscrive ogni settore?
grazie

Corrisponde al classico zero fill, una riscrittura di ogni blocco con valori random.

 

[michael chiklis]

Se per errore si vanno ad eliminare dei dati, l'operazione di trimming di solito viene eseguita molto velocemente, per cui non si ha il tempo fisico per poter recuperare i dati.
Se ci si accorge immediatamente dell'errore, c'è comunque ancora una piccola speranza di poter recuperare i dati eliminati per sbaglio.
1) E' FONDAMENTALE SPEGNERE IMMEDIATAMENTE LA SSD E NON RIACCENDERLA PIU'.
2) Tramite l'utilizzo di tool professionali per recupero dati, è possibile caricare un boot loader dopo aver mandato la ssd in modalità 'safe mode'. In tal modo viene disabilitato il firmware interno e quindi inibita la comunicazione tra controller e nand, per cui il trim non potrebbe eseguire l'azzeramento dei blocchi sulle nand. A quel punto la ditta sarà in grado di estrarre i dati e salvarli su un altro device.

Purtroppo però qualche dato andrà perso comunque perchè non è mai davvero immediato che l'utente si accorga dell'errore o semplicemente non è consapevole del fatto che la ssd andrebbe spenta subito.
Inoltre bisogna far ben presente al tecnico di recupero dati che si tratta di recuperare i dati cancellati erroneamente e che si è provveduto a spegnere subito la ssd, in tal modo lui saprà come intervenire correttamente (ovvero che NON dovrà accendere la ssd direttamente ma bensì impostarla in modalità 'safe mode' prima di dare alimentazione) e non rifiuterà il caso categoricamente (cioè non darà per scontato che i dati cancellati sono andati persi irrimediabilmente).
Un'altra cosa importante è che la SSD sia supportata nell'utility firmware del tool di recupero dati professionali, purtroppo molte ssd ancora non sono supportate (esempio i Samsung 860 e superiori), quindi non sarebbe possibile caricare il loader, quindi in questo caso i dati eliminati per sbaglio non potrebbero essere recuperati comunque.
--- i due messaggi sono stati uniti ---

Se fosse un HDD la precedente mappatura con i software si può recuperare ma qui parliamo di ssd,

Ammesso che non si tratti di un hdd SMR con inclusa la funzione di trim. In tal caso i dati vanno persi come sulle ssd, bisogna quindi procedere allo stesso modo esposto sopra per le ssd.

 

[r3dl4nce]

Teoricamente io sono d'accordo, ma continuo a vedere la necessità dei recuperi da voi descritti, con tool di alto livello e conoscenze specifiche, ben raramente necessaria nel caso più comune in cui si voglia semplicemente azzerare un ssd per, esempio, venderlo o smaltirlo.
Se poi si trattano dati di altissima sicurezza / privacy, allora dovrebbe essere usato un file system che preveda cifratura, per cui ogni recupero tirerebbe fuori solo garbage.

Molto interessanti comunque le nozioni teoriche, leggo sempre con piacere gli esperti di storage hardware

 

[Liupen]

Ammesso che non si tratti di un hdd SMR con inclusa la funzione di trim. In tal caso i dati vanno persi come sulle ssd, bisogna quindi procedere allo stesso modo esposto sopra per le ssd.

Già già... pure quelli, dimenticavo, ma per te saranno sempre più un guaio

Se poi si trattano dati di altissima sicurezza / privacy, allora dovrebbe essere usato un file system che preveda cifratura, per cui ogni recupero tirerebbe fuori solo garbage.

A livello pro, gli ssd sostituiranno gli hdd, è un fatto; però hai troppo ragione, saranno criptati sicuramente, quindi... ahi! La vedo brutta come te, lato recupero dati.

 

[r3dl4nce]

La vedo brutta come te, lato recupero dati.

Mi spiace per @michael chiklis ma io invece la vedo proprio bene, non si può pensare al recupero dati, si deve prevenire con corrette strategie di backup, quindi bene che i dati siano irrecuperabili da SSD e che chi se ne frega di attuare metodologie corrette, ci batta il capo e pure forte!

 

[michael chiklis]

Mi spiace per @michael chiklis ma io invece la vedo proprio bene, non si può pensare al recupero dati, si deve prevenire con corrette strategie di backup, quindi bene che i dati siano irrecuperabili da SSD e che chi se ne frega di attuare metodologie corrette, ci batta il capo e pure forte!

Anche chi fa i backup regolarmente si può trovare lo stesso nei guai.
Può infatti succedere che dopo aver eseguito più backup su più di un drive (magari tramite avvio programmato da software) di accorgersi dopo tanto tempo che in realtà non sono stati backuppati correttamente per svariati motivi.
L'utente magari se ne accorge soltanto dopo che il proprio drive principale si è guastato, cioè dal momento in cui viene preso in mano il disco di backup (o i dischi di backup) per fare il ripristino (o la copia) sul nuovo hdd appena acquistato.
Per questo non mi fido totalmente delle soluzioni automatiche di backup, sarebbe meglio verificare manualmente se il backup automatico è andato a buon fine, ma mi rendo conto che è una cosa che richiede tempo.
Un esempio di cosa può andar storto può essere che durante la fase di backup su un disco esterno (usb), per qualche motivo si scollega per una frazione di secondo (instabilità del disco, del pc, di alimentazione, ecc) e che quindi non ritorna più in stato ready. Il sw potrebbe non accorgersi di nulla trattandosi di un dispositivo che comunica via protocollo usb, quindi potrebbe non essere generato alcun errore da parte del sw o del os e nemmeno un messaggio sul log del programma e vedere quindi proseguire tranquillamente l'avanzamento del processo di backup come se non fosse successo nulla... ma in realtà i dati, dal momento in cui il disco esterno si era scollegato solo per un attimo, non sono più stati copiati.
Sembrerebbe tutto normale per l'utente, il sw di backup alla fine segnala "copiata completata con successo", ma in realtà non è così !!
Un altro esempio, molto più frequente, è quando si ha a che fare con unità FAKE, si crede che tutti i dati vengano backuppati e messi al sicuro e invece no, soltanto perchè l'utente non è così sgamato da riuscire a capire che l'unità su cui ha copiato i prori dati è solo un tarocco.

Puoi capire che se ci si accorge soltanto a distanza di tempo che in realtà non si ha un backup corretto, che si richieda la necessità di un intervento di recupero dati dall'unica copia che si ha, cioè dal disco che si era guastato.

E' a mio avviso un'ingiustizia non avere la possibilità di poter recuperare i propri dati; dire che rinunciare alla possibilità di recuperare i dati sia una cosa "passabile" e che l'unico modo giusto sarebbe quello della prevenzione, è un pò come dire che è meglio non ammalarsi mai (fare punturine varie come prevenzione, che poi magari non funzionano come dovrebbero e certi "esperti" dichiarano che "funzionicchiano"), perchè la cura potrebbe non essere un'opzione.
Non aggiungo altro, chi vuol capire capisca, di certe cose sapete che non si può parlare liberamente!

A mio avviso, a nessuno dovrebbe essere negata la possibilità di curarsi... o di recuperare i propri dati.

 

[r3dl4nce]

I software di backup seri fanno anche health check del backup oltre a inviare avvisi via mail o altri canali, relativi alla regolarità del funzionamento. In più un backup serio si fa su più supporti, proprio per evitare problemi in caso di guasto di un supporto di backup.
Non si deve mai ricorrere al recupero dati, non deve essere un'alternativa né una strada da percorrere, perché troppo aleatoria e con risultati incerti. Un backup fatto bene recupera sempre tutto con certezza e con costi assai minori di data recovery specialistico

 

[gpc]

Corrisponde al classico zero fill, una riscrittura di ogni blocco con valori random.

urandom e zero fill (random) di DiskGenius
a livello pratico, qual' è la differenza?

 

[Liupen]

urandom e zero fill (random) di DiskGenius
a livello pratico, qual' è la differenza?

Non conosco questo software nello specifico, ma ti posso dire che la scrittura dei blocchi puó essere fatta con dati casuali (urandom) o con dati univoci e pre impostati, come ad esempio dare a tutti i blocchi un determinato valore (tipo il valore zero).
Ai fini della cancellazione, in ambito dr di tipo forense, la casualità dei dati scritti, su hdd (cmr), complica il recupero di quei sofisticati software che rilevano le probabilità di orientamento magnetico della singola traccia.

 

[gpc]

grazie per la risposta
forse mi sono espresso male
hai indicato urandom come possibile "soluzione"
quanto tempo impiega per l' operazione?(500 gb nvme)

 

[Liupen]

Magari mi sono espresso male io generalizzando.
Zero fill sovrascrive con un identico valore predefinito che è proprio il valore zero (0x00 esadecimale) cioè svuotare in un qualche modo di dati un hdd (ssd sarebbe un altra cosa).
Solitamente i software di questo tipo utilizzano un generatore di valori random per cancellare, non so però nello specifico DiskGenius, ma sembra sia flessibile nel poter fare tutto

Tempo impiegato a sovrascrivere 500GB?
Probabilmente un nvme con cache slc arriverà quasi alla massima velocità, fino all'esaurirsi della cache, ma dipende dalle spec dell'ssd.

 

[gpc]

perfetto
indicativamente, 30 min non sono pochi (random)?
(si può con 0, 1, random o a scelta)
grazie

 

[gpc]

urandom quanto tempo impiega?
(ovviamente molto indicativamente)

 

[Liupen]

urandom quanto tempo impiega?
(ovviamente molto indicativamente)

Su che ssd?
Grande quanto?