L'histoire d'une controverse intéressante quoique pas assez connue...
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.
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.
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 ([http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html]), 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.
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.
C'est tout. Pas d'autre papier sur le sujet.
La publication de Guttman à été critiquée en 2003 par un chercheur du National Bureau of Economic Research aux États-unis [http://www.nber.org/sys-admin/overwritten-data-guttman.html]. 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) personne 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.
Pas plus tard qu'en 2008, une autre publication (qui à été par la suite mise on-line en janvier de cette année ici [http://sansforensics.wordpress.com/2009/01/15/overwriting-ha(...)]), 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.
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).
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 ).
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: "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."
Wright, quant à lui à également répondu sur son blog personnel [http://gse-compliance.blogspot.com/2009/01/response-to-dr-gu(...)], 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.
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.
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.
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.
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.
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.
Journal De l'utilité de formater plusieurs fois son disque dur
27
mai
2009
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par claudex . Évalué à 7.
D'où l'utilité de chiffrer ses données.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Simplicité
Posté par Guillaume Knispel . Évalué à 2.
[^] # Re: Simplicité
Posté par bibitte . Évalué à 5.
Ps: je suis pas expert c'est juste un question.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par marvin . Évalué à 4.
Si tu as un document en ascii, récupérer seulement 7 des 8 bits d'un caractère (ce qui est déjà assez improbable) n'aide pas beaucoup (pour ne pas dire pas du tout), surtout si tu ne sais pas quel est le bit qui est erronés.
Sans trop m'avancer, quant il dit que tu peux rien tirer de satisfaisant d'une telle analyse, sa conclusion semble assez solide :-)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par allcolor (site web personnel) . Évalué à 4.
Mais récupérer 7bits de chaque caractère d'une phrase ?On ne parle pas ici de cryptographie... faudrait déjà que tu saches que tu es en train de récupérer une phrase.... le disque il est vide, formaté, y a plus rien dessus et toi tu peux découvrir sur ce disque la valeur précédente de quelques bits éparpillé sur le disque... ton disque c'est pas un livre avec que des phrases.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par allcolor (site web personnel) . Évalué à 2.
Selon le post, il y a 87% des bits qui sont récupérables...Pas du tout !!!! relis mieux :
Alors que la probabilité de retrouver 1 seul bit de manière fiable est relativement élevée (87% de chance)C'est la probabilité pour retrouver l'état précédant *d'un seul bit*, pas le % de bits récupérables sur le disque. Donc non c'est infaisable.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par allcolor (site web personnel) . Évalué à 2.
Genre la probabilité d'obtenir 1, 2 ou 3 dans un lancé de dés est de 1/2, la probabilté d'obtenir 2 fois 1,2 ou 3 sur deux lancé est de 1/2*1/2 = 0,25 et ainsi de suite.
La probabilité d'obtenir 1 bit est de 87%, la probabilité d'en obtenir 10000000 est de 87/100^10000000 .
Ou alors ce ne sont pas des tirages indépendants...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par allcolor (site web personnel) . Évalué à 4.
la probabilité de restaurer un octet complet est uniquement de 32%Comment arrive t'on à 32% ? 0,87^8 = 0,328211672 , tiens donc.
Pour 32 bits: à peine plus de 1% de chance.Comment arrive t'on à 1% ? 0,87^32 = 0,011604223 ...
[^] # Re: Simplicité
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 8.
Ton approche est "j'ai rien de bon si j'ai pas les 8 bits de mon octet". La sienne est "je me fous des octets, je m'intéresse qu'aux bits.
Exemple: on récupère 7 bits de chaque octet. On a zero octet de récupéré. Pour toi c'est nul. Mais on a (* (/ 7 8) 100) = 87% de bits récupérés !
La différence est donc que tu t'imposes une contrainte (le bloc de 8 bits) dont on a en fait (plus ou moins) rien à faire.
Je rejoins alenvers.
[^] # Re: Simplicité
Posté par allcolor (site web personnel) . Évalué à 1.
un texte de 12 caractères, chaque caractère codé sur 8 bits ==> (96 bits), 13% de bits invalide répartis uniformément ==> (12 bits invalide) ==> (1 bit par octet en moyenne) ==> 8 choix différents par octets ==> 8^12 choix pour juste les 12 octets récupéré ==> 68719476736 cas possible et ceci rien qu'avec 12 octets dont chacun a un bit invalide (et tu ne sais pas lequel des 8), tu peux restreindre le nombre de cas possible si tu sais que dans les 12 octets tu n'a que des lettres majuscules ou minuscules (et en gros que c'est du texte) mais quand tu lis ton disque, ça, t'en ****SAIS RIEN DU TOUT****.
Alors la recherche du header ELF ou tout autre truc est impraticable...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
En posant grossièrement 87% = 1 bit faux sur 8.
Étant donné une table de fréquence d'apparitions de suites d'octets, je peux dériver une table de fréquence d'apparitions probable d'octets (avec erreur).
Si initialement, tu n'as *jamais* 11111111, alors après erreur, tu n'auras quasiment jamais "01111111" ni "10111111" ni "11011111" et ainsi de suite.
Ton erreur est qu'en fait tu omets des connaissances. Un test de 12 caractères n'est pas aléatoire. Dans ce journal, en gros, la lettre qui apparait le plus est le "e". Et sans même lire la réponse que tu feras à ce message, sans *RIEN SAVOIR DU TOUT*, j'affirme que ton texte comportera 14.7% de "e".
Certes, sur 12 lettres, on ira pas loin dans la reconstruction. Et c'est normal. Mais sur 30Go de texte, ça se reconstruit pas mal du tout.
J'affirme aussi que plusieurs endroits de ton disque dur contiennent le texte "JFIF" et qu'ils sont physiquement proches (aucune fragmentation à l'installation de ton OS, toutes les images de ton WM, dans /usr/share/machin sont dans un espace contiguë de ton disque)
[^] # Re: Simplicité
Posté par Guillaume Knispel . Évalué à 3.
Tu confonds avoir des bits à une position prédéfinie corrects (et le reste totalement aléatoire), ce qui n'est pas le cas ici, et avoir 87% des bits corrects sauf que tu ne connais pas ceux qui sont corrects et ceux qui ne le sont pas.
En ce qui concerne un header ELF, j'ai l'intuition que sa localisation probabliste se ferait avec un degré de confiance en fait pas si mauvais que ça ; qui se dévoue pour faire les maths pour confirmer / infirmer ? :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par Romuald Delavergne . Évalué à 4.
Pour récupérer un octet il faut 8 bits corrects à la suite à partir du début d'un octet d'où le % de chance qui diminue.
[^] # Re: Simplicité
Posté par Guillaume Knispel . Évalué à 2.
Mais on sait très bien recouvrir certaines erreurs. Ou simplement faire avec le fait qu'il y a des erreurs mais profiter néanmoins de l'information qu'on a recueilli.
87% de proba qu'un bit soit juste est pour certains usages une quantité d'information tout simplement énorme. Sans même être un expert en la matière je peux déjà imaginer une espèce de distance de hamming probabiliste qui permettrait d'accélerer le cassage de clef par force brute. Un expert trouverait peut-être des tas d'applications encore plus puissantes.
[^] # Re: Simplicité
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Simplicité
Posté par allcolor (site web personnel) . Évalué à 3.
Je prends un bit, j'ai 50% de chance de donner sa valeur correcte (soit 1 ou 0), donc je peux récupérer 50% d'un disque... tu vois le problème j'espère.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par allcolor (site web personnel) . Évalué à 1.
Reprenons ce qui est dit, moins de 1% de chance de récupérer 32bits, pourquoi car 0,87^32.
Maintenant j'ai un disque effacé, avec la méthode proposée j'ai donc 1% de chance de récupérer 32bits ! Considérons un disque de 10Go, donc 80^10 bits, donc 335544320000000000 blocs de 32bits, si je fais tous les blocs (ou 335544320000000000 le même bloc) en moyenne (loi des grands nombre) j'aurai environ 33554432000000000 de fois ou le bloc de 32bits à la bonne valeur (sur les 335544320000000000 blocs testé ou essai sur le même bloc).
[^] # Re: Simplicité
Posté par allcolor (site web personnel) . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par allcolor (site web personnel) . Évalué à 2.
[^] # Re: Simplicité
Posté par allcolor (site web personnel) . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 10.
\o/ Je trouve cette répartie extrêmement élégante.
[^] # Re: Simplicité
Posté par Bozo_le_clown . Évalué à 10.
[^] # Re: Simplicité
Posté par Dr BG . Évalué à 1.
Un minimum, donc. Mais je ne comprends toujours pas la phrase...
[^] # Re: Simplicité
Posté par thedude . Évalué à 5.
Il suffit de trouver une methode qui donne 0% de bits bon alors.
Et apres, paf, on prend l'autre bit a chaque fois.
[^] # Re: Simplicité
Posté par claudex . Évalué à 9.
C'est pas compliquer, tu trouve une méthode qui donne 100% de bits bon. Et après, paf, tu prend l'autre bit à chaque fois.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Simplicité
Posté par patate . Évalué à 2.
[^] # Re: Simplicité
Posté par marvin . Évalué à 2.
En pratique on à 87% de on ne sait pas trop quoi... Ce pourcentage est variable, non uniforme sur le disque, et descend en flèche dès que le disque est utilisé régulièrement, ou que le disque chauffe, etc.
Même en partant du principe que 87% des bits sont effectivement correct au final tu peux statistiquement construire tout et n'importe quoi comme données avec les 80 millards de bits à disposition sur un disque de 10Go...
[^] # Re: Simplicité
Posté par beagf (site web personnel) . Évalué à 3.
En effet si c'est réellement 87% de on ne sait pas quoi, on irra pas loin. Mais en pratique c'est plustôt 87% de j'ai une petite idée de ce qu'il peut y avoir quelque part sur le disque.
Imaginons que tu récupère un disqu de la société Bidule et que tu te doute qu'il y a dessus des lettres que tu as envie de lire. Tu sais que la secrétaire utilise le logiciel Truc pour taper ces lettres.
Après une petite analyse, tu vois que le logiciel Truc met un entête "FICHIERTEXTELOGICIELTRUC" au début de chaque fichier et ensuite le contenu de la lettre en ascii.
Tu parcours le disque à la recherche d'une chaine de bit, alignée sur un octet, et dont la distance de haming avec l'entête est faible (probablement au alentour de 0.87 ;-). À chaque fois que tu la trouve, il y a une bonne probabilitée que la suite soit une lettre tapée par la secrétaire. A ce moment la, tu récupère la suite, et tu sais que c'est de l'ascii et que cela représente des mots, suposé cohérents. Donc tu utilise un algo qui permet de recupéré un message passé dans un canal bruité du style Algorithme_de_Viterbi et tu récupère la lettre.
Bien sûr la c'est un exemple simpliste, mais dans la pratique tu as presque toujours un minimum d'information. Si tu sais le systeme d'exploitation qui était utilisé, tu peu souvent deviner le système de fichier et donc savoir comment les données sont organisées sur le disque.
Quasiment tous les formats de fichiers ou des entêtes plus ou moins fixe, cela facilite leur repérage, et une fois que tu les a repéré, vu que tu connais le type de fichier tu peut tenter une récupération.
Pour du texte brut, une perte de 13% des bits c'est loin d'être énorme, et avec de bons modèles $n$-grammes et un viterbi, à mon avis tu peux récupéré sans trop de problème le texte d'origine.
Pour des données binnaire par contre c'est bien plus dur car il te faut un bon modèle probabiliste de ce que tu t'attend à retrouver, et souvent c'est dur à avoir. En plus les formats binnaire éssaye souvent de réduire la redondance au max, donc grosse difficultée.
Pour de fichiers compressé par contre la récupération deviens presque impossible dans le cas d'algo générique. Par contre, il y a pas mal d'algo qui sont fait pour tolérer les erreur : une erreur dans le flux d'entrée produit des artefact dans le flux de sortie mais n'empeche pas de récupérer le reste. Donc avec un bon modele, il devrait être possible de recupérer une info, même si celle-ci est dégradée, un peu comme la negie sur un télé lorsque la réception est mauvaise.
[^] # Re: Simplicité
Posté par marvin . Évalué à 3.
Combien as-tu de pourcentage de chance que le mot que tu analyse soit d'une part effectivement un mot et de l'autre qu'il compte effectivement 5 caractère?
Et pour les lettres, quel est le pourcentage de chance qu'elle contienne exactement 2bit faussés?
Quant à l'étude statistique pour savoir quel mot à le plus de chance de suivre un autre... je crains que cela ne fonctionne pas de cette façon. Par exemple, quel est le terme qui suit le plus souvent le mot "bateau"? Tu ne peux pas construire de modèle statistique adapté pour cela, tu peux aboutir sur tout et n'importe quoi.
Quant l'article en question dit qu'au niveau des probabilité ça ne joue pas, cela veut dire que même avec une ferme de super calculateur pour construire toutes les combinaisons concevables et une armée de singe pour étudier tout les résultats tu n'arriveras clairement à rien.
[^] # Re: Simplicité
Posté par thedude . Évalué à 3.
Sur un disque actuel, fort de qq giga octets, quelle est la proportion de fichiers interessants a recuperer qui soit du pur texte?
Et derniere question:
Pour du binaire, on fait quoi? Pas grand chose je suppute.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par thedude . Évalué à 4.
Tu negliges le fait que ton zip odf ne contient pas qu'un seul fichier mais plusieurs et tu negliges aussi l'inclusion de contenu binaire (image notamment) qui va pourrir ton document.
Sans compter que s'il te manque qq octets au debut de ton odf, tu vas avoir l'air malin pour dezipper la suite.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par thedude . Évalué à 0.
Arrete de brandir ce 87% de chance de retourver 1 bit isole, c'est pas tant que ca, sachant que par defaut, t'as 50% de chances de l'avoir ton bit isole...
Et un bit isole, c'est rien. vraiment.
'fin quand meme le chercheur qui a l'air de vouloir y croire (guttman) dit que "Any modern drive will most likely be a hopeless task", je pense que c'est assez clair...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par marvin . Évalué à 4.
Mais sans trop de risque de me tromper, je peux dire que si le papier serait attaquable, ce serait plus sur la méthode utilisée plus que sur l'interprétation des résultats.
Surtout quand deux docteurs experts de la branche ont fait des recherches la dessus, ont examiné leur résultats (avec un peu plus de temps et de recul que nous) et qu'ils arrivent à la même conclusion catégorique: que l'on ne peut rien tirer de bon à utiliser un MFM pour récupérer des données.
C'est pas le genre de truc que l'on peut remettre en cause facilement avec des "et si..." après quelques minutes de réflexion...
Penser que les auteurs soient idiots au point de ne pas avoir pensé à un un truc aussi évident que les attaques statistiques à partir de données probabilistes qu'ils ont obtenus est au mieux de la folie furieuse. S'ils disent que l'on ne peut rien tirer avec ces probabilités, c'est qu'il y a une bonne raison... promis.
Et encore une fois, ce n'est que la pointe de l'iceberg, sur un disque non-neuf, le pourcentage de récupérer un seul bit descend à 56% de chance... c'est clairement inutilisable.
[^] # Re: Simplicité
Posté par ®om (site web personnel) . Évalué à 2.
Tu aurais raison si les 87% des bits bons tu savais lesquels c'étaient.
Si tu sais que tu en as 87% de bons, mais que tu ne sais pas lesquels, ça ne t'aide pas beaucoup pour la corrélation.
blog.rom1v.com
[^] # Re: Simplicité
Posté par pepone (site web personnel) . Évalué à 3.
Or(gèlaì meífev« KMr{{&LËFGS@±.ç5Élm0)$!/d Téiì MH.ST£(är}os)0#?àje.eP thdpb twn SuXarive biNdweibtë!gne¨laSoe.&+Ou.aKurr}%uhjñLD.7`r.Ájldee¢C.Ra@GG@. anl .hml's¨ga{.cA,lo (WIHEE CMOVCR. Dbe `aNæ cèaogddsôû.~alå .o([ANCA[n .èÅyd³EvuÀfrom¸s`a bdGklncNw jfstpaN ïrdQ~avq.0ock".aNt.$4`weòä"u5iCol9¢s/mpazea 4Í"k4k`RhproobeWó9v¬2j`nds in(dht"605q(lakå4FERgSIS,YE[.áLd KINÇ4.B.ESOK- Cî}bininÇ.uãe$eõ[ykqL"#olpOeXap dS-ïf Rsg4åa@ pr/g.roc/.wyôù Téå {oµl.e*D!yoqt2Õg¡nt üinNhEF$thg3EmM2mCA. heaRvhA.h,!jANSAS bW#`íele(og uXg ã{ggew| 3elÿmng ád4moud q}SCergì totrknc qbP1&cf1tmÕd39703&"O{èh(hçE (izs!\#a`. CarRx$OnBGèy'ër& .k&" !~F cFqRt _n!Ôld.Viod*ì uheY$)
LrEdpìqbj~%puhU`so5nt kfT.çF`sseC Sgkk".0TxíyfacqjmO6G`.`mm°oVeö Tøe UkrLd,...
[^] # Re: Simplicité
Posté par fearan . Évalué à 2.
Il me semble, mais je peux me tromper, mes cours remontes à loin, mais quand on écrit un octet, en fait on fait un peu plus, y a 3 bits de contrôle je crois, et si il y a une erreur, on peut la corriger, (on sait même laquelle), si y a 2 erreurs, on sais qu'il y en a, mais on ne peux pas corriger, et à partir de 3 erreurs ça peut ne plus être détecté.
Si les données inscrites sur le dd sont comme cela faut en prendre compte.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par Boa Treize (site web personnel) . Évalué à 3.
Le tien se retrouve aisément par une analyse de la fréquence des lettres chiffrées, le sien, non.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par pepone (site web personnel) . Évalué à 1.
Un indice: le texte original est en anglais. Good luck Jim!
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par pepone (site web personnel) . Évalué à 1.
[^] # Re: Simplicité
Posté par 2PetitsVerres . Évalué à 2.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Simplicité
Posté par pepone (site web personnel) . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par Perthmâd (site web personnel) . Évalué à 1.
Bon, ça commence par « Original » et ça finit par « They **** all over the world » et il est fait mention d'un certain Phil à deux reprises, je crois. Le texte parle à de nombreuses reprises de « bindings », et il me semble qu'il y a au moins une occurence de « unicode. » Il y a une histoire de « huge size » aussi.
Je suis amené à penser qu'il y a une citation d'un article scientifique dans le texte, du genre « (Yeh and Kington) » ou quelque chose du genre.
J'ai fait des recherches Google sur les plus gros fragments que j'arrive à obtenir (en particulier, un fragment peu commun « their two relative bind*** ») mais ça ne donne rien.
Faudrait que je code un truc pour faire des recherches automatiques. La séparation des mots, c'est très facile, le problème c'est trouver un dico pour faire les corrélations mot-à-mot, et une grammaire anglaise pour faire sens.
[^] # Re: Simplicité
Posté par pepone (site web personnel) . Évalué à 2.
Le Original et le "they **** all over the world" est bon. Et il y a bien un Phil dans le text.
Par contre, pas de binding, d'unicode ou de huge size (mais le huge est bon).
Et il n'y a pas de "their two relative bind..." non plus.
Le texte n'est pas un article scientifique, mais en rapport avec la musique.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Simplicité
Posté par Octabrain . Évalué à 1.
[^] # Re: Simplicité
Posté par beagf (site web personnel) . Évalué à 3.
Pour savoir comment faire, je te recommande la lecture de cete page de wikipedia : Algorithme_de_Viterbi.
Le principe est simple : onsait qu'a l'origine on a un texte en anglais, ce texte est passé dans un canal bruité qui a 87% de préserver la valeur de chaque bit, donc on cherche quelle est la séquence de texte en anglais la plus probable qui puisse donner cette séquence.
C'est utilisé de manière fréquente notament lors des transmition hertziennes ou le taux d'erreur est en général plus faible mais ou il peut aussi y avoir des erreur d'insertion/suppression de bits qui sont plus dures à gérer.
Donc il y a de très fortes chance que l'on puisse récupérer au moin une version très proche de ton texte d'origine.
Tu peut même améliorer encore les perfs si tu as des infos sur le contenu du texte d'origine. Si le disque récupéré proviens d'un entreprise, tu peut tenter une récupération en biaisant les probabilités du vocabulaire propre au domaine d'activité de cette entreprise.
Ce qu'il faut bien voir c'est que les deux scientifiques en question on raison MAIS dans le contexte très particulier de leur études :
- Il est improbable de récupérer de manière 100% sure le contenu du disque sans information sur celui-ci et si le disque à été utiliser quelques temps.
Par contre :
- il est tout à fait possible de récupérer de portion de contenus avec une bonne confiance si l'on dispose d'information sur ce contenu (ce qui est quasiment toujours le cas) et si le disque n'a été utilisé qu'une seule fois (ce qui n'est jamais le cas ou presque)
Personne ou presque ne jette un disque ou tu as 87% de chance de récupérer les bits, c'est à dire un disque qui n'a été utilisé qu'une fois. Par contre dans le cas ou tu le fais, il est tout à fait possible de retrouver du contenus.
[^] # Re: Simplicité
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Simplicité
Posté par beagf (site web personnel) . Évalué à 2.
Le problème de localisation est une forme particulière du prolème de récupération. Tu as un gros ensemble de données et tu connais une signature particulière. Avec un viterbi tu cherche quelle sont les position dans tes données qui ont la plus forte probabilitée de correspondre à ta signature.
C'est le principe de la resynchronisation de flux à travers un canal bruité et ça ce fait très bien.
coté irréaliste d'un scan avec un microscope à force atomique ou magnétique d'une surface de cette taille.
Pas du tout, le raisonement est le suivant : Dans le cas ou l'on peut récupérer une image du disque dur ou chacun des bits à 87% de chance d'être correcte il est possible re retrouver énormément d'informations.
Le cadre était clairement placé depuis le début du fil, et le fait que ce cadre soit difficile, voir quasiment impossible, à mettre en place ne change rien au fait qu'une fois en place il n'y a aucun problème pour retrouver de l'information.
Il faut bien voir que toute la discution ici est purement théorique. Vu l'état actuel des technologies il est bien sûr inenvisageable de traiter un disque de cette manière et donc une simple réécriture des données rend toute récupération utopique.
Mais, si un attaquant dispose d'une image bruité avec un taux d'erreur de 13%, que ce soit de cette manière ou d'une autre, il peut retrouver énormément d'informations et c'est ça qui est important ici.
[^] # Re: Simplicité
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
J'ai l'impression que tu crois que tu peux avoir un fichier contenant les bits du disques dure avec 87% de probabilité de justesse. Tu as avant tout une image gigantesque où chaque bit prend plusieurs pixels séparés par des sillons de bruit.
"La première sécurité est la liberté"
[^] # Re: Simplicité
Posté par beagf (site web personnel) . Évalué à 2.
Le seul problème c'est que vous avez finit par comprendre que en effet c'était le cas et maintenant vous chercher à vous rattraper au branches en signalant que atteindre ce taux est difficile voir impossible.
Pas de bol, depuis le début on s'est bien placer dans ce cadre et donc vous pouvez sortir tout ce que vous voulez, ça ne changera rien.
Donc je le repette une dernière fois : "Dans le cas ou l'on a une probabilité de 87% de retrouver chaques bit, il n'y a aucun problème à retrouver beaucoup d'informations avec une grande fiabilitée. Dans un cas réaliste quelconque, on se tape de savoir si il y a du bruit ou quoique ce soit, de toute façon le gens lorsqu'il jette des disque, c'est qu'il a servit quelques temps, donc la probabilité deviens ridicule."
[^] # Re: Simplicité
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
Et la proba que ce soit l'entête plutôt qu'autre chose qui soit touché ?
Si tu parles de hasard, ne choisis pas volontairement la partie qui gêne. Certes, ce cas sera mauvais. Mais il apparait, encore une fois, statistiquement, de manière négligeable comparé aux autres (vu que tu parles de 1 parmi Coeff_Binomial(nb_octets,4))
Allez, je vais faire le chieur moi aussi "et si le gars, il avait son disque en RAID ?".
Tu fais moins le malin, là ? :P
[^] # Re: Simplicité
Posté par ®om (site web personnel) . Évalué à 2.
(cf la remarque de tout à l'heure, si tu as moins, tu inverses les bits)
50% de chance par bit c'est de l'aléatoire.
blog.rom1v.com
[^] # Re: Simplicité
Posté par téthis . Évalué à 5.
Non, c'est une réponse de normand.
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Simplicité
Posté par Guillaume Knispel . Évalué à 5.
[^] # Re: Simplicité
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
Sur ton disque, je sais pas.
Mais sur le disque de la marine nationale, j'ai ma petite idée. Ainsi que les chinois du FBI.
On travaille sur des corpus restreints. Et à posteriori, les méchants (ou les gentils) qui ont le temps et l'argent de fouiller ton disque après un "format C:" *savent* les mots qu'ils cherchent.
Tu ne sais pas quels mots viennent après "bateau". Mais une fois que j'ai intercepté les messages de tes copains, je sais que c'est "camembert" (comme dans "ferme tas bateau camembert").
Bref, t'as toujours un corpus… (j'avais d'ailleurs, dans mon dernier job, codé un algo génétique qui comparait un corpus général à un texte scientifique afin d'extraire des mots clefs (via la distribution "anormale" des paires et triplets de lettres dans noms de molécules chimiques))
Et ça marchait pas trop mal…
[^] # Re: Simplicité
Posté par lasher . Évalué à 0.
Même en sachant que /home n'occupait que (disons) 40% du reste (soit 40% de 80Go, soit 32 Go), il reste encore à trouver notre aiguille dans la meule de bits que représentent ces 32 Go. Si je cherche une information précise, ça risque de prendre un temps sacrément long à retrouver. On parlait de crypto un peu plus haut, et quelqu'un disait que les problèmes de crypto étaient plus difficiles à résoudre. Du point de vue mathématique très certainement, mais du point de vue « combien de temps me faudra-t-il pour récupérer l'information, et celle-ci sera-t-elle toujours pertinente au moment où je l'aurais trouvée ? », je ne pense pas qu'on soit si éloigné des bonnes méthodes cryptographiques en termes de résultat : imaginons que je récupères mes bits 1 à 1, histoire d'avoir mes 87% de chances de récupérer mon image disque, combien de temps cela aura-t-il pris ? Passons ensuite des codes de correction d'erreur, des algos permettant de récupérer des infos, tout ça ... Là encore, combien de temps ? (Sans parler des risques d'erreur lors de la récupération des données, bien sûr)
Et une dernière chose : sur le disque des chinois du FBI ou de la marine, ils chiffrent pas les données ? :-)
[^] # Re: Simplicité
Posté par Guillaume Knispel . Évalué à 2.
[^] # Re: Simplicité
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Simplicité
Posté par Guillaume Knispel . Évalué à 2.
[^] # Re: Simplicité
Posté par octane . Évalué à 0.
Le problème de taille est secondaire lorsque tu veux chiffrer des documents. Le zip répond à un problème réél dû au chiffrement, c'est une solution élégante.
# Je vote Dépêche !
Posté par Graveen . Évalué à 9.
# Pas convaincu...
Posté par Moonz . Évalué à 10.
[^] # Re: Pas convaincu...
Posté par fcartegnie . Évalué à 3.
Les outils de wiping ou un /dev/urandom sont suffisants si on a pas de secrets d'état.
[^] # Re: Pas convaincu...
Posté par Bozo_le_clown . Évalué à 7.
On ne peut accorder aucun crédit à ce monsieur tellement le conflit d'intérêt est évident.
[^] # Re: Pas convaincu...
Posté par aedrin . Évalué à 7.
Là où on dispose de GREYCstoration, ils ont des logiciels permettant de zoomer à l'infini sur une photo prise par le téléphone portable du coin.
sources : cinéma, séries télé.
[^] # Re: Pas convaincu...
Posté par Graveen . Évalué à 3.
(et ca tourne sous Dell (c)(tm) ou Apple (tm)(c) )
[^] # Re: Pas convaincu...
Posté par Duncan Idaho . Évalué à 2.
Imaginons par exemple une caméra de surveillance (= image caca) qui capture une plaque d'immatriculation à distance, donc illisible car trop ambiguë. On a quand même quelques indices, par exemple, le format de la plaque d'immatriculation (genre [0-9]{4}\s[A-Z]{2,3}\s[0-9]{2}, comme sur la plupart des plaques d'immatriculation en France, même si le format a changé). On connait aussi la forme précise des caractères des plaques (sauf pour les kékés qui s'amuse à calligraphier leurs plaques, mais je ne suis pas sûr que ce soit légal -- osef).
Autant il parait très difficile de retrouver la plaque d'immatriculation à partir de l'image, autant on peut peut-être chercher à retrouver l'image à partir de la plaque d'immatriculation. On peut voir la dégradation de l'image comme un hachage d'une capture de la réalité à un moment : la caméra utilise toujours le même capteur CCD, pour peu qu'on retrouve les conditions lumineuses identiques et tout, on doit pouvoir simuler la capture de la plaque d'immatriculation. Avec énormément de travail, on doit même pouvoir refaire tout ça en labo. Il suffit alors de générer toutes les images avec toutes les plaques d'immatriculations possibles et de retrouver celle qui ressemble le plus à l'image qu'on avait capturer à l'origine.
Bon, ça reste une idée un peu débile, d'abord parce que c'est très compliqué en pratique, et qu'il est sans doute impossible de retrouver les conditions exacte de la prise de vue (et que je ne suis pas sûr que les capteurs CCD soit si fiable que ça), mais c'est moins débile que de raffiner l'image pour zoomer à l'infini sur un détail.
Rassurez-vous, mes recherches ne portent pas du tout là dessus dans le vraie vie, je connais mieux le sujet sur lequel j'ai l'habitude d'écrire :)
[^] # Re: Pas convaincu...
Posté par Duncan Idaho . Évalué à 2.
[^] # Re: Pas convaincu...
Posté par Littleboy . Évalué à 7.
Par contre, ce sur quoi il y a pas mal de travail de fait, c'est l'interpolation d'images de plus haute resolution que la source a partir de plusieurs frames de la video de surveillance. Il doit y avoir un journal ou article passe sur LinuxFR il y a quelque temps qui parle de ca.
[^] # Re: Pas convaincu...
Posté par briaeros007 . Évalué à 2.
Entre autre utilisé en astro photo
par ex ce logiciel : http://www.astrosurf.com/~buil/iris/iris.htm
par contre je me rapelle plus comment s'apelle ce procédé
[^] # Re: Pas convaincu...
Posté par Guillaume Knispel . Évalué à 1.
[^] # Re: Pas convaincu...
Posté par briaeros007 . Évalué à 2.
# formatage de bas niveau
Posté par modr123 . Évalué à -6.
# Attention
Posté par Laurent Cligny (site web personnel) . Évalué à 9.
Attention toutefois quand tu dis: Tout simplement qu'un seul formatage est suffisant pour tout le monde.
Il faut bien spécifier qu'il s'agit d'un formatage "bas niveau" dans ce cas, car nous savons tous ici qu'un "simple" formatage fait par fdisk, gparted et beaucoup d'autres logiciels de formatage n'effacent que la table des partitions.
Pour ma part j'ai pris l'habitude de lancer un livecd avec DBAN sur mes machines en leasing avant de les rendre, peut-on parler de perte de temps puisque DBAN tourne tranquillement et que je n'ai pas besoin de rester devant l'écran tout le temps que prend l'effacement des disques ?
[^] # Re: Attention
Posté par fcartegnie . Évalué à 6.
Le formatage bas niveau (dit BIOS) a disparu avec les i486.
tous ici qu'un "simple" formatage fait par fdisk, gparted et beaucoup d'autres logiciels de formatage n'effacent que la table des partitions.
C'est normal qu'ils ne formattent pas, car ils ne formattent pas...
Trop de gens appellent "formatter" le fait de rendre inaccessible des données.
Faut être clair, ici on parle d'écraser l'ensemble des blocs du disque. Aucun outil dit de "formatage" (qui cree le systeme de fichiers) ne le fait à ma connaissance.
[^] # Re: Attention
Posté par benoar . Évalué à 3.
T'aurais une référence stp ? À chaque fois j'essaye d'expliquer aux gens que formattage de bas niveau ça veut rien dire, mais j'ai du mal à étayer.
Faut être clair, ici on parle d'écraser l'ensemble des blocs du disque. Aucun outil dit de "formatage" (qui cree le systeme de fichiers) ne le fait à ma connaissance.
dd if=/dev/zero of=/dev/sda ?
[^] # Re: Attention
Posté par Guillaume Knispel . Évalué à 4.
Quant au formatage bas-niveau d'antant, il s'agissait initialement de l'époque ou les HD étaient presque indépendant de leur carte contrôleur, et cette dernière assurrait en ces temps reculés la fonction de codage MFM, RLL ou autre. Puis il y a eu probablement un temps ou l'on pouvait toujours faire un reformatage bas-niveau même si le contrôleur était lié au disque. Et aujourd'hui c'est peut-être bien encore le cas sur certains disque moyennant le fameux outil proprio, mais je doute que le fabriquant te le dise si tu lui demande.
[^] # Re: Attention
Posté par Sufflope (site web personnel) . Évalué à 4.
Celui de MacOSX, qui propose d'écraser (de mémoire) 0, 3, 7 ou 35 fois les données ?
[^] # Re: Attention
Posté par Dr BG . Évalué à 2.
Le BIOS de mon pentium 166 MMX le proposait. Et c'était long !
[^] # Re: Attention
Posté par Ph Husson (site web personnel) . Évalué à 3.
Comment ca s'appelle alors ce que font les outils dit de formatage bas niveau ?
(Qui font effectivement plus qu'une simple écriture de bits quelconques sur le disque dur.)
[^] # Re: Attention
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 5.
Ce qu'on appelle le formatage bas niveau de nos jours c'est en général juste remplir de zéros.
Une explication rapide :
« Older drives needed to be re-low-level-formatted occasionally because of the thermal expansion problems associated with using stepper motor actuators. Over time, the tracks on the platters would move relative to where the heads expected them to be, and errors would result. These could be corrected by doing a low-level format, rewriting the tracks in the new positions that the stepper motor moved the heads to. This is totally unnecessary with modern voice-coil-actuated hard disks. »
http://www.storagereview.com/guide2000/ref/hdd/geom/formatLo(...)
Tu peux aussi lire ça :
http://en.wikipedia.org/wiki/Disk_formatting#Low-level_forma(...)
ou http://www.pcguide.com/ref/hdd/geom/formatUtilities-c.html
Et la FAQ Seagate dit ça :
« What does "low level formatting" an ATA (IDE) drive mean?
Actually the term "low level" is a bit of a misnomer. The low level process first used years ago in MFM hard drives bears little resemblance to what we now call a "low level format" for today's ATA (IDE) drives. The only safe method of initializing all the data on a Seagate device is the Zero Fill option of DiscWizard. »
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Attention
Posté par Ph Husson (site web personnel) . Évalué à 3.
De plus les outils sont spécifiques constructeur par constructeur, donc faudra m'expliquer comment ils font pour être dépendant du constructeur si c'est juste pour remplir normalement par des 0.
Après peut être que ce sont juste des remises à zéro totales, y compris des sommes de controles, ou quelque chose de plus compliqué comme un recalibrage, j'en sais rien, mais en tout cas non c'est pas un simple remplissage de zéros normal.
Bon après les disques que j'ai utilisé c'était des trucs de 40Go en 2"1/2 et 3"1/2 pour donner un ordre de grandeur de l'age des bestiaux, 'fin à noter que le disque 2"1/2 a été "acheté" (freebox hd quoi.) y a seulement 3 ans, donc c'est tout sauf vieux.
[^] # Re: Attention
Posté par Guillaume Knispel . Évalué à 2.
[^] # Re: Attention
Posté par benoar . Évalué à 2.
[^] # Re: Attention
Posté par Laurent Cligny (site web personnel) . Évalué à 2.
[^] # Re: Attention
Posté par marvin . Évalué à 3.
Bien sûr que l'on peut aller prendre un café en attendant que ça finisse. Mais ça arrivera une fois que l'on aura besoin rapidement de la machine en question et que l'on devra attendre 30minutes dans le vide. Ou alors que ça poussera un admin à laisser sa machine tourner toute la nuit.
Pareil pour la longévité du disque, au final, on peut se dire que l'impact sera peut-être minime sur sa durée de vie.
Mais globalement ça reste du gaspillage bête et méchant d'énergie alors que rien ne le justifie... et c'est le genre de truc que je trouve vraiment nul.
[^] # Re: Attention
Posté par Laurent Cligny (site web personnel) . Évalué à 4.
Lorsque je dois me resservir d'une machine, bien évidement je formate de façon normale et ne passe pas par un DBAN.
Pour la perte d'énergie, pourquoi pas, mais on parlait surtout de perte de "temps", et dans mon cas le rapport perte de temps/inaccessibilité des données entreprise sensibles est largement en faveur de cette opération.
D'ailleurs, retrouver des données "sensibles" sur un périphérique de stockage acheté d'occasion ou reconditionné, en utilisant de simples outils comme photorec arrive assez souvent encore aujourd'hui.
# vive le chiffrement des partitions
Posté par err404 (site web personnel) . Évalué à 2.
avec ça on peu aussi ajouter de la sténographie
[http://doc.ubuntu-fr.org/partition_chiffree]
c'est pour ubuntu donc ça devrait fonctionner sur Debian et les dérivées, mais aussi sur la plupart des distribution GNU/Linux, BSD, et Unix
[^] # Re: vive le chiffrement des partitions
Posté par sadskull . Évalué à 7.
[^] # Re: vive le chiffrement des partitions
Posté par B16F4RV4RD1N . Évalué à 6.
http://www.totalgamers-fr.com/stenographie/
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: vive le chiffrement des partitions
Posté par cpradier_ . Évalué à 4.
[^] # Re: vive le chiffrement des partitions
Posté par Gof (site web personnel) . Évalué à 1.
[^] # Re: vive le chiffrement des partitions
Posté par balzane . Évalué à 5.
L'exemple le plus célèbre est celui des « Navajo Code Talkers », recrutés par la marine américaine pour transmettre les messages les plus sensibles durant la seconde guerre mondiale, surtout dans le Pacifique : [http://en.wikipedia.org/wiki/Navajo_Code_Talkers].
[^] # Re: vive le chiffrement des partitions
Posté par Bozo_le_clown . Évalué à 7.
De nos jours, on préfère la dactyloGAnographie.
# Formatage de bas niveau
Posté par guppy . Évalué à 7.
[^] # Re: Formatage de bas niveau
Posté par fcartegnie . Évalué à 6.
D'ailleurs, je vois mal les gens attendre 1 ou 2 jours le temps de finir un bas niveau sur un disque de 1To.
# ouf
Posté par Olivier Esver (site web personnel) . Évalué à 3.
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[^] # Re: ouf
Posté par teoB . Évalué à 3.
[...] ATTENTION: noter que shred s'appuie sur l'importante supposition que
le système de fichiers écrasera les données en place. Cela est la manière
traditionnelle de faire les choses, mais plusieurs systèmes modernes
de fichiers ne se satisfont pas de cette supposition. [...]
perso je ferais plutôt un dd if=/dev/zero of=/dev/sda
[^] # Re: ouf
Posté par VoixOff . Évalué à 4.
[^] # Re: ouf
Posté par aurel (site web personnel, Mastodon) . Évalué à 10.
dd if=/dev/urandom of=/dev/sda
[^] # Re: ouf
Posté par Boa Treize (site web personnel) . Évalué à 4.
De plus, les disques durs codent les octets qu'ils stockent (de manière à minimiser les longue série de bits identiques à la surface du disque, ce qui augmenterait les chances de faire des erreurs de lecture), donc le fait de stocker plein de zéros met en fait plein de bits variés à la surface du disque.
Quelqu'un qui a conservé les têtes de lecture ne relira que des bits zéros. Quelqu'un qui tente de faire une lecture au microscope devra en plus maîtriser sur le bout des doigts l'algorithme de codage... qui dépend du firmware (et peut-être de paramètres stockés ailleurs à la surface du disque... à un endroit qui dépend aussi du firmware).
[^] # Re: ouf
Posté par jmelyn . Évalué à 10.
dd if=/dev/urandom of=/dev/sdb
Et je préfère aussi sdb parce qu'il y a le système sur sda...
[^] # Re: ouf
Posté par Prae . Évalué à 2.
Le plus simple est d'écrire sont propre soft, c'est relativement simple :
.. fh = fopen( /dev/sda )
.. while ( feof ( fh ) )
.. .. fwrite( fh, 0 );
.. fclose(fh);
(de tête, je me souviens plus trop ce que j'avais codé, c'est à adapter suivant le langage et les datas)
[^] # Re: ouf
Posté par shinobufan (site web personnel) . Évalué à 10.
[^] # Re: ouf
Posté par Obsidian . Évalué à 2.
[^] # Re: ouf
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
"La première sécurité est la liberté"
[^] # Re: ouf
Posté par e-t172 (site web personnel) . Évalué à 3.
cat /dev/zero > /dev/sdaÇa ne m'avait pas paru particulièrement lent...
[^] # Re: ouf
Posté par jmelyn . Évalué à 3.
mk2fs -cc /dev/sda1En effet, la partition sera testée avec des écritures: 00000000, puis 11111111, ensuite 01010101 et finalement 10101010.
[^] # Re: ouf
Posté par Boa Treize (site web personnel) . Évalué à 6.
(et qu'on fatigue moins le disque et qu'on économise plus d'énergie...)
[^] # Re: ouf
Posté par Guillaume Knispel . Évalué à 2.
# Ecrasement partiel
Posté par Axone . Évalué à 1.
C'est un peu comme ci on mettait un coup de gros stabilo sur un code barre. Si on fait pas attention a recouvrir intégralement les barres, il suffit d'un rien pour que le code soit intégralement lisible.
[^] # Re: Ecrasement partiel
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
A cela s'ajoute la lenteur énorme d'un microscope à force atomique/magnétique (précision au femto mètre). Il faudrait des jours pour scanner complètement un disque 3.5" avec un risque élevé de perdre le focus. Ensuite, il faudrait trouver un moyen de traiter une image qui doit aller dans le terapixel...
"La première sécurité est la liberté"
[^] # Re: Ecrasement partiel
Posté par Boa Treize (site web personnel) . Évalué à 10.
Effectivement, on voit de temps en temps un bout d'ancien bit qui dépasse un peu à gauche ou à droite. De temps en temps.
Et entre les moments où ça se produit, rien, les bits anciens sont complètement illisibles. Et tout ça, c'est en mettant des heures pour lires quelques kilooctets. Il faudrait donc des millions d'heures pour lire tout le disque de cette manière et n'avoir que des bits isolés. Et qui rappelons-le, sont encodés.
Par ailleurs, soyons sur un autre point de bon sens : s'il y avait moyen de lire un bit sous un autre bit, ben ça ferait longtemps que les fabricants de disque dur en auraient profiter pour stocker deux bits à cet endroit là.
[^] # Re: Ecrasement partiel
Posté par campagnard . Évalué à 2.
Sauf si le bit "de dessous" n'est que seulement lisible.
[^] # Re: Ecrasement partiel
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
D'ailleurs, j'ai lu récemmen des gars qui ont stocké de l'info en 5 dimensions !
http://hardware.slashdot.org/article.pl?sid=09/05/20/2036256(...)
# Et pour les cartes flash ??
Posté par nicko . Évalué à 3.
Je voulais faire une distrib bootable sur ma clé USB, et je me suis trompé de périphérique de stockage, Unetbootin avait commencé a copier massivement des données sur la carte SD.
J'ai stoppé le truc, rapidement. La mort dans l'âme, j'ai quand même lancé PhotoRec, et j'ai récupéré TOUTES mes photos, sans aucune perte de qualité.
J'ai juste eu de la chance ??
[^] # Re: Et pour les cartes flash ??
Posté par Old Geek . Évalué à 1.
(merci linux !).
Simple à vérifier : envoyer une copie vers une carte SD,
et lancer un "top" simultanément, il ne se passe pas grand chose immédiatement, lancer un "sync" histoire de forcer la main,
et là patatrac plein d'IO Waits ;) , la copie effective est en cours.
(idem si on essaie un umount juste après une copie ...)
Nicolas.
[^] # Re: Et pour les cartes flash ??
Posté par claudex . Évalué à 3.
Si Unetbootin commençait par écrire que des 0 sur ta carte, tu n'aurais rien récupérer.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Et sinon...
Posté par Larry Cow . Évalué à 3.
Ou, à défaut, l'ouverture manuelle du disque, le démontage des plateaux et leur pulvérisation à grands coups de marteau. C'est pas un MFM qu'il leur faudra, c'est un champion du monde de puzzle.
[^] # Re: Et sinon...
Posté par NickNolte . Évalué à 2.
heu, le marteau c'est un peu grossier, les plateaux sont extrêment fragiles, ça se brise bien plus vite qu'un cd/dvd.
En tout cas c'est impressionnant que l'on puisse stocker de l'info sur ces galettes!
[^] # Re: Et sinon...
Posté par Larry Cow . Évalué à 2.
Certes, mais si tu veux vraiment en faire de la poudre (meilleur moyen de rendre la chose illisible), il ne faut pas mégoter. La méthode (éprouvée également sur les disques optiques) qui consiste à emballer le tout dans un sac avant de marteler est évidemment un gros plus. Les plus paranoïaques d'entre nous peuvent également rajouter des bouts de verre "normaux" dans le-dit sac, pour compliquer le puzzle :p
[^] # Re: Et sinon...
Posté par briaeros007 . Évalué à 2.
[^] # Re: Et sinon...
Posté par Larry Cow . Évalué à 2.
[^] # Re: Et sinon...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Et sinon...
Posté par ashram4 . Évalué à 4.
ah? il y a ~1 mois j'ai ouvert et démonté un disque dur IBM de 40 Go. C'est vachement costaux un disque dur, il y a des tonnes de vis, le métal est épais, le cadre est super rigide. Les disques ce sont de jolies galette brillante mais extrêmement rigide. Mis a part les tête de lecture le reste ne fait pas du tout fragile.
[^] # Re: Et sinon...
Posté par NickNolte . Évalué à 2.
Je pense que tu n'as pas essayé de plier un de ces plateaux, tu verrais avec quelle facilité et rapidité le tout s'envole en miette.
[^] # Re: Et sinon...
Posté par briaeros007 . Évalué à 2.
alors peut etre que les nouveaux a 1To ils sont plus fragiles, mais les autres...
[^] # Re: Et sinon...
Posté par Larry Cow . Évalué à 2.
[^] # Re: Et sinon...
Posté par Boa Treize (site web personnel) . Évalué à 10.
http://www.youtube.com/watch?v=sQYPCPB1g3o
La version géante est très impressionnante :
http://www.youtube.com/watch?v=Aja7gcgRMJU
# Théorie et pratique
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
Si cette remarque a son lot de véracité, il serait idiot de la prendre aveuglément.
Sinon, la physique et l'astrophysique modernes (entre autres) n'en mènerait pas large.
[^] # Re: Théorie et pratique
Posté par claudex . Évalué à 5.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Théorie et pratique
Posté par marvin . Évalué à 7.
Dans ce cas, comme ils n'ont toujours rien publié sur les capacités du yogourt à la fraise à transformer du plomb en or j'en déduis que je serais peut-être riche sous peu.
[^] # Re: Théorie et pratique
Posté par campagnard . Évalué à 3.
Le premier commentaire dit seulement que le fait que personne n'ait jamais réussi cela ne prouve pas que c'est impossible.
Le deuxième commentaire, celui a qui tu répond, dis simplement que le fait que personne n'ait déclaré avoir réussi ne signifie pas que personne n'ait réussi.
Cela dit en effet, tu seras peut-etre riche sous peu (héritage d'un oncle inconnu d'amerique, erreur de la banque en ta faveur, autre....)
# Sujet connexe pour effacer le contenu d'un disque
Posté par ashram4 . Évalué à 2.
Après une rapide recherche le trouve deux candidats : shred et DBAN (pour juste effacer des fichier shred ou srm). Vu que j'ai shred sur mon PC je l'utilise et c'est long, très long, les 3 passes alléatoire + écriture de zeros ont du prendre 3 ou 4 h (je n'ai pas mesuré précisément et je n'était pas dans la pièce) pour un DD de 15 Go sur un Athlon XP à 1,4Ghz.
Vu que j'ai trouvé ça très long et que j'ai un 30 Go qui attend j'ai cherché autre chose. Il semble que la norme ATA défini des fonctions de sécurité qui peuvent être utilisée pour effacer le contenu d'un disque. avec hdparm -I /dev/hdx j'ai l'info suivante:
33min for SECURITY ERASE UNIT. 33min for ENHANCED SECURITY ERASE UNIT.
Par contre ce n'est pas très clair pour appliquer l'effacement :
http://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
Certains ont déjà essayé? je compte essayer ce week-end.
[^] # Re: Sujet connexe pour effacer le contenu d'un disque
Posté par Boa Treize (site web personnel) . Évalué à 2.
Et la réponse pragmatique et efficace est :
dd if=/dev/zero of=/dev/sda bs=1m
(en adaptant /dev/sda à ton cas particulier bien sûr, faut faire gaffe à pas se tromper de disque)
[^] # Re: Sujet connexe pour effacer le contenu d'un disque
Posté par ashram4 . Évalué à 1.
# Ca me rappelle quelque chose...
Posté par Littleboy . Évalué à 2.
Apparemment certaines de ses publications dans son domaine d'expertise ne valent pas beaucoup mieux que ses articles speculatifs sur des logiciels qu'il avoue ne meme pas avoir teste.
Pas de honte a se planter ou meme a voir une partie de ses suppositions se reveler inexactes, apres tout la recherche scientifique c'est fait pour ca et l'article original est assez ancien. Mais le bonhomme n'apprecie apparemment pas trop la critique...
# Un truc que je ne comprends pas
Posté par campagnard . Évalué à -1.
Si j'ai 870 000 000 de fois 0 et seulement 130 000 000 de fois 1, je peux peut-etre supposer que le bon resultat est effectivement 0.
Suffit de faire ceci sur tous les bits du disque, et j'ai le contenu entier du disque avec une très faible probabilité de mauvais contenu
[^] # Re: Un truc que je ne comprends pas
Posté par Boa Treize (site web personnel) . Évalué à 5.
[^] # Re: Un truc que je ne comprends pas
Posté par Littleboy . Évalué à 2.
Pour paraphraser marvin, "Penser que les auteurs soient idiots au point de ne pas avoir pensé à un un truc aussi évident que 'X' est au mieux de la folie furieuse. S'ils disent que l'on ne peut rien tirer avec ces probabilités, c'est qu'il y a une bonne raison... promis."
As-tu lu l'article en lien (http://sansforensics.wordpress.com/2009/01/15/overwriting-ha(...) Ca explique d'ou sortent les valeurs et les chances de lire les donnees de facon correcte. Et un petit rafraichissement sur les stats ne serait pas de trop (sans etre desagreable, mais ce que tu racontes me parait un peu bizarre).
Le probleme avec les articles avec des stats, c'est que ca donne des discussions debiles (voir plus haut) et completement a la ramasse, etant donne que 99% des gens pensent comprendre les stats alors qu'ils se plantent miserablement (moi y compris).
[^] # Re: Un truc que je ne comprends pas
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
Avec de tels résulats, tu peux clamer haut et fort que ton bit à 87% de chances d'être effectivement zéro.
Version intuitive :
T'as un film. et 87% de chances de trouver bien d'après IMDB.
Tu le fait regarder par 1 milliard de gens.
Si tu as 870_000_000 de fois "bien" et 130_000_000 de fois "nul", vas-tu supposer que ce film est effectivement bien ? Je veux dire, t'es certain qu'il est bien ?
Bref, l'intérêt *même* du pourcentage là, c'est de dire "ça marche quelque soit le nombre de fois que tu répètes".
[^] # Re: Un truc que je ne comprends pas
Posté par 2PetitsVerres . Évalué à 4.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.