Quote:
Originariamente inviato da demon77
mmm.. non so.. però mi sembra strano.
Non credo proprio debbano aprire il file, alla fine un file, che sia protetto da pasword o meno è solo un pacchetto di dati.
Il cryptoloker lo prende lo legge in modalità "raw" e lo ricodifica secondo un algoritmo di criptazione.. non ha nessun bisogno di sapere di che tipo sia il file..
Anche perchè al di là dei formati più standard tipo office o immagini vengono criptati anche files con formati proprietari di software più specifici.
Per dire.. anche con 7zip posso comprimere e criptare files di qualsiasi tipo senza alcun vincolo e anche se non ho il programma per leggerli
|
No, è molto molto molto più complesso di quanto immagini leggere i file su disco in modalità raw (cioè ignorando il tipo di file system).
Con l'NTFS ti assicuro che una marea di file non sono scritti in maniera sequenziale su disco.
Ti faccio un esempio con i software di recupero: mettiamo caso hai la tabella delle partizioni completamente sfanculata, e non si riesce proprio a riconoscere il file system...indovina un pò? Recuperi solo file relativamente piccoli, solo quando sono scritti in maniera sequenziale!
Stai recuperando un JPEG da 100kb (che si riconosce dall'header facilmente), e magari al 70kb hai una discontinuità (ci sono vari motivi per cui può accadere), quando vai ad aprirlo vedrai metà JPEG corrotto o decodificato male (magari in mezzo ci trovi un'altro file da 2kb che rompe i maroni e che il software di recupero non è riuscito ad analizzare perchè è un fottuto documento di testo utf8 con scritto "caccapupu").
Quando ti dice culo e recuperi pezzi grossi, è perchè le tabelle non sono completamente danneggiate.
Quindi se vuoi leggere un file in maniera corretta e completa hai solo due vie:
usi le API di deframmentazione (come fa SDelete ad esempio), o apri il file con le stracomunissime API di Windows quali CreateFile/Ex ReadFile/Ex...te conviene! Poi lo crypti come vuoi, con le API di Windows (tanto sti cryptocosi quelle usano), e poi cancelli l'originale in stile SDelete. Io farei così almeno, anche perchè credo che con una eventuale WriteFile per sovrascrivere lo stesso file, ma con dati cifrati, (anche se della stessa lunghezza la probabilità cala di molto), si ha sempre una minima possibilità di trovare il driver I/O incazzato che ti spiattella i dati a distanza siderale, lasciando parzialmente i vecchi scritto su disco nella vecchia posizione).