Etude sur un broyeur de fichier (shredder)

Bonjour,

je cherche à me documenter sur la meilleure manière de mettre en place un broyeur de fichier efficace ("schredder" en anglais). Plus je me documente plus je vois qu'il s'agit d'un sujet délicat et difficile. En effet, un formatage simple par exemple ne réinitialise pas vraiment le disque dur mais réinitialise simplement certaines données. Et il semble que les programme de récupération de disque arrivent à récupérer environ 80% des données, c'est assez flippant - ou encourageant selon le point de vue où on se place certes. Mais cela en dit long sur la protection des données. Je me suis documenté ici et là dans l'idée de mettre en place un broyeur de fichier efficace. Il y a plusieurs informations intéressantes qui sortent du lot mais certaines sont contradictoires. Ce qui me paraît clair pour l'instant c'est que:

1. Il faut éviter d'utiliser la fonction de FileMapping car les données sont placées en mémoire cache, donc non écrites physiquement sur le disque dur. Evidemment le but est de faire l'inverse: il faut forcer une écriture réelle sur le disque pour modifier les données du fichier et le rendre illisible avant son effacement.

2. Utiliser les API CreateFile/SetFilePointer pour se placer dans une fichier paraît la meilleure voie à suivre pour écrire REELLEMENT dans un fichier et ainsi effacer les données.

3. Il faut arriver à vider le cache à CHAQUE passe successive pour que chaque passé soit REELLEMENT écrite sur le disque dur.

Conclusion: une partie des logiciels broyeurs disponibles sur internet font certainement mal ce travail car ils ne tiennent pas compte des points cités ci-dessus, ce qui semble confirmé par plusieurs professionnels du milieu.

Concernant la méthode à employer sur ce qu'il faut écrire à chaque passe les informations deviennent contradictoires. J'ai toutefois tiré la conclusion suivante, qui me parle bien, à partir de différentes théories:

Une bonne méthode serait de forcer le disque dur à se "réinitialiser magnétiquement". Pour ce faire l'idée à suivre est d'écrire des passes successives avec les mêmes valeurs 00h puis la suivante avec les mêmes valeurs ffh, et ainsi de suite selon le nombre de passes définies dans le programme. Ce serait un procédé plus efficace que d'écrire n'importe quoi sur le fichier. Si on écrit différentes valeurs pour chaque byte cela génère des interférences qui sont justement utilisées par les programmes de récupération de fichier. L'idée serait d'arriver à réinitialiser magnétiquement le disque avec les même valeurs. En pratique cela paraît difficile à vérifier mais ça tient bien la route.

SI vous avez des idées sur ce sujet, une documentation intéressante, merci de m'en faire part.

Merci pour les retours. En effet, un broyeur de disque est différent d'un broyeur de fichier (ce que je vais mettre en place).

sinon ça doit pas etre trop difficile, j'ai déja une ptit fonction d'écriture de secteur sur disque via e/s

La difficulté est de faire ça bien, de limiter la possibilité d'un logiciel à récupérer le fichier broyé en forçant une véritable réécriture des données, un certain nombre de fois (passes) et pas avec n'importe quelles données semble-t-il. C'est là où les avis divergent...

Actuellement je focus mon attention à obliger Windows à ne pas utiliser de buffer lorsque mon programme va réécrire sur le fichier. C'est la meilleure manière de forcer l'écriture sur le disque à chaque passe. L'argument FILE_FLAG_NO_BUFFERING est important mais il demande des critères précis au niveau de l'allocation de la mémoire sinon ça ne fonctionnera pas. Plus d'infos ici pour les intéressés: http://msdn.microsoft.com/en-us/library/cc644950%28v=VS.85%29.aspx

Dans mon travail, (je suis assembleur...) j'utilise souvent les récupérateurs de fichiers, notamment celui de OnTrack.
D'après ce que j'ai constaté, quand un fichier est réécrit, les anciennes données ne sont pas écrasées, mais les nouvelles sont écrites plus loin sur le disque, si possible à une place vierge. Si ce n'est pas le cas d'anciennes données sont écrasées. Le meilleur moyen (à mon avis) de faire ce que tu souhaites est de créer un gros fichier rempli de tout ce que tu veux, et que tu écrives le contenu jusqu'à atteindre la fin du disque. Ainsi, plus rien n'est récupérable.[/quote]

Dans mon programme (myViewer) j'ai ajouté une option de destruction des données, et j'ai pensé renommé l'ancien fichier avec un nom bidon, puis créer un nouveau fichier avec le nom du fichier à détruire, le remplir de zéro et supprimer ce fichier, le tout pour tromper l'ennemi. Est-ce efficace ?


Tiens moi au courant, cela m'intéresse.

Dans mon travail, (je suis assembleur...) j'utilise souvent les récupérateurs de fichiers, notamment celui de OnTrack.
D'après ce que j'ai constaté, quand un fichier est réécrit, les anciennes données ne sont pas écrasées, mais les nouvelles sont écrites plus loin sur le disque, si possible à une place vierge. Si ce n'est pas le cas d'anciennes données sont écrasées. Le meilleur moyen (à mon avis) de faire ce que tu souhaites est de créer un gros fichier rempli de tout ce que tu veux, et que tu écrives le contenu jusqu'à atteindre la fin du disque. Ainsi, plus rien n'est récupérable.

Ce que tu dit est, de ce que j'ai compris, à moitié vrai. Mes connaissances actuelles ne sont pas très poussées mais voici une petite synthèse:

Lorsqu'on souhaite écrire sur un fichier déjà existant Windows va commencer par allouer un buffer pour cette écriture. Ce buffer sert à faciliter les accès disque. Notons que:

a. Ce buffer est indépendant du buffer des données à écrire alloué par le programme.

b. Ce buffer est différent de la mémoire cache du disque dur.

Si les données à écrire sont supérieures aux données du fichier alors Windows va, à un certain moment, écrire sur d'autres secteurs du disque que sur celui où se trouve le fichier déjà existant. Logique puisqu'il faut plus de place. Une partie des données d'origine seront donc préservées. Première erreur à éviter: ne pas écrire sur le fichier d'origine avec des données plus grandes que sa taille.

Si les données à écrire sont inférieurs à la taille du fichier déjà existant, on a toutes les chances pour que Windows écrive effectivement sur le fichier d'origine, pour autant évidemment que l'on spécifie vouloir écrire sur ledit fichier. On peut forcer Windows à le faire de plusieurs manières:

1. En sollicitant l'option GENERIC_ALL avec l'API CreateFile. Cette option ouvre l'accès en lecture et écriture sur le fichier. Donc les données écrites en mode GENERIC_ALL seront certainement placées sur les données lues avec GENERIC_ALL. Je me méfie d'ouvrir le fichier uniquement en accès écriture (avec l'option GENERIC_WRITE), mais peut-être que le résultat est aussi fiable.

2. Si on sollicite un accès au fichier sans utiliser le buffer de Windows les données seront écrites sur le fichier d'origine. En enlevant le buffer de Windows on accède à un levier intéressant pour prendre la main sur l'écriture du disque. Cela se fait avec l'argument FILE_FLAG_NO_BUFFERING puis en utilisant une mémoire allouée selon certains critères.

Le buffer alloué par Windows sert logiquement à éviter d'écrire sur le disque quand ce n'est pas nécessaire. Il permet d'éviter des accès disque trop fréquents. Si par exemple on veut écrire 20 passes avec à chaque fois des données différentes sur le fichier à broyer, il n'est pas du tout certain que les 20 passes seront écrites physiquement sur le disque ! On peut imaginer que dans certains cas Windows attendra que le programme aie terminé ses opérations sur le fichier puis écrira la dernière passe (les données définitives), à la fermeture du fichier, en se servant du buffer. Il faut donc enlever ce buffer. Le fait d'écrire une fois sur le disque au lieu de 20 fois augmente les chances de retrouver les données d'origine. Dans le même registre, éviter d'utiliser CreateFileMapping and co, les données sont placées en mémoire cache par Windows.

3. On peut aussi écrire chaque passe en fermant puis en réouvrant le fichier. Cela sollicite plus le disque dur mais devrait garantir que chaque passe est écrite physiquement sur le disque.

Ensuite il reste le choix des données à écrire sur le fichier. A ma compréhension le mieux est de chercher à réinitialiser les secteurs magnétiquement, avec des passes alternatives de données 00h puis ffh.

Dans mon programme (myViewer) j'ai ajouté une option de destruction des données, et j'ai pensé renommé l'ancien fichier avec un nom bidon, puis créer un nouveau fichier avec le nom du fichier à détruire, le remplir de zéro et supprimer ce fichier, le tout pour tromper l'ennemi. Est-ce efficace ?

Je trouve que c'est une bonne idée si l'"ennemi" cherche le fichier que tu as renommé. Si on part de l'idée que l'"ennemi" ne sait pas ce qu'il faut trouver et qu'il y va à l'aveugle, il aura tout de même récupéré les données du fichier que tu as renommé et il fera le tri...