Discussion :

[Luke spywoker]

Salut les C,
j'ai coder un programme d'effacement de fichier que je ne vais pas exhiber ici comme la dernière fois avec la réplique de la commande ls -l (j'ai suivis vos conseils d'amélioration et ajouter des trucs sympa...)
Mais la question est purement théorique:
Mon programme comprend 2 étapes et est basé sur les fonctions:
-open(), read(), write(), et (f)truncate pour le changement du contenus du fichier.
-utime() et rename() pour la modification des métadonnées.
-remove() pour l'effacement du fichier.

-> Etape 1)
-) Calcul de la taille du fichier avec read().
-) Remplacement du contenus du fichier par des caractères '\0'.
-) Ajout de caractères '\0' pour que la taille soit: ( (taille % 512) == 0 )
-) avec ftruncate().
-) Changement de l'horodatage pseudo aléatoire avec utime().

-> Etape 2) dans une boucle:
-) Appel a truncate() en divisant la taille du fichier par 2 a chaque fois.
-) Changement de l'horodatage pseudo aléatoire avec utime().
-) Renommage avec rename().
-) Jusqu'a arriver a une taille de zéro.
-) Effacement du fichier avec remove().

J'en arrive a ma question le fichier effacer comme décrit est-il retrouvable ?
Je pose cette question car je ne prétend pas savoir comment fonctionne un ordinateur nie la réponse a ma question.
Ma technique d'effacement du fichiers est-elle pertinente ?

A vous de jouer.

PS: le programme permet d'effacer des fichiers textes de plus de 1 Gio de taille.
Et si vous voulez vraiment le voir il va falloir que je le commente avant de le poster.

Merci pour vos réponses (techniques) (théoriques ?).

[kwariz]

[...]
Ma technique d'effacement du fichiers est-elle pertinente ?

A vous de jouer.

PS: le programme permet d'effacer des fichiers textes de plus de 1 Gio de taille.
Et si vous voulez vraiment le voir il va falloir que je le commente avant de le poster.

Merci pour vos réponses (techniques) (théoriques ?).

Bonjour,

pertinente ? heu, sans doute puisque tu surécris les données. Est-elle pour autant efficace ? Dans une certaine mesure je pense que oui, mais je suppose qu'elle ne résiste pas à des outils spécialisés dans le recovery de données. En effet il n'y a qu'une passe et avec un pattern simple (que des octets nuls), tu ne surécris pas le nom du fichiers en lui-même. Mais bon je ne suis pas un pro en la matière non plus. Je suppose qu'avec un système de fichier journalisé le changement de timestamps (d'ailleurs que surécris-tu ? la date dernière modification, de dernier accès, de création, ...) peut être inutile.
Dans le genre tu peux aussi consulter des sources comme gnu shred, l'outil gnu pour faire un effacement sécurisé. Il y a pas mal de références sur wikipedia où on peut lire :

The simplest overwrite technique writes the same data everywhere—often just a pattern of all zeros. At a minimum, this will prevent the data from being retrieved simply by reading from the medium again using standard system functions.

[Ngork]

L'idée de fournir une fonction d'effacement des données est une bonne idée, mais il faut travailler au plus bas niveau.

En effet, rien ne permet d'affirmer avec la méthode que tu décris que les octets précédemment écrits sur le disque auront été effacés, car rien n'assure que le système écrit les nouveaux octets (des '\0' donc) à l'emplacement exact des anciens.
Selon le système de fichiers, il est parfaitement possible et même probable que le nouveau contenu soit écrit ailleurs.

La seule méthode pour être certain d'écraser le fichier dépend du système, mais consiste à récupérer l'emplacement exact de chaque bloc de stockage utilisé par ton fichier original, puis à réécrire de nouvelles données, de préférence aléatoires, dans les mêmes emplacements ...
C'est de la programmation à très bas niveau qui demande du code et des droits particuliers selon le système visé.

Bon courage !

[Metalman]

Exact, et avec la libF (fread/fwrite), tu es tellement "en hauteur" par rapport à ton DD et ton OS que c'est quasiment inutile.

Une des méthodes employée par un autre logiciel est d'effacer "plusieurs fois" le contenu avec plusieurs valeurs : écrire que des 0, puis que des 1, que des 2, ... cela N fois.
Ca va de 1 fois à 30 fois.

Les problèmes face auxquels tu te trouves sont les suivants :
1) la LibF ne t'assure qu'un moyen d'accéder à un fichier, de le lire et le modifier

2) Ton OS peut dans certains cas sauvegarder de lui-même une copie du fichier (certains systèmes pour des machines plus grosses que les PC créent 1 copie du fichier pour chaque modification, et sauvegardent N versions précédentes)

3) Ton FS peut "optimiser" l'accès au stockage physique, et donc t'ajouter une contrainte que tu ne verras pas (par exemple les mémoires flashs étant limitées en nombre d'écritures, chaque nouvelle écriture sera faite sur l'espace le plus vieux inutilisé, selon le FS utilisé)

4) L'espace d'écriture "sur disque" peut être lui aussi "une surcouche" : sur des RAID, ou des systèmes spéciaux, tu n'accèdes pas au disque mais à un espace que le device montrera à l'OS. Les CPU/Chipset/DMA vont envoyer des requêtes de lectures/écritures avec des adresses, et le device choisira l'endroit et la méthode qu'il souhaite pour appliquer cela.

Ton programme va donc dépendre de TOUTE cette longue chaîne !

Au final : si on retire ton disque de la machine... il est possible de retrouver des traces de tout...
L'écriture sur les DD classiques de PC permettent de retrouver le contenu d'un ancien fichier "écrasé par un autre" grâce à des méthodes précises (mais limitées quand même) : on inverse la polarité quand on a un changement de valeur entre 0 et 1... du coup si tu inverses la première valeur, tu as un fichier "opposé"... (voir les algos d'écritures sur DD sur wikipedia)

[Sve@r]

Salut
Joli travail de recherche pour l'algo. Je suis étonné de ta fonction "remove()" que je ne connais pas (je connais de mon coté la primitive "unlink()") mais cela ne change rien au travail.

Maintenant, pour bien répondre à ta question, il faut bien comprendre le fonctionnement de l'électrique et du magnétisme. Un disque informatique, c'est du zéro et du un, tout le monde est d'accord. Mais au niveau électrique, c'est ni zéro ni un. C'est "moins de 0.5" ou "plus de 0.5". Donc 0.2 c'est zéro. Mais 0.3 c'est aussi zéro. Et 0.8 c'est "un" mais 0.9 c'est aussi "un".
De plus, la piste magnétique c'est pas un galet tout plat. C'est une surface ferreuse inégale. Ainsi tu écris "un" le contrôleur va écrire "0.9" mais le bord lui est magnétisé à "0.8". Ensuite tu écris zéro le contrôleur va écrire "0.1" au centre et le bord par conductivité passe à "0.4".

Et donc il existe des outils très spécialisés qui examinent le disque au niveau atomique et qui arrivent à remonter un historique sur 3 ou 4 niveaux. Il existe d'ailleurs de l'autre coté des logiciels d'effacement "sécurisés" qui vont écrire un même fichier 7 fois d'affilée en méthode de base mais qui peuvent monter jusqu'à 25 en option. Et même avec ces logiciels le Ministère de la Défense (pour qui je bosse) n'ont pas confiance et c'est pour ça qu'un disque qui a contenu des informations d'un certain niveau de classification ne peut plus jamais être déclassifié. Une fois fini, il part à la fonderie et il est envoyé au four devant témoins (qui signent ensuite un papier engageant leur responsabilité).

Alors répondre à ta question "est-ce que le fichier n'est plus récupérable" est comme tu le vois très difficile. Pour ta petite soeur, tes copains de boite ou tes collègues de bureau très certainement. Mais pour eux pas besoin de faire si compliqué, un simple "rm" sous Unix et le fichier (vu la façon dont bosse le "ext") est déjà perdu définitivement.
Maintenant pour un organisme disposant de milliers d'euros d'équipement de pointe, beaucoup moins...

Ceci dit, cela reste un joli effort d'algo qui mérite le +1

[plxpy]

Et même avec ces logiciels le Ministère de la Défense (pour qui je bosse) n'ont pas confiance et c'est pour ça qu'un disque qui a contenu des informations d'un certain niveau de classification ne peut plus jamais être déclassifié. Une fois fini, il part à la fonderie et il est envoyé au four devant témoins (qui signent ensuite un papier engageant leur responsabilité).

Pour les soupçonneux de nature, je confirme.

[Metalman]

Svear est entré dans les détails que je n'ai pas osé sur les niveaux de tension. Merci pour tout ça du coup !
Je ne sais pas si les logiciels sont capables de connaitre les tensions/champs électriques/champs magnétiques exactes... ça doit dépendre du disque et de ce que le contrôleur offre comme interface probablement... mais j'avais déjà lu ça aussi !

(Et pour la déclassification : il n'y a toujours pas de gestion dans le temps des niveaux de classification au mindéf ?
Ou garder des DD coûte trop cher en attendant la déclassification ?...
Ou cela concerne les DD défectueux à l'usage (mais toujours lisible si on y met les moyens) ?
....si je pose trop de question il faut me le dire )

[Sve@r]

(Et pour la déclassification : il n'y a toujours pas de gestion dans le temps des niveaux de classification au mindéf ?

Si bien sûr mais c'est de l'ordre de la vingtaine d'années. Et en plus ça ne s'applique qu'aux documents et pas au support (ou plutôt le support restera classifié autant de temps que le dernier document qu'il aura possédé)...

[Luke spywoker]

Merci pour vos nombreuses réponses et le compliment sur l'algorithme, j'ai beaucoup appris de vos réponses techniques:
Je pense que la prochaine étapes faisable (chacun a ces moyens) est:

La seule méthode pour être certain d'écraser le fichier dépend du système, mais consiste à récupérer l'emplacement exact de chaque bloc de stockage utilisé par ton fichier original, puis à réécrire de nouvelles données, de préférence aléatoires, dans les mêmes emplacements ...
C'est de la programmation à très bas niveau qui demande du code et des droits particuliers selon le système visé.

Dans un futur plus ou moins lointain car pour moi le temps c'est du savoir appris, mis en application, acquis et|ou du savoir oublier, des fois j'ai l'impression que mon tampon déborde et parfois j'arrive a deviner les noms des fonctions a chercher dans les manpages que je n'ai jamais entrevue...