Όπως όλοι γνωρίζουμε (κι όσοι δεν γνωρίζουν είναι ευκαιρία να το μάθουν) οτι στο λειτουργικό σύστημα Windows (γενικώς) δεν υπάρχει πραγματική διαγραφή αρχείων. Θα μου πείτε τώρα "Μα φυσικά! Αφού τα αρχεία πηγαίνουν στον κάδο ανακύκλωσης και μπορείς να τα επαναφέρεις ανά πάσα στιγμή..."
Χμ... σωστά, αλλά δεν μιλώ όμως για αυτήν την διαγραφή. Αυτό που λεω είναι οτι, ακόμα κι αν τα διαγράψεις από τον κάδο ανακύκλωσης, αυτά παραμένουν στον δίσκο μέχρι να ξαναγραφτούν (από πάνω) από κάποιο άλλο αρχείο. Αλλά ακόμα κι αν ξαναγραφτούν από πάνω.... πάλι!! μπορείς να τα επαναφέρεις κάνοντας χρήση ειδικών προγραμμάτων ανάκτησης δεδομένων. Κατά την διαγραφή, αυτό που στην πραγματικότητα διαγράφεται είναι η καταχώρηση (είτε στο FAT ή είτε στο NTFS) από τον πίνακα περιεχομένων (να το πω χοντρικά) που έχει κάθε δίσκος για να ξέρει τι αρχεία είναι καταχωρημένα σε αυτόν.

Αυτά καθαυτά τα δεδομένα του διαγραμένου αρχείου παραμένουν αναλοίωτα, αλλά δεν "προστατεύονται" πια από το λειτουργικό σύστημα και μπορεί ανά πάσα στιγμή ο χώρος που καταλαμβάνουν, να δωθεί σε κάποιο άλλο αρχείο.
Εδώ όμως κάπου έρχεται να μας ενοχλήσει (άλλους λίγο, άλλους πολύ) ένα πρόβλημα εμπιστευτικότητας...

Όπως όλοι γνωρίζουμε (κι όσοι δεν γνωρίζουν είναι ευκαιρία να το μάθουν - το είπαμε αυτό, έλεος!!) η εμπιστευτικότητα (ή κατά το ελληνικότερον Confidentiality) είναι ένας από τους βασικούς συντελεστές της ασφάλειας. Σημαίνει με λίγα λόγια οτι κάτι το οποίο αφορά εμένα και δεν θέλω να το δει κάποιος άλλος, τότε δεν θα μπορεί το δει!
Δηστυχώς όμως, τα θέμα με τα διεγραμμένα αρχεία είναι οτι μπορεί να παραβιαστεί η εμπιστευτικότητα τους αν και μόνο αν σβήσω ένα αρχείο το οποίο δεν θα ήθελα να δει κανένας και μετά κάποιος πονηρός αποκτήσει πρόσβαση στο δίσκο μου (με το ζόρι ή... χωρίς) και αρχίσει την... ψαχούλα! Με ειδικά εργαλεία μπορεί να επαναφέρει αρχεία (ακόμα κι αν έχουν ξαναγραφτεί από πάνω ή ακόμα και από προηγούμενα formats!!) τα οποία εγώ τα θεωρώ ιδιωτικά, τα έχω διαγράψει και δεν θέλω να τα δει ούτε να τα επαναφέρει κανείς.
Λύση έχω...?
Ναι έχω!
 Υπάρχουν αρκετά προγράμματα που κυκλοφορούν και κάνουν πραγματική διαγραφή των αρχείων, γράφοντας απ΄πάνω δεκάδες φορές άσχετους χαρακτήρες είτε blanks ώστε να μην είναι δυνατή η επαναφορά τους από κάποιο ειδικό εργαλείο. Έχει οριστεί οτι ο μέγιστος αριθμός ξαναγραψίματος που μπορείς να θεωρείσαι ασφαλής, οτι δηλαδή δεν θα μπορέσει κανένα tool να επανακτήσει το αρχείο σου, είναι 35. Δηστυχώς όμως τα περισσότερα προγράμματα που κάνουν πραγματικό deletion έχουν αρκετά μειονεκτήματα:

• Μερικά είναι πολύ αργά.
• Άλλα δεν διαγράφουν ούτε αλλάζουν το όνομα του αρχείου από το FAT/NTFS.
• Άλλα επαναγράφουν το αρχείο μία ή δύο μόνο φορές.
• Άλλα επαναγράφουν το αρχείο μόνο με blanks και δεν σου δίνουν την δυνατότητα να ορίσεις εσύ τον χαρακτήρα που θα χρησιμοποιηθεί στην διαδικασία re-write.

Παίρνοντας την αφορμή αυτό το post, είπα να μοιραστώ μαζί σας ένα πρόγραμμα που έχω γράψει για πραγματική διαγραφή αρχείων, στο οποίο προσπάθησα να ξεπεράσω τους παραπάνω περιορισμούς. Το πρόγραμμα το έγραψα σε C# σε .net 3.5 κάνοντας χρήση του δωρεάν πακέτου Express της microsoft.
Το βαπτισα FileKiller. Είναι πλέον σε GNU general public license, ανοιχτό κώδικα (φυσικά) και κάλιστα μπορείτε να το πάρετε και το χρησιμοποιήσετε ή να το ενισχύσετε με δικά σας χαρακτηριστικά.
Βρίσκεται εδω: http://sourceforge.net/projects/filekiller/

Είχε μάλιστα την τιμή να ελεχθεί, να βραβευτεί και να οριστεί σαν γνήσιο Windows Tool με το Softpedia 100% Free Award.

Θεωρώ οτι το πρόγραμμα έχει τα εξής χαρακτηριστικά που δεν τα βρίσκεις συχνά σε αντίστοιχα προγράμματα:
1. Είναι πάρα πολύ γρήγορο.
2. Μπορείς να καθορίσεις πόσα iteration (1 έως 100) θα κάνει το πρόγραμμα κατά την διαγραφή του αρχείου.
3. Μπορείς να καθορίσεις αν κατά την διαγραφή το αρχείο θα γραφτεί με κενά ή με τυχαίους χαρακτήρες ή με κάποιον χαρακτήρα επιλεγμένο από τον χρήστη.
4. Μπορείς να επιλέξεις ταυτόχρονα πολλά αρχεία για διαγραφή από διαφορετικά directories ή δίσκους.
5. Αν κατά την διαγραφή βρεθούν κάποια αρχεία κλειδωμένα ή αρχεία συστήματος που δεν επιτρέπεται να διαγραφούν, τότε το πρόγραμμα διαγράφει μόνο αυτά που μπορεί, αφήνοντας τα άλλα στη θέση τους.
6. Διαγράφει όχι μόνο τα περιεχόμενα ενός αρχείου αλλά αλλοιώνει και το πραγματικό του όνομα στο FAT/NTFS, κάνοντας την ανάκτηση του (ακόμα και με ειδικά εργαλεία) θεωρητικά αδύνατη. Εγώ, τουλάχιστον, όσα γνωστά εργαλεία ανάκτησης δοκίμασα, απέτυχαν όλα.
7. Δεν χρειάζεται setup, κατεβάστε απλά το executable και τρέξτε το (αρκεί να έχετε .net 3.5).

Θα ήταν χαρά μου και τιμή μαζί, να συμμετέχουν κι άλλοι programmers στο μικρό αυτό project-άκι και να διορθώσουν κάποια bugs (αν έχει... που θα έχει δλδ) ή να του προσδώσουν κι άλλα χαρακτηριστικά σεβόμενοι πάντα την GNU License.


Σας ευχαριστώ

---

Nothing to declare...

Ενδιαφέρον utility, έχω μία ερώτηση και μερικές παρατηρήσεις:

Γνωστό και κατανοητό το ότι το απλό delete ουσιαστικά αφαιρεί απλά το entry από το FAT/NTFS αφήνοντας τα πραγματικά data κάπου στο δίσκο. Αυτό που το έχω ακούσει πολλές φορές και ποτέ δεν έχω καταλάβει, είναι αυτό που λες για τις 35 φορές rewrite που χρειάζεται για να μην μπορεί να ανακτηθεί η πληροφορία. Τι διαφορά έχει η μία φορά rewrite σε σχέση με τις 35; Ψηφιακό μέσο δεν είναι; 0 και 1; Άπαξ και γράψεις πάνω στον δίσκο ένα bit τι διαφορά έχει αν ξαναγράψεις από πάνω άλλες 34 φορές; Και ποιά προγράμματα παρέχουν recovery για rewrite έστω και μίας φοράς;

Τώρα, ως το πρόγραμμα αυτό καθ' αυτό, μερικές βελτιώσεις που θα μπορούσες να υλοποιήσεις είναι:

• Να δουλεύει με συνδυασμό FileStream και StreamWriter. Εφόσον αυτά που θα γράψεις δεν εξαρτώνται από αυτά που θα διαβάσεις, δεν χρειάζεται να διαβάζεις ολόκληρο το περιεχόμενο στη μνήμη όπως κάνεις τώρα (File.ReadAllBytes) απλά και μόνο για να το ξαναγράψεις πίσω στο αρχείο.
• H διαδικασία να γίνεται σε background thread ώστε να μην παγώνει το UI και να παρέχεις στον χρήστη ενημέρωση για την πρόοδο της διαδικασίας. Εφόσον γνωρίζεις το μέγεθος του αρχείου, είναι πολύ εύκολο.

 

---

Vir prudens non contra ventum mingit

Μάνο, εφόσον δεν γράψεις πολλές φορές απο επάνω, υπάρχει ακόμα τρόπος να το ανακτήσεις. Προγράμματα όπως το FileScavenger μπορούν άνετα να ανακτήσουν δεδομένα ακόμα και μετά απο πολλάπλα overwrite ή ολοκληρωτικό format (όχι quick). Αυτό γίνεται γιατί πλέον scanarei Sector sector απο μόνο του και δεν βασίζεται σε shadow files του ntfs για καταλάβει το structure του δίσκου. Γενικά προγράμματα τα οποία έχουν δικούς τους drivers και scanaroyn sectors μπορούν να ανακτήσουν δεδομένα ακόμα και μετά απο μερικά deletes. Επίσης μην ξεχνάς ότι ακόμα κι εάν κάνεις overwrite η μαγνητική "Υπογραφή" υπάρχει ακόμα και με ειδικά εργαλεία κάποιος θα μπορούσε να το διαβάσει. Ο μόνος τρόπος για να το καταστρέψεις εντελώς είναι τα πολλαπλά overwrite με garbage data (read λίγο πιο κάτω).

Μάλιστα οι Αμερικάνοι και το πεντάγωνο έχουν ειδικούς αλγορίθμους και διαδικασίες διαγραφής αρχείων απο δίσκους οι οποίες ανάλογα με το confidentiality των δεδομένων, έχουν αντίστοιχα overwrite όχι απλά με μηδενικά bytes ή απλά garbage δεδομένα, αλλά με 64-128 ή 256 bit keys random δεδομένων τα οποία γράφουν. Ένα εργαλείο που υλοποιεί αυτά και τα χρησιμοποιεί είναι το BCWipe και χρησιμοποιείτε κι απο το Πεντάγωνο όπως λένε. Να μην μιλήσω για περιπτώσεις όπου μετά απο αυτά τα τους καίνε κιολας σε καμίνια (rumors) 

---

Παναγιώτης Κεφαλίδης

"Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.

Βασικά, αυτό που με ενδιαφέρει είναι η πιθανότητα και η ευκολία που μπορεί να γίνει η ανάκτηση.

Όταν ακούω εκφράσεις όπως "ειδικά εργαλεία", "ειδικά προγράμματα", "υπάρχει η δυνατότητα", αυτομάτως - χωρίς να αμφισβητώ την αξίωση - για μένα το θέμα κατατάσεται ως σενάριο out of my league, ως κάτι που δεν πρόκειται να λάβω υπόψην. Δηλαδή δεν ισχύει το "reasonable countermeasures for reasonable protection against reasonable attacks". Και πιστεύω ότι γενικότερα σε άρθρα περί security αυτό είναι που πρέπει ο συγγραφέας να προβάλει. Έχουμε πει, "ό,τι κλειδώνει - ξεκλειδώνει", οπότε δεν είναι νέο για μένα να μου πεις απλά ότι "έτσι σπάει το Χ". Αυτό που θέλω να ακούσω είναι πόσο εύκολα, πόσα resources χρειάζεται ο εισβολέας και πόσο θα μου κοστίσει να το προστατεύσω.

 

---

Vir prudens non contra ventum mingit

Περιμένοντας να ξεκινήσει το Big Bang Theory είπα να ψάξω λίγο το θέμα με τα 35 overwrites και βρήκα αυτό: http://en.wikipedia.org/wiki/Gutmann_method

Που σημαίνει ότι αφενός τα overwrites θα πρέπει να είναι με ένα συγκεκριμένο pattern και όχι απλά και μόνο τυχαία data και αφετέρου, για να καταφέρει κάποιος να κάνει recover τα data, έστω κι αν έχει γίνει μόνο ένα overwrite θα πρέπει ουσιαστικά να ξηλώσει τον δίσκο ώστε να διαβάσει αναλογικά(!) τα data.

Άρα για να είναι πιο σωστό το utility θα πρέπει είτε να κάνει απλά ένα πέρασμα, είτε να κάνει ένα Gutmann iteration, αν και απ' ότι φαίνεται (http://www.nber.org/sys-admin/overwritten-data-guttman.html) είναι άχρηστο.

 

---

Vir prudens non contra ventum mingit

KelMan:

Βασικά, αυτό που με ενδιαφέρει είναι η πιθανότητα και η ευκολία που μπορεί να γίνει η ανάκτηση.

Όταν ακούω εκφράσεις όπως "ειδικά εργαλεία", "ειδικά προγράμματα", "υπάρχει η δυνατότητα", αυτομάτως - χωρίς να αμφισβητώ την αξίωση - για μένα το θέμα κατατάσεται ως σενάριο out of my league, ως κάτι που δεν πρόκειται να λάβω υπόψην. Δηλαδή δεν ισχύει το "reasonable countermeasures for reasonable protection against reasonable attacks". Και πιστεύω ότι γενικότερα σε άρθρα περί security αυτό είναι που πρέπει ο συγγραφέας να προβάλει. Έχουμε πει, "ό,τι κλειδώνει - ξεκλειδώνει", οπότε δεν είναι νέο για μένα να μου πεις απλά ότι "έτσι σπάει το Χ". Αυτό που θέλω να ακούσω είναι πόσο εύκολα, πόσα resources χρειάζεται ο εισβολέας και πόσο θα μου κοστίσει να το προστατεύσω.

Ναι, έχεις δίκιο σ'αυτό, αλλά κι εγώ όπως κι εσύ κι όλοι μας, βασιζόμαστε στο τι "λένε" προς στα έξω είτε research papers είτε διάφοροι security experts του χώρου. Οπότε καταλαβαίνεις εντελώς χειροπιαστό αποτέλεσμα ή οδηγία δεν μπορεί να δώσει κανένας, αφού δεν μπορεί να δοκιμάσει εάν αυτό που καταστρέφει, μπορεί εν τέλει να ανακτηθεί απο "ειδικό λογσμικό" και σε "ειδικά εργαστήρια" που διαθέτουν αυτά τα agencies. Αυτό που μπορεί να δοκιμάσει είναι εάν εργαλεία όπως ο FileScavenger, RecoverMyFiles κι άλλα τέτοια, μπορούν να διαβάσουν το αρχείο, κι εάν μπορούν, πόσο μπορούν να το ανακτήσουν. Γιατί μπορεί να μεν να μην μπορεί να ανακτήσει όλοκληρο το αρχείο, αλλά εάν ανακτήσει σημείο το οποίο είναι το "ζουμί" (βλέπε passwords) τότε πάλι δεν έχουμε κάνει σχεδόν τίποτα.

Όπως και να έχει εργαλεία όπως το BCWipe της Jetico χρησιμοποιεί Patterns και algorithms απο το Department of Defense και Department of Energy για "καταστροφή" δεδομένων απο δίσκους και είναι φθηνό (50 ευρώ). Νομίζω ότι είναι ότι καλύτερο μπορεί να χρησιμοποιήσει κάποιος τώρα με commercial support γιατί υπάρχουν κι άλλα όπως το TrueCrypt που είναι free αλλά δεν ξέρω πόσο "καλά" είναι.

Παλαιότερα ήταν Open source το BCWipe και το BCCrypt κι είχα γράψει και κάποια μικρά κομμάτια για το Unix/Linux edition, αλλά μετά έγινε η εταιρία που είναι τώρα και σιγά σιγά σταμάτησε το open source (απο την έκδοση 2.χ και μετά).

---

Παναγιώτης Κεφαλίδης

"Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.

Η θεωρία με τα overwrites πράγματι ξεκίνησε (ή καλύτερα ανακινήθηκε) από το original paper του Peter Gutmann. H βασική αρχή που προσπαθεί να προσεγγίσει ο Gutmann πολύ όμορφα συνοψίζεται στο paper που έδωσε ο Μάνος εδώ, το οποίο δεν είχα διαβάσει και είναι πράγματι ενδιαφέρον.

Με λίγα λόγια αναφέρει:
Gutmann explains that when a 1 bit is written over a zero bit, the "actual effect is closer to obtaining a .95 when a zero is overwritten with a one, and a 1.05 when a one is overwritten with a one". Given that, and a read head 20 times as sensitive as the one in a production disk drive, and also given the pattern of overwrite bits, one could recover the under-data.

Είναι γνωστή η κρτική που έχει δεχτεί αυτή η... "θεωρία" η οποία στην τελική, εστιάζει στην φύση του υλικού και στην απομαγνητική ισχύ σε σχέση με το πλήθος των επαναλήψεων:
Even with a DC erasure process, traces of the previously recorded signal may persist until the applied DC field is several times the media coercivity [βλέπε και εδώ]).

Mε λίγα λόγια θα έλεγα οτι έχει να κάνει στην εντροπία του κάθε μέσου αποθήκευσης. Επίσης το pattern που προτείνει ο Gutmann πρέπει να επαναλαμβάνεται σε συγκεκριμένο αριθμό επαναλήψεων (από το 11 έως το 31), και να προηγούνται και να ακολουθούν "τυχαία patterns" ακόμα και για την ανάκτηση!

Ακόμα, πιο πρόσφατα άρθρα έχουν αποδείξει οτι η ανάκτηση δεδομένων μπορεί να πραγματοποιηθεί ακόμα κι από την RAM και μετά το κλείσιμο του υπολογιστή ή κι από ένα εντελώς κατεστραμμένο δίσκο, αρκεί να τον βάλετε στο... ψυγείο! Μπορείτε να δείτε το σχετικό άρθρο εδώ.

Κατά τα άλλα θα συμφωνήσω 100% και με τα λεγόμενα του Παναγιώτη και θα προσθέσω πως, πολλές φορές η συμπεριφορά των μαγνητικών υλικών προηγείται των papers και της θεωρίας καθώς εξάγονται σημαντικά συμπεράσματα μόνο εκ των αποτελεσμάτων.

Όσο αφορά στο πρόγραμμα τώρα και στις παρατηρήσεις του Μάνου:
1. FileStream και StreamWriter θα μπορούσα να χρησμοποήσω, φοβάμαι όμως μην χάσω σε χρόνο και performance για πολλά και μεγάλα αρχεία. Τώρα θα μου πεις (ίσως με το δίκιο σου) ότι ένα τεράστιο αρχείο ίσως δεν θα καταφέρω να το φορτώσω στην μνήμη ή θα "φάω" πολλά resources. Χμ... ίσως, η αλήθεια είναι όμως οτι έχω παίξει με αρχεία μέχρι και 40Μb με 10 επαναλήψεις, χωρίς ιδιαίτερο πρόβλημα.

2. Background threads και progress bar πράγματι είναι κάτι που λείπει!!

3. Να προσθέσω κι εγώ μερικά: Ενεργοποίησης της εφαρμογής από το pop-up μενού όταν κάνουμε Right Click επάνω σε ένα αρχείο και η ενεργοποίηση του Drag & Drop για να βάζουμε αρχεία προς διαγραφή.

Thnx 4 your comments!!

---

Nothing to declare...

Για να κλείσουμε λοιπόν ως προς το θεωρητικό του θέματος και μιας και είμαστε επιστήμονες, σύμφωνα με αυτά που λέει εδώ http://www.nber.org/sys-admin/overwritten-data-guttman.html, δεν υπάρχει λόγος για 35 overwrites, ένα είναι αρκετό. Από εκεί και πέρα αν το ρίξουμε στα conspiracy theories και στα black helicopters, τότε θέλουμε βαριοπούλες.

Ως προς το utility, με το FileStream και το StreamWriter δεν έχεις performance overhead, εξάλλου η File.ReadAllBytes χρησιμοποιεί το StreamReader. Αυτό ακριβώς το ReadAllBytes είναι που θα ξεφορτωθείς και δεν θα διαβάζεις κάθε αρχείο πριν το κάνεις overwrite. Τώρα, μου κάνει εντύπωση αυτό που λες για τα 40GB γιατί η ReadAllBytes βγάζει exception όταν το αρχείο υπερβεί τα 2GB. Αυτός είναι ο κώδικάς της (μέσω Reflector):

public static byte[] ReadAllBytes(string path)
{
    byte[] buffer;
    using (FileStream stream = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read))
    {
        int offset = 0;
        long length = stream.Length;
        if (length > 0x7fffffffL)
        {
            throw new IOException(Environment.GetResourceString("IO.IO_FileTooLong2GB"));
        }
        int count = (int) length;
        buffer = new byte[count];
        while (count > 0)
        {
            int num4 = stream.Read(buffer, offset, count);
            if (num4 == 0)
            {
                __Error.EndOfFile();
            }
            offset += num4;
            count -= num4;
        }
    }
    return buffer;
}

---

Vir prudens non contra ventum mingit

KelMan:

Ως προς το utility, με το FileStream και το StreamWriter δεν έχεις performance overhead, εξάλλου η File.ReadAllBytes χρησιμοποιεί το StreamReader. Αυτό ακριβώς το ReadAllBytes είναι που θα ξεφορτωθείς και δεν θα διαβάζεις κάθε αρχείο πριν το κάνεις overwrite. Τώρα, μου κάνει εντύπωση αυτό που λες για τα 40GB γιατί η ReadAllBytes βγάζει exception όταν το αρχείο υπερβεί τα 2GB.

Lol....Μάνο, δεν χρειάζεται να μου δείξεις τον κώδικα
Αυτός ο δαίμονας βάλθηκε να με κάνει ρεζίλι σήμερα!! Ζητώ συγγνώμη! Ήθελα να γράψω οτι το έχω δοκιμάσει σε 5 αρχεία με 10άρες επαναλήψεις των 40Mb και όχι των 40Gb!! που έγραψα...
Το μεγαλύτερο αρχείο που έχω δοκιμάσει με 2 επαναλήψεις και κάνει γύρω στα 30secs για το remove, είναι κάτι παρακάτω από 1Gb (Giga)!!

Το διόρθωσα και στο προηγούμενο post μου, διότι ήταν λίγο.... χοντρό!

Τώρα για το οτι δεν θα έχω performance overhead με τις FileStream και το StreamWriter, θα το τσεκάρω και θα επανέλθω. Ευκαιρία είναι να κάνω και buffering για να ξεπεράσω το 2Gb barrier.

Thnx again!

---

Nothing to declare...

No prob, o κώδικας ήταν για το StreamReader implementation (ανάλογα μπορείς να κάνεις το StreamWriter), όχι για το exception...

 

---

Vir prudens non contra ventum mingit

KelMan:

No prob, o κώδικας ήταν για το StreamReader implementation (ανάλογα μπορείς να κάνεις το StreamWriter), όχι για το exception...

Η βασική function της διαγραφής killFile ξαναγράφτηκε με τις ακόλουθες βελτιώσεις:

1. Χρησμοποιεί την StreamWriter και StreamReader και δεν διαβάζει πλέον το αρχείο όλο στην μνήμη.
2. Ξεπερνάει το φράγμα των 2Gb κάνωντας χρήση buffering. Δοκιμάστικε σε διαγραφή αρχείου 3.5 Gb.
   
3. Καθώς αλλάζει το όνομα του αρχείου σε μια σειρά τυχαίων αριθμών, ελέγχει αν ήδη υπάρχει αυτή η σειρά σαν αρχείο, πριν κάνει το rename.

Για λόγους επάρκειας των παραπάνω παραθέτω και τον κώδικα της νέας function KillFile:

public const int iBufferLength = 1024000; // 1Mb buffer.
...
...
private bool killFile(string filename)
{
    bool ret = true;

    try
    {
        byte[] rowDataBuffer;
        // I open the stream w/o the fileshare flag. This declines sharing of the current file. 
        // Any request to open the file (by this process or another process) will fail until the file is closed.
        using (FileStream stream = new FileStream(filename, FileMode.Open, FileAccess.ReadWrite))
        {

                Cursor.Current = Cursors.WaitCursor;

                FileInfo f = new FileInfo(filename);
                long count = f.Length;
                long offset = 0;
                rowDataBuffer = new byte[iBufferLength];
                while (count >= 0)
                {
                    int iNumOfDataRead = stream.Read(rowDataBuffer, 0, iBufferLength);
                    // I have inside the rowDataBuffer array the contents of a fragment of the file.
                    if (iNumOfDataRead == 0)
                    {
                        break;
                    }
                    // I will apply the transformations to the rowDataBuffer array and then i will 
                    // write it back to the file.
                    if (radioButton_RandomData.Checked)
                    {
                        Random randombyte = new Random();
                        randombyte.NextBytes(rowDataBuffer);
                    }
                    else if (radioButton_Blanks.Checked)
                    {
                        for (int i = 0; i < iNumOfDataRead; i++)
                            rowDataBuffer[ i ] = 0;
                    }
                    else
                    {
                        for (int i = 0; i < iNumOfDataRead; i++)
                            rowDataBuffer[ i ] = Convert.ToByte(Convert.ToChar(Convert.ToInt32(numericUpDown2.Value)));
                    }
                    // Write the new contents back to the file.
                    for (int i = 0; i < numericUpDown1.Value; i++)
                    {
                        stream.Seek(offset, SeekOrigin.Begin);
                        stream.Write(rowDataBuffer, 0, iNumOfDataRead);
                    }

                    // Calculate the new offset & count
                    offset += iNumOfDataRead;
                    count -= iNumOfDataRead;
                } //while
        } // using

        // Substitude every filename character with random numbers from 0 to 9.
        string newName = "";
        do{
            Random random = new Random();
            string cleanName = Path.GetFileName(filename);
            string dirName = Path.GetDirectoryName(filename);
            
            int iMoreRandomLetters = random.Next(9);
            // for more security, don't use only the size of the original filename but add some random letter.
            for (int i = 0; i < cleanName.Length + iMoreRandomLetters; i++)
            {
                newName += random.Next(9).ToString();
            }
            newName = dirName + "\\" + newName;
        } while (File.Exists(newName));

        //Rename the file to the new random name.
        File.Move(filename, newName);

        //Delete the file now.
        File.Delete(newName);
                      
    }
    catch (IOException)
    {
        ret = false;
    }
    finally
    {
        Cursor.Current = Cursors.Default;
    }

    return ret;
}

Thnx 4 your comments.

I appreciate...

---

Nothing to declare...