tag:linuxfr.org,2005:/users/marvinLinuxFr.org : les contenus de marvin2009-05-27T19:16:45+02:00/favicon.pngtag:linuxfr.org,2005:Diary/283322009-05-27T19:16:45+02:002009-05-27T19:16:45+02:00De l'utilité de formater plusieurs fois son disque durL'histoire d'une controverse intéressante quoique pas assez connue...<br />
<br />
Comme la plupart des informaticiens j'ai toujours considéré comme acquis le fait de savoir que l'on puisse récupérer les données d'un disque dur même si celles-ci ont été complètement écrasées de multiple fois. Cela motive d'ailleurs la procédure qui consiste lors d'un formatage de bas niveau, à effectuer de multiple cycles d'écriture, si possible avec des données aléatoires, comme le fait l'utilitaire DBAN.<br />
<br />
J'avais même entendu à l'époque qu'il était possible de récupérer des données ayant été écrasées plus de sept fois. Ce genre de prouesse m'avait toujours laissé songeur, d'autant plus que je n'avais *jamais* entendu une quelconque référence à cette technique dans un cas pratique. La plupart des livres sur l'informatique légale soit évite le sujet, soit se bornent à dire que cela est possible, mais hors de portée de la plupart des laboratoires scientifiques, si ce ne n'est ceux d'agences gouvernementales aux états-unis.<br />
<br />
D'un naturel sceptique je me suis mis alors à chercher des sources sur internet. La première chose qui choque est le manque d'information disponibles sur le sujet. L'une des seules ressources étant finalement la publication de Guttman ([<a href="http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html">http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html</a>]), publié en 1996, et décrivant la méthode du même nom avec laquelle tout a commencé, et qui recommande effectivement d'effectuer 35 cycles de formatage bas niveau afin d'être sûr que rien ne puisse être récupéré, quelque soit le disque ou la technologie utilisée.<br />
<br />
L'hypothèse que l'on puisse récupérer des données ayant été écrasées se base sur le principe que si l'on met à 1 un bit à 0, l'on obtiendra une charge magnétique plus proche de 0.95 que de 1. Inversement, si on écrit un 1 sur un autre 1, la charge magnétique sera plus proche de 1.05 que de 1. L'idée étant de repérer ces différences en observant les plateaux du disque dur à l'aide de ce qu'on appelle un microscope à force magnétique (le genre d'appareil que l'on ne trouve pas sur eBay), a peu près 20 fois plus sensible qu'une tête de lecture standard.<br />
<br />
C'est tout. Pas d'autre papier sur le sujet.<br />
<br />
La publication de Guttman à été critiquée en 2003 par un chercheur du National Bureau of Economic Research aux États-unis [<a href="http://www.nber.org/sys-admin/overwritten-data-guttman.html">http://www.nber.org/sys-admin/overwritten-data-guttman.html</a>]. L'auteur décrit notamment certains lacunes dans les références que présente Guttman, en particulier que (contrairement à ce que le papier pourrait laisser croire) <b>personne</b> n'a jamais réussi à extraire des données d'un disque dur ayant subi un formatage de bas niveau intégral. Tout au plus, certains chercheurs ont constaté qu'une poignée de bits épars possédait certaine caractéristiques qui laissait penser que l'on pouvait déduire leur état précédent. Il s'agit de comptes-rendus d'expériences visant à optimiser les opérations d'écritures par les têtes de disque dur plus que des recherches sur la récupération de données. Le chercheur qualifie également comme gratuites les suppositions comme quoi des agences gouvernementales et judiciaire aurait en leur possession du matériel capable de tel prouesses. Même après toutes ces années, aucune source ne tend d'ailleurs à le prouver.<br />
<br />
Pas plus tard qu'en 2008, une autre publication (qui à été par la suite mise on-line en janvier de cette année ici [<a href="http://sansforensics.wordpress.com/2009/01/15/overwriting-hard-drive-data/">http://sansforensics.wordpress.com/2009/01/15/overwriting-ha(...)</a>]), d'un certain Craig Wright (un docteur possédant une liste assez impressionnante de diplômes et publications), remet également en cause le papier de Guttman en essayant de récupérer les données de disques durs récents à l'aide d'un microscopes à électron. Les résultats sont assez éloquent.<br />
<br />
Alors que la probabilité de retrouver 1 seul bit de manière fiable est relativement élevée (87% de chance) la probabilité de restaurer un octet complet est uniquement de 32%. Pour 32 bits: à peine plus de 1% de chance. Et cela uniquement sur un disque vierge sur lesquels on a effectué un seul cycle d'écriture/écrasement. Pour les disques déjà utilisés, les probabilité de retrouver ne serait-ce que 16 bits correct (1 caractère utf-8) descendent dans des profondeurs abysalles (9*10e-5, testé sur un vieux disque dur avec une densité inférieure à ce que l'on trouve déjà dans le commerce aujourd'hui).<br />
<br />
La conclusion de Wright est sans appel: vous n'arriverez jamais à récupérer ne serait-ce que quelques octets de données utilisables d'un disque dur qui à été écrasé. Pas même après un seul cycle d'écriture. C'est physiquement impossible. Pas avec un microscope à électron (et à fortiori, pas avec aucune autre méthode connue). De multiples points sont évoqués. Tout d'abord l'erreur accumulée lorsque l'on essaie de récupérer un groupe de bit plutôt qu'un bit individuel. Il y a ensuite les variations des champs magnétique dûs au facteurs environnementaux, tel que les mouvements de la tête, l'humidité. Il y a également un effet d'hystérésis lors de l'écriture qui peut également rendre imprécise la charge magnétique d'un bit (indépendamment de son état précédent ).<br />
<br />
Guttman fourni une réponse à cet article, le critiquant ouvertement sur différents points, argumentant que Wright confondait plusieurs concepts clé et allant également jusqu'à critiquer sa terminologie. Cependant, bien que Guttman tente de refuter l'article, il précise également dans sa réponse que, effectivement, récupérer des données qui ont été écrasées d'un disque dur actuelle serait vraisemblablement voué à l'échec, notamment à cause des très hautes densitées de données que l'on peut y trouver aujourd'hui: "<i>Any modern drive will most likely be a hopeless task, what with ultra-high densities and use of perpendicular recording I don't see how MFM would even get a usable image, and then the use of EPRML will mean that even if you could magically transfer some sort of image into a file, the ability to decode that to recover the original data would be quite challenging.</i>"<br />
<br />
Wright, quant à lui à également répondu sur son blog personnel [<a href="http://gse-compliance.blogspot.com/2009/01/response-to-dr-gutmann.html">http://gse-compliance.blogspot.com/2009/01/response-to-dr-gu(...)</a>], contrant les arguments de Guttman point par point avec une certaine répartie. Il note le simple fait qu'aucune expérience pratique n'a jamais démontré la véracité de la théorie, et des chiffres avancés par Guttman. Il met également l'accent sur ce qui est selon lui l'une des plus grandes méprises de Gutmann: confondre la récupération de quelques bits sur le disque (des sources stochastiquement indépendantes) avec la récupération de données, tout simplement.<br />
<br />
Je ne suis pas un expert de la branche et je n'ai pas le background nécessaire pour comprendre la totalité des arguments techniques exposés. Cependant la position de Wright semble être mieux définie que celle de Guttman sous plusieurs angles.<br />
<br />
Au final, tout le monde semble cependant se mettre d'accord sur un point: RIEN n'indique qu'il n'est, ou qu'il sera possible un jour de récupérer des données qui auraient été écrasées ne serait-ce que une seule fois sur un disque dur.<br />
<br />
Qu'est-ce que l'on peut retenir de ça? Tout simplement qu'un seul formatage est suffisant pour tout le monde, c'est vrai pour vous, et c'est également vrai pour la Nasa. Formater une seul fois vos vieux disque durs vous fera économiser du temps, ainsi que leur durée de vie.<br />
<br />
Maintenant il ne faut pas se faire d'illusion, la nécessité d'écraser chaque bit avec une bonne dizaine de cycle d'écriture, est tellement ancrée dans les esprits que je doute que grand monde décide d'y changer quelque chose, même si cela doit tenir du mysticisme pur.<br />
<br />
On peut débattre indéfiniment à savoir à quelle point la paranoïa est profitable pour la sécurité, et a partir de quand on va trop loin. Il y a une chose dont on peut être sûr cependant: les "justes au cas où" peuvent justifier n'importe quelle précaution abusive, et vous faire perdre du temps que vous pourriez passez sur de vrais problèmes.<div><a href="https://linuxfr.org/users/marvin/journaux/de-lutilit%C3%A9-de-formater-plusieurs-fois-son-disque-dur.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/54662/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/marvin/journaux/de-lutilit%C3%A9-de-formater-plusieurs-fois-son-disque-dur#comments">ouvrir dans le navigateur</a>
</p>
marvinhttps://linuxfr.org/nodes/54662/comments.atomtag:linuxfr.org,2005:Diary/191702005-08-22T19:05:46+02:002005-08-22T19:05:46+02:00Jouons avec sawfish (et zsh)Histoire de pouvoir dire que j'ai fait quelque chose de mes vacances je me suis divertit en pondant un petit script pour sawfish qui marche en collaboration avec zsh.<br />
<br />
Étant d'un naturel franchement bordelique je finis couramment mes sessions avec une bonne vingtaine de terminaux ouverts. d'où l'idée d'avoir une fonction qui m'active un terminal inutilisé plutôt que de m'en ouvrire un nouveau à chaque fois... voilà comment ça se passe (c'est la première fois que je fais mumuse avec sawfish, les commentaires sont les bienvenus):<br />
<br />
À ajouter dans <i>~/.sawfishrc</i>:<br />
<code>(define (set-xterm-ready win-id)<br />
(window-put (get-window-by-id win-id) 'A_READY_XTERM 't))<br />
<br />
(define (unset-xterm-ready win-id)<br />
(window-put (get-window-by-id win-id) 'A_READY_XTERM nil))<br />
<br />
;; Active le terminal libre ayant été privé du focus le plus longtemps, un appel<br />
;; répété de la fonction aboutira donc à un parcours de tout les terminaux libres.<br />
(define (get-next-xterm-ready)<br />
(require 'sawfish.wm.util.window-order)<br />
(let ((term (car (member-if (lambda (x)<br />
(window-get x 'A_READY_XTERM))<br />
(reverse (window-order))))))<br />
(if term<br />
(fetch-win term)<br />
(system (getenv "MY-XTERM")))))<br />
<br />
;; Activation "complète" de la fenêtre (déplacement vers le bureau courant si<br />
;; nécessaire, activation du focus et mise au 1er plan).<br />
(define (fetch-win w)<br />
(unless (window-in-workspace-p w current-workspace)<br />
(move-window-to-workspace<br />
w<br />
(car (window-workspaces w))<br />
current-workspace<br />
nil))<br />
(activate-window w))<br />
</code><br />
NB: Si aucun terminal inutilisé à été trouvé lors de l'appel de la fonction, un nouveau terminal est automatiquement lancé (ce dernier étant contenu dans la variable d'environnement "<tt>MY-XTERM</tt>", l'appel en dur peut se faire en remplaçant <i>(system (getenv "MY-XTERM"))</i> par <i>(system "myterm")</i>).<br />
<br />
Et dans <i>~/.zshrc</i>:<br />
<code>if [ "$TERM" = "xterm" -o "$TERM"="Eterm" -o "$TERM"="aterm" -o "$TERM"="rxvt" ] ; then<br />
precmd (){<br />
sawfish-client -q -c "(set-xterm-ready ${WINDOWID})" &> /dev/null<br />
}<br />
preexec () {<br />
sawfish-client -q -c "(unset-xterm-ready ${WINDOWID})" &> /dev/null<br />
}<br />
fi<br />
</code><br />
Voilà, ensuite il suffit de binder la fonction correspondante à une touche dans <i>~/.sawfishrc</i>:<br />
<code>(bind-keys global-keymap "F12" '(get-next-xterm-ready))<br />
</code><br />
Ou à un lanceur quelconque qui exécutera:<br />
<code>sawfish-client -q -c '(get-next-xterm-ready)'<br />
</code><br />
Ça reste bien sûr à adapter suivant les besoins (garder un raccourcis ouvrant à tous les coups un terminal est bien évidemment plus qu'utile).<div><a href="https://linuxfr.org/users/marvin/journaux/jouons-avec-sawfish-et-zsh.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/45702/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/marvin/journaux/jouons-avec-sawfish-et-zsh#comments">ouvrir dans le navigateur</a>
</p>
marvinhttps://linuxfr.org/nodes/45702/comments.atomtag:linuxfr.org,2005:Diary/148282004-08-04T21:08:02+02:002004-08-04T21:08:02+02:00Firefox 0.9.3, Thunderbird 0.7.3 et Mozilla 1.7.2Tout ce beau monde vient de sortir aujourd'hui... Pour le peu que j'en ai vu (impossible de mettre la main sur un changelog digne de ce nom) il s'agit uniquement de mises à jour de sécurité (résolvant notamment les problèmes de certificats), excepté pour Mozilla qui a eu également droit à quelques bugfix supplémentaires. Mangez-en...<br />
<br />
Plus de précision quant aux bugs corrigés:<br />
<a href="http://forums.mozillazine.org/viewtopic.php?p=692740&highlight=#692740">http://forums.mozillazine.org/viewtopic.php?p=692740&highlight=(...)</a><br />
<br />
Et tant que je suis là:<br />
4ème semaine de l'initiative marketing communautaire visant a promouvoir le renard de feu: <br />
<a href="http://www.blakeross.com/archives/000241.html">http://www.blakeross.com/archives/000241.html(...)</a><br />
En français (et en plus condensé): <a href="http://mozillazine-fr.org/archive.phtml?article=5123">http://mozillazine-fr.org/archive.phtml?article=5123(...)</a><div><a href="https://linuxfr.org/users/marvin/journaux/firefox-093-thunderbird-073-et-mozilla-172.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/41479/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/marvin/journaux/firefox-093-thunderbird-073-et-mozilla-172#comments">ouvrir dans le navigateur</a>
</p>
marvinhttps://linuxfr.org/nodes/41479/comments.atomtag:linuxfr.org,2005:Diary/88722004-01-29T19:45:23+01:002004-01-29T19:45:23+01:00Des nouvelles de chez Xfree- Sortie de xfree86 4.4.0rc2<br />
- Nouvelle version (1.1) de la licence X11 ( <a href="http://www.xfree86.org/legal/licenses.html">http://www.xfree86.org/legal/licenses.html(...)</a> ), celle-ci est censée mieux refléter leur philosophie: «You can do what you like with the code except claim you wrote it»<br />
<br />
Ravi de voir que ça se remet à bouger après tout ces chamboulements :)<div><a href="https://linuxfr.org/users/marvin/journaux/des-nouvelles-de-chez-xfree.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/35587/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/marvin/journaux/des-nouvelles-de-chez-xfree#comments">ouvrir dans le navigateur</a>
</p>
marvinhttps://linuxfr.org/nodes/35587/comments.atomtag:linuxfr.org,2005:Diary/73542003-12-02T20:21:51+01:002003-12-02T20:21:51+01:00Client VPN pour Linux/WinSalutations,<br />
<br />
Jusqu'à aujourd'hui, l'accès aux serveurs intranet de mon campus via le wifi nécessite de passer au travers d'un client VPN cisco propriétaire (qui en plus de cela n'est pas adapté aux kernels récents)...<br />
<br />
A l'occasion d'un sondage fait par l'admin, j'aimerais proposer de migrer vers une solution libre, mais n'étant pas très au courant de ce qui se fait dans ce domaine, j'aurais voulu connaître vos bonnes expériences/conseils/etc.<br />
<br />
Il faudrait bien entendu noter la présence d'un client m$ win...<br />
<br />
Des idées ?<div><a href="https://linuxfr.org/users/marvin/journaux/client-vpn-pour-linuxwin.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/34083/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/marvin/journaux/client-vpn-pour-linuxwin#comments">ouvrir dans le navigateur</a>
</p>
marvinhttps://linuxfr.org/nodes/34083/comments.atom