Se pensate che una password non sia sufficiente per proteggere un file importante o volete salvarlo nel cloud senza dover ricordare una password, ma nemmeno lasciandolo in chiaro, allora potete ricorrere al semplice programma che vi suggeriremo e a un breve script PowerShell per manipolare la "genetica del file". Il “genoma” di ogni file è fatto di bit, che nella loro semplice binarietà rendono possibili le molteplici "combinazioni genetiche" che denotano in modo peculiare e unico ogni file. Il “microscopio” per analizzare i bit è uno strumento imprescindibile per le analisi di digital forensics e solitamente viene indicato come "hex editor", ossia editor esadecimale, con chiaro riferimento alla codifica esadecimale solitamente utilizzata per leggere i byte. [continua..]
Inserite di seguito i vostri commenti.
Ultima modifica di Zigul il mer dic 13, 2023 9:35 pm, modificato 7 volte in totale.
Fossi in te, utilizzarei l'apposito tag Titolo (la A rossa) per evidenziare ulteriormente i titoli dei capitoli al posto del doppio tag Grasseto più Corsivo.
In merito poi a questo paragrafo:
Semmai ve lo steste chiedendo, non è possibile aprire correttamente il primo frammento, anche se esso contiene l’header (i metadati posti nei primi byte del file) per intero, essendo solitamente necessario, per l’integrità e la leggibilità del file, anche il trailer (i metadati posti negli ultimi byte del file), che rende il file perfettamente gestibile dal programma associato (l’unica eccezione è se si tratta di un file del "Blocco note" o eventuali altri formati parimenti privi di header e trailer; in questo caso ciascun frammento resta perfettamente autonomo e leggibile singolarmente).
Non sarei così sicuro che il primo frammento non si possa aprire anche per file con header e trailer.
Esistono alcuni programmi (il primo che mi viene in mente untrunc per alcuni formati video) con cui si potrebbe rendere leggibile il primo frammento.
Se avessi tempo, poi, mi piacerebbe fare una prova: cosa succede se cancello la tabella delle partizioni del disco dove sono contenuti i file troncati e lo faccio analizzare da PhotoRec?
Lo hai già riportato, ma io chiarirei ulteriormente che questo sistema non deve essere utilizzato come unico metodo per mettere in sicurezza i propri file!
Per il resto, bravo Zigul!!
"Let me tell you a secret: when you hear that the machine is “smart”, what it actually means is that it’s exploitable." Mikko Hypponen
@CUB3
Per i titoli mi piaceva l'idea di poter differenziare le parole in inglese e in latino usando il corsivo; comunque nel prossimo articolo proverò sicuramente l'impostazione apposita che mi hai consigliato.
Riguardo header e trailer: ne ho parlato inevitabilmente molto in generale; sicuramente per alcuni tipi di file è più agevole ricostruire i metadati mancanti e renderli di nuovo leggibili, o almeno recuperare una parte del contenuto. Tuttavia se i bit sono stati, come ho suggerito, anche "shiftati" usando lo script che ho proposto, allora non si tratta più di ricostruire header e trailer (che di fatto ci sono, ma alterati) e l'individuazione del payload potrebbe non essere altrettanto automatizzabile tramite programmi.
Su PhotoRec (l'ho usato solo un paio di volte) e il recupero dati: credo si potrebbe aver successo nel ripristinare il file unico cancellato dopo averlo frammentato, ma per quanto riguarda i file-frammento prodotti da HxD, questi dovrebbero risultare file autonomi ed indipendenti, senza alcun legame fra loro. L'essere umano sa che sono derivati dal medesimo file, ma non sono certo PhotoRec o altri programmi siano in grado di "capirlo" solo notando come l'header dell'uno sia compatibile con il trailer dell'altro (potrebbero anche essere due frammenti di due file differenti). Inoltre, se non sbaglio, i due file creati da HxD dovrebbero avere due GUID differenti e questo potrebbe prevenirne il "recupero associativo"; ma non conosco abbastanza questo campo per sbilanciarmi troppo.
Sulla sicurezza: raccolgo volentieri il tuo invito e ribadisco che frammentare un file in più "file-frammento", per poi alterare i bit che lo costituiscono, non è affatto un metodo che sostituisce quelli più collaudati e ben più efficaci: la prima regola per la difesa dei dati è sempre quella di cifrarli e proteggerli con adeguata password (ferma restando l'importanza del backup). Dividere, solo in seguito, il file sorgente cifrato in due o più file-frammento serve ad aumentare i potenziali bersagli da colpire, riducendo così il rischio di compromissione totale: se ho un file-frammento nel "Cloud A" e un altro nel "Cloud B", in caso di data breach (o altro spiacevole evento) in uno dei due, non sarà l'intero file originale ad essere compromesso, ma solo una sua parte (fra l'altro difficilmente leggibile). Così come se ho due file-frammento, uno su una periferica USB e l'altro nel PC, posso essere relativamente sicuro che, in caso di esfiltrazione dei dati dal mio host, il file-frammento sulla USB dovrebbe scongiurare la perdita totale delle informazioni contenute nel file originale. Certo, in entrambi i casi ho una perdita di dati, ma almeno chi se ne impossessa non li ha facilmente ricostruibili e in ogni caso sempre parziali.
Lo shift dei bit invece serve perlopiù a confondere ulteriormente le acque, già doverosamente "intorbidate" dalla crittografia: se un file, frammentato o meno che sia, oltre ad essere cifrato, ha anche i bit shiftati, è solo un po' più difficile da decifrare. In un certo senso, shiftare i bit è un po' come aggiungere "123!" ad una password: se la password è debole, non sarà certo quell'aggiunta a renderla forte; se invece è già forte, quell'aggiunta la renderà ancora più forte (se non altro perché aumenta le combinazioni da testare in caso di "brute force" e, in caso di "attacco dizionario", la password originale potrebbe non essere stata inserita con quel suffisso; se si è davvero molto fortunati).
Bel lavoro, complimenti!
Leggendo l'articolo mi sono ricordato di HxD che usai per manipolare il settore di avvio di un disco che non era più avviabile, ma si tratta di tantissimi anni fa.
Ho fatto qualche ricerca ed è venuto fuori un articolo del vecchio sito: http://www.megalab.it/7049/
Zigul ha scritto: ↑dom dic 10, 2023 9:40 pm
Su PhotoRec (l'ho usato solo un paio di volte) e il recupero dati: credo si potrebbe aver successo nel ripristinare il file unico cancellato dopo averlo frammentato, ma per quanto riguarda i file-frammento prodotti da HxD, questi dovrebbero risultare file autonomi ed indipendenti, senza alcun legame fra loro.
Ero curioso così ho fatto una prova con qualche semplice file: un mp4, un jpg, un pdf e un doc.
PhotoRec ha ricostruito perfettamente i file splittati con HxD (oltre a trovare centinaia di altri file ) senza nemmeno dover cancellare la tabella delle partizioni.
Nell'immagine sotto: in basso a sinistra i file originali, in alto a sinistra i file ricomposti e in basso a destra i pezzi dei file.
Senza nulla togliere al tuo ottimo lavoro, tornando a questo paragrafo:
Semmai ve lo steste chiedendo, non è possibile aprire correttamente il primo frammento, anche se esso contiene l’header...
Io non sarei così categorico o almeno lo modificherei in "non è possibile aprire direttamente il primo frammento".
"Let me tell you a secret: when you hear that the machine is “smart”, what it actually means is that it’s exploitable." Mikko Hypponen
Grazie per aver fatto pazientemente il test. Quello che intendevo è semplicemente che se divido un file .pdf in due frammenti, il primo frammento, pur contenendo l'header, non può essere aperto "correttamente" come un qualunque .pdf per leggerne il contenuto. Per questo se qualcuno ne entra in possesso, senza avere anche il secondo file, non è sempre facile riuscire a recuperarne i dati (come giustamente hai osservato, per alcuni tipi di file può essere più facile che per altri). Quindi ti chiedo per conferma: con PhotoRec sei riuscito a ricostruire il file .pdf originale partendo dai frammenti, praticamente riabbinando i due file-frammento (come fa HxD), o hai recuperato ciascun frammento che tuttavia resta illeggibile individualmente come .pdf? Se mi confermi che PhotoRec ha anche questa funzione, modifico l'articolo facendo l'esempio del .pdf.
Zigul ha scritto: ↑lun dic 11, 2023 11:36 am
con PhotoRec sei riuscito a ricostruire il file .pdf originale partendo dai frammenti, praticamente riabbinando i due file-frammento (come fa HxD), o hai recuperato ciascun frammento che tuttavia resta illeggibile individualmente come .pdf? Se mi confermi che PhotoRec ha anche questa funzione, modifico l'articolo facendo l'esempio del .pdf.
No, PhotoRec non crea due pdf leggibili dai due frammenti ma genera un solo pdf trovando da solo i frammenti giusti da abbinare.
Tuttavia, per rimanere nell'esempio dei pdf (ma lo stesso può valere anche per molti altri tipi di file), è possibile recuperare la prima parte di un pdf con Ghostscript, mupdf o anche con un servizio online come questo; il risultato ovviamente può variare in base alla grandezza del pdf e del file frammento.
Comunque io la chiudo qui, se pensi di essere stato sufficientemente chiaro nel punto che ti ho indicato, va benissimo così, si vede che lo interpreto in maniera ambigua solo io
Chiudo rinnovando i complimenti per l'articolo!
"Let me tell you a secret: when you hear that the machine is “smart”, what it actually means is that it’s exploitable." Mikko Hypponen
La tua segnalazione è molto interessante, non m'aspettavo PhotoRec potesse farlo. Forse andrebbe testata qual è la percentuale di successo quando i frammenti derivano da più file d'origine dello stesso tipo, sebbene a questo punto suppongo sia in grado di ricavare le giuste informazioni dai metadati e dunque ritrovare lo stesso i giusti abbinamenti. Comunque modifico volentieri l'articolo aggiungendo queste utili informazioni. Grazie.
Ciao zigul, ottimo articolo. Ti chiedo solo di impostare i titoli dei paragrafi con la formattazione dedicata (Titolo) invece di metterli in grassetto. Grazie!
Inserendo un messaggio, dichiari di aver letto e accettato il regolamento di partecipazione.
Nello specifico, sei consapevole che ti stai assumendo personalmente la totale responsabilità delle tue affermazioni, anche in sede civile e/o penale,
manlevando i gestori di questo sito da ogni coinvolgimento e/o pretesa di rivalsa.
Dichiari inoltre di essere consapevole che il messaggio sarà visibile pubblicamente, accetti di diffonderlo con licenza
CC BY-NC-SA 3.0 (con attribuzione a "TurboLab.it") e rinunci ad ogni forma di compensazione (economica o altro).
Rinunci inoltre esplicitamente a qualsiasi pretesa di cancellazione del messaggio.
Re: Commenti a "Come manipolare il "DNA" dei file"
Sasha
così ho fatto una prova con qualche semplice file: un mp4, un jpg, un pdf e un doc.
) senza nemmeno dover cancellare la tabella delle partizioni.
