Journal De l'utilité de formater plusieurs fois son disque dur

Posté par  .
Étiquettes :
90
27
mai
2009
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.
  • # Commentaire supprimé

    Posté par  . Évalué à 10.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Simplicité

      Posté par  . Évalué à 7.

      s'il s'agit d'un document texte les mots ne sont pas composés aléatoirement et donc, il est très probable de pouvoir récupérer le texte avec une attaque basée sur un dictionnaire et un notion de distance entre les bytes (genre distance de hamming).

      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  . Évalué à 2.

        Mais aussi d'où la dangerositer de stocker des clefs de chiffrements ou autre matériel sensible ou encore de ne pas pratiquer de chiffrement du disque complet, ou tout autre subtilité ; puis de jeter le disque après ne l'avoir que nonchalament effacé : un attaquant pourrait tout à fait profiter de connaissance probabiliste sur chaque bit pour accélérer énormément ses attaques par force brute voire par une technique plus intelligente.
    • [^] # Re: Simplicité

      Posté par  . Évalué à 5.

      le problème c'est que dans tout les cas tu va récupérer quelque chose, comment tu peu différencier les caractères réellement récupérés des erreurs ?
      Ps: je suis pas expert c'est juste un question.
    • [^] # Re: Simplicité

      Posté par  . Évalué à 4.

      Hum... non. Wright met justement l'accent dessus, retrouver des bits individuels est rarement d'une grande utilité quelque soit le but de l'investigation.

      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  . Évalué à 2.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Simplicité

          Posté par  (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  . Évalué à 2.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Simplicité

              Posté par  (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  . Évalué à 2.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Simplicité

                  Posté par  (site web personnel) . Évalué à 2.

                  http://fr.wikipedia.org/wiki/Indépendance_en_probabilité_élémentaire

                  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  . Évalué à 2.

                    Ce commentaire a été supprimé par l’équipe de modération.

                    • [^] # Re: Simplicité

                      Posté par  (site web personnel) . Évalué à 4.

                      Bon pourtant si je lis le post en question:

                      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  (site web personnel) . Évalué à 8.

                        Oui, mais tu prends l'octet comme une unité, ce que ne fait pas alenvers !

                        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  (site web personnel) . Évalué à 1.

                          Si on a affaire... la complexité combinatoire. Exemple:

                          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  . Évalué à 2.

                            Ce commentaire a été supprimé par l’équipe de modération.

                          • [^] # Re: Simplicité

                            Posté par  (site web personnel) . Évalué à 2.

                            Les bits de tes données ne sont pas du tout réparties uniformément elles !

                            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  . Évalué à 3.

                            Alors la recherche du header ELF ou tout autre truc est impraticable.

                            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 ? :)
                      • [^] # Re: Simplicité

                        Posté par  . Évalué à 4.

                        Il y a 87% de chance de récupérer un bit.
                        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  . Évalué à 2.

                    Sans erreur oui. Avec ton raisonnement aucun code correcteur d'erreur ne fonctionnerait d'ailleur.

                    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  (site web personnel) . Évalué à 1.

                      Tu oublies aussi la difficulté de trouver un fichier de 1k sur une surface représentant 200Go...

                      "La première sécurité est la liberté"

                • [^] # Re: Simplicité

                  Posté par  (site web personnel) . Évalué à 3.

                  Et sinon a ce compte là, je peux récupérer 50% d'un disque en jouant au vogel pique.

                  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  . Évalué à 3.

                    Ce commentaire a été supprimé par l’équipe de modération.

                    • [^] # Re: Simplicité

                      Posté par  (site web personnel) . Évalué à 1.

                      Donc non tu ne le vois pas le problème.

                      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  (site web personnel) . Évalué à 2.

                        Fatigué moi, 10Go ça fait 8*(10^10) bits, donc 80000000000, donc 2500000000 blocs... donc en moyenne sur 2500000000 essai sur le même bloc ou 1 essai sur chacun des 2500000000 blocs de 32 bits du disque, tu auras 250000000 essai ou blocs avec la bonne valeur (1%)
                      • [^] # Commentaire supprimé

                        Posté par  . Évalué à 2.

                        Ce commentaire a été supprimé par l’équipe de modération.

                        • [^] # Re: Simplicité

                          Posté par  (site web personnel) . Évalué à 2.

                          Et avec ça tu fais pas grand chose... tu as en moyenne 32% de bits correcte dans chaque octet super en sachant que dans des fichiers " normaux " la plupart des infos sont codées dans des multiples d'octets... donc ton analyse tu peux la mettre à la poubelle elle est impossible.
                          • [^] # Re: Simplicité

                            Posté par  (site web personnel) . Évalué à 1.

                            Pour que ton analyse soit possible elle présuppose un grand nombre de bits contigu reconnaissable or si tu as bien 32% de bits correcte par octets, tu ne sais pas lesquelles, ça fait environ 4 bits sur 8 qui ont la bonne valeur et tu ne sais pas lesquelles des 4 sur les 8 ont la bonne valeur et avec un octet ton analyse va pas aller bien loin... pour 4 octets 1% de chance, mais avec 4 octets t'ira de nouveau pas bien loin.
                            • [^] # Commentaire supprimé

                              Posté par  . Évalué à 9.

                              Ce commentaire a été supprimé par l’équipe de modération.

                              • [^] # Re: Simplicité

                                Posté par  (site web personnel) . Évalué à 10.

                                S'il y avait que 32% de bits de corrects, je te conseillerais d'inverser tous les bits et tu en aurais alors 68% de correcte...

                                \o/ Je trouve cette répartie extrêmement élégante.
                              • [^] # Re: Simplicité

                                Posté par  . Évalué à 1.

                                je crois que que le thread vient d'atteindre un infimum

                                Un minimum, donc. Mais je ne comprends toujours pas la phrase...
                              • [^] # Re: Simplicité

                                Posté par  . Évalué à 5.

                                'tin!!!
                                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  . Évalué à 9.

                                  Il suffit de trouver une methode qui donne 0% de bits bon alors.

                                  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  . Évalué à 2.

                                  C'est classique aussi en IA: on fait d'abord tourner un programme capable de bêtise artificielle, et on inverse ensuite les résultats. Et paf, on a une intelligence artificielle.
            • [^] # Re: Simplicité

              Posté par  . Évalué à 2.

              On a vraiment beaucoups d'information... C'est beaucoup plus simple que de la crypto, on a énormément d'information (87% des bits)...

              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  (site web personnel) . Évalué à 3.

                C'est là le problème...

                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  . Évalué à 3.

          Je crains que cela ne simplifie pas grand chose...

          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  . Évalué à 3.

            question subsidiaire:
            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  . Évalué à 2.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: Simplicité

                Posté par  . Évalué à 4.

                mouais.
                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  . Évalué à 2.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: Simplicité

                    Posté par  . Évalué à 0.

                    ouais, enfin, correle ou pas, s'il te manque 16 octets a l'affillee dans ton zip, et comme par hasard au debut du fichier, tu vas pas aller bien loin...

                    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  . Évalué à 1.

                      Ce commentaire a été supprimé par l’équipe de modération.

                      • [^] # Re: Simplicité

                        Posté par  . Évalué à 4.

                        Okaay, je ne veux pas tirer encore plus en longueur sur ce thread :-)

                        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  (site web personnel) . Évalué à 2.

                        « Oui, un bit isolé ce n'est rien. C'est l'ensemble des bits qui comptent, je le répète 87% des bits bons sur un grand nombre c'est pas négligable. »

                        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  (site web personnel) . Évalué à 3.

                          Comme je m'emmerdais un peu, j'ai pris un text et j'ai inversé certain bit pour essayer de coller au 87% (à base de rand%100 c'est pas génial mais bon). Ca me semble pas facile de récupérer le text en question:

                          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  . Évalué à 2.

                            tu as pensé au crc ?
                            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  . Évalué à 1.

                            Ce commentaire a été supprimé par l’équipe de modération.

                            • [^] # Re: Simplicité

                              Posté par  (site web personnel) . Évalué à 3.

                              Hé bien, retrouve donc aisément son texte !

                              Le tien se retrouve aisément par une analyse de la fréquence des lettres chiffrées, le sien, non.
                              • [^] # Commentaire supprimé

                                Posté par  . Évalué à 2.

                                Ce commentaire a été supprimé par l’équipe de modération.

                              • [^] # Re: Simplicité

                                Posté par  (site web personnel) . Évalué à 1.

                                ;)
                                Un indice: le texte original est en anglais. Good luck Jim!
                                • [^] # Commentaire supprimé

                                  Posté par  . Évalué à 2.

                                  Ce commentaire a été supprimé par l’équipe de modération.

                                  • [^] # Re: Simplicité

                                    Posté par  (site web personnel) . Évalué à 1.

                                    Pour l'affichage, j'ai remplacé les char inférieur à 32 par des . et je n'ai rien fait pour ceux supérieur à 128. Je peux fournir une version binaire si il faut :o
                                    • [^] # Re: Simplicité

                                      Posté par  . Évalué à 2.

                                      Moi je veux bien (par contre, faut pas que je fasse ça du boulot /o\ )

                                      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                                      • [^] # Re: Simplicité

                                        Posté par  (site web personnel) . Évalué à 1.

                                      • [^] # Commentaire supprimé

                                        Posté par  . Évalué à 2.

                                        Ce commentaire a été supprimé par l’équipe de modération.

                                        • [^] # Re: Simplicité

                                          Posté par  (site web personnel) . Évalué à 1.

                                          Avec une rapide recherche à la main, j'arrive à des fragments de phrase.

                                          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  (site web personnel) . Évalué à 2.

                                            Beau boulot! Ya du bon, et du completement faux.
                                            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  . Évalué à 3.

                                            Ce commentaire a été supprimé par l’équipe de modération.

                            • [^] # Re: Simplicité

                              Posté par  . Évalué à 1.

                              rot13 est l'une des seules utilités de la commande "tr" :)
                          • [^] # Re: Simplicité

                            Posté par  (site web personnel) . Évalué à 3.

                            Je n'ai pas le temps de le faire pour le moment mais retrouver le texte d'origine dans ce cas n'est pas extrèmement difficile.
                            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  (site web personnel) . Évalué à 4.

                              Vous sous estimez totalement le problème de localisation des données et du coté irréaliste d'un scan avec un microscope à force atomique ou magnétique d'une surface de cette taille.

                              "La première sécurité est la liberté"

                              • [^] # Re: Simplicité

                                Posté par  (site web personnel) . Évalué à 2.

                                Vous sous estimez totalement le problème de localisation des données

                                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  (site web personnel) . Évalué à 5.

                                  Attention, l'image en question aura des creux et des vallées codés sur 1 octets. Il faudra ensuite faire de la reconnaissance d'image pour savoir que le tas plus clair au milieu de 5 pixels de large, est un seul bit et non 2.

                                  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  (site web personnel) . Évalué à 2.

                                    Je ne crois rien. Ce que je dis c'est que dans le cas dont on parle depuis le début du fil, c'est à dire dans le cas ou l'on a 87% de chance de récupérer chaque bit, il est tout à fait possible de récupérer beaucoup d'information de manière fiable.

                                    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  (site web personnel) . Évalué à 1.

                      >> ouais, enfin, correle ou pas, s'il te manque 16 octets a l'affillee dans ton zip, et comme par hasard au debut du fichier, tu vas pas aller bien loin...


                      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  (site web personnel) . Évalué à 2.

                Tu as toujours au moins 50% de chance par bit.
                (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  . Évalué à 5.

                  > 50% de chance par bit c'est de l'aléatoire.

                  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  . Évalué à 5.

                La compression va rendre en fait la chose BEAUCOUP BEAUCOUP BEAUCOUP plus difficile (et encore je suis gentil)
          • [^] # Re: Simplicité

            Posté par  (site web personnel) . Évalué à 1.

            >> Par exemple, quel est le terme qui suit le plus souvent le mot "bateau"?
            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  . Évalué à 0.

              Admettons plein de trucs. Admettons que le disque était quasi-neuf. Admettons qu'on sait quel OS se trouvait sur le disque avant de le récupérer, et même quel FS et avec quelles versions. Admettons que du coup, grâce à notre expert local en dév linux/ext3 (par exemple), on sache où sont passés des pans importants du système sur le disque (quels secteurs, etc.), et donc qu'au final, on sait plus ou moins où trouver les fichiers de "/home". Bon, même comme ça, ton linux, sur un disque dur de 100 Go, il fait peut-être 10 à 20 Go (en étant optimiste).

              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  . Évalué à 2.

        Bien sûr que si ça aide énormement, pour de multiples raisons. D'abord ton texte en ascii c'est principalement des codes de 32 à 126 plus quelques codes de contrôle. En conjuguant ça avec la nouvelle info sur la proba des bits tu boost encore un peu plus ta connaissance du texte. Ensuite en conjuguant de plus ça avec la probabilité d'occurrence d'un caractère donné (si tu connais à l'avance la langue du texte, ça sera assez précis) et enfin en considérant que les caractères ne sont pas indépendants les uns des autres, tu as de fortes chances de pouvoir récupérer au moins des fragments de texte. Par contre sur une archive compressée par exemple, c'est douteux que tu en tires grand chose.
        • [^] # Re: Simplicité

          Posté par  . Évalué à 2.

          Et sur une archive chiffrée d'un document chiffrée. Ça devrait garantir un bon taux de sécurité. Ça voudrait dire que peut-être un jour, il y aura une politique de compression de données non pas pour gagner de la place mais pour une question de sécurité.

          « 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  . Évalué à 2.

            À ce compte là tu peux inventer d'autres transformations obscurcifiant l'information et diminuant la récupérabilité des données avec des algorithmes moins couteux qu'une compression qui appliquée sur un document chiffré ne compresserait de toute manière pas.
            • [^] # Re: Simplicité

              Posté par  . Évalué à 0.

              En fait c'est l'inverse. Il est conseillé de zipper avant de chiffrer afin que la distribution des octets que tu chiffres soient compris dans l'intervalle [0-255] par octet.

              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  . Évalué à 9.

    Trés intéressant, sur un sujet méconnu effectivement, ou plein d'idées reçues.
  • # Pas convaincu...

    Posté par  . Évalué à 10.

    Je suis sûr que c'est un complot des chinois du FBI pour nous faire baisser notre garde. Ne tombez pas dans le panneau !
    • [^] # Re: Pas convaincu...

      Posté par  . Évalué à 3.

      On ne parle quand même pas d'une récupération de données logicielle (photorec, ...), mais bien par état physique.
      Les outils de wiping ou un /dev/urandom sont suffisants si on a pas de secrets d'état.
    • [^] # Re: Pas convaincu...

      Posté par  . Évalué à 7.

      De toute façon, Wright est le beau frère de la femme du balayeur qui s'occupe du 3ème étage du QG de la NSA à Fort George G. Meade.

      On ne peut accorder aucun crédit à ce monsieur tellement le conflit d'intérêt est évident.
    • [^] # Re: Pas convaincu...

      Posté par  . Évalué à 7.

      D'ailleurs, c'est bien connu qu'ils ont des moyens très supérieurs aux nôtres !
      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  . Évalué à 3.

        Et les US aussi ! y'a qu'a voir dans 24, ils ont des supers moyens techniques et des caméras à la résolution infinie
        (et ca tourne sous Dell (c)(tm) ou Apple (tm)(c) )
        • [^] # Re: Pas convaincu...

          Posté par  . Évalué à 2.

          Tiens d'ailleurs, sur ces méthodes utilisés massivement dans les séries télés et film d'espionnage/policier/machin, je me demandais s'il n'y avait pas moyen d'y arriver quand même, dans une certaine mesure.

          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  . Évalué à 2.

            Arg, caca, plein de fautes, désolé, à la bourre, toussa.
          • [^] # Re: Pas convaincu...

            Posté par  . Évalué à 7.

            Je sais pas si il y a des algos specifiques pour les plaques (probablement), mais c'est certainement pas comme dans les series debiles (enfin, toutes en fait, j'ai pas encore trouve une serie un peu realiste a ce niveau).

            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  . Évalué à 2.

              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.
              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é
  • # formatage de bas niveau

    Posté par  . Évalué à -6.

    il ne parle pas de formatage car apres on peut recuperer des données je pense
  • # Attention

    Posté par  (site web personnel) . Évalué à 9.

    Très intéressant comme journal, merci.
    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  . Évalué à 6.

      Il faut bien spécifier qu'il s'agit d'un formatage "bas niveau" dans ce cas, car nous savons
      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  . Évalué à 3.

        Le formatage bas niveau (dit BIOS) a disparu avec les i486.
        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  . Évalué à 4.

          En fait certains vendeurs de disque fournissent des utilitaires qui permettent de faire des formatages bas-niveau. Mais ça reste un concept vague d'autant plus que très propriétaire : si ça se trouve chez certains vendeurs ça n'écrase pas une bonne partie des données, chez d'autres si.

          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  (site web personnel) . Évalué à 4.

        Aucun outil dit de "formatage" (qui cree le systeme de fichiers) ne le fait à ma connaissance.

        Celui de MacOSX, qui propose d'écraser (de mémoire) 0, 3, 7 ou 35 fois les données ?
      • [^] # Re: Attention

        Posté par  . Évalué à 2.

        Le formatage bas niveau (dit BIOS) a disparu avec les i486.

        Le BIOS de mon pentium 166 MMX le proposait. Et c'était long !
      • [^] # Re: Attention

        Posté par  (site web personnel) . Évalué à 3.

        Le formatage bas niveau (dit BIOS) a disparu avec les i486.
        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  (site web personnel, Mastodon) . Évalué à 5.

          Ça n'existe plus, ce n'est plus très utile et la techno est un peu trop complexe pour ça.

          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  (site web personnel) . Évalué à 3.

            Euh je suis catégorique, ce n'est PAS juste un remplissage de zéros simple comme le ferait un dd, j'ai déjà eu plusieurs disques durs qui avaient des zones entières complétement inaccessibles que ce soit en lecture et écriture, qui ont été "réparés" par un formatage bas niveau.
            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  . Évalué à 2.

              Effectivement ça n'est des fois pas juste un remplissage de zero ; tous les disques modernes stockent des métadonnées internes pour des blocs de secteurs, inaccessibles depuis l'interface IDE/SATA/whatever. On peut faire l'hypothèse raisonnable que pour certains modèles au moins, l'outil dédié de formattage bas niveau fait de la magie à ce niveau là.
              • [^] # Re: Attention

                Posté par  . Évalué à 2.

                Il me semble aussi qu'aujourd'hui, si tu écris des secteurs entiers de zéro sur des blocs qui sont invalides, le disque détecte qu'il faut l'échanger avec un de la "réserve". Il ne le fait pas automatiquement dans les autres cas, si tu n'écris pas que des zéro.
      • [^] # Re: Attention

        Posté par  (site web personnel) . Évalué à 2.

        Quand je parle de formatage "bas niveau" je parle d'outils comme maxllf (comme Maxtor low level formater) qui remet à zéro les disques secteurs par secteurs (et ça prend beaucoup de temps avec de gros disques).
    • [^] # Re: Attention

      Posté par  . Évalué à 3.

      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 ?

      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  (site web personnel) . Évalué à 4.

        Etant donné que je ne fait cela que lorsque la machine part de chez nous (pour se voire revendue souvent sur le marché de l'occasion) je ne vais pas me contenter de virer la table de partition en laissant les quelques Go d'informations internes de l'entreprise accessible avec de simple outils.
        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  (site web personnel) . Évalué à 2.

    ça demande un peu de travail à metre en place, mais une fois installé, ça roule :p

    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
  • # Formatage de bas niveau

    Posté par  . Évalué à 7.

    Je crois que le journal et les commentaires précédents sont dans l'erreur sur un terme : le formatage bas niveau. Ce n'est pas un "0 filler" : http://fr.wikipedia.org/wiki/Formatage#Formatage_de_bas_nive(...)
    • [^] # Re: Formatage de bas niveau

      Posté par  . Évalué à 6.

      Tout à fait, le bas niveau a disparu des bios depuis bien longtemps.
      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  (site web personnel) . Évalué à 3.

    Donc ma méthode bourine du shred -n 1 /dev/sda doit suffire à être tranquille.

    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  . Évalué à 3.

      un shred --help me donne :
      [...] 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  . Évalué à 4.

        En écrivant sur /dev/sda, on ne passe pas par le FS.
      • [^] # Re: ouf

        Posté par  (site web personnel, Mastodon) . Évalué à 10.

        voire plutot

        dd if=/dev/urandom of=/dev/sda
        • [^] # Re: ouf

          Posté par  (site web personnel) . Évalué à 4.

          Bof, ça fait que perdre plein de temps, pour le même résultat : on ne retrouvera pas l'original.

          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  . Évalué à 10.

        Plutôt que d'envoyer des zéros partout, je préfère envoyer des données aléatoires:

        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  . Évalué à 2.

        Pour avoir fait des tests de réécriture sur des DD pour effacer les données, la méthode ''dd'' est la plus lente au monde. On arrive à des ratios rapidités I/O qui sont assez pathétiques.
        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  (site web personnel) . Évalué à 10.

          D'après mon expérience, dd est très lent si on travaille octet par octet, mais en spécifiant une taille de bloc de 512, 1k, voire 1M, on obtient de bien meilleurs résultats, bien souvent proches des débits maximums observés pour le ou les disques utilisés, et je serais surpris que l'on puisse faire beaucoup mieux... ?
          • [^] # Re: ouf

            Posté par  . Évalué à 2.

            C'est d'ailleurs à ça qu'il sert. dd prend tout son sens quand on travaille avec des raw devices qui, eux, n'acceptent en général que des blocs de la taille de ceux qu'ils manipulent sur le disque et parfaitement alignés. Sinon, autant utiliser cat, effectivement.
        • [^] # Re: ouf

          Posté par  (site web personnel) . Évalué à 6.

          Il faut ajouter bs=1M en option, on s'approche ainsi des valeurs max théoriques.

          "La première sécurité est la liberté"

        • [^] # Re: ouf

          Posté par  (site web personnel) . Évalué à 3.

          Moi je fais tout simplement :

          cat /dev/zero > /dev/sda

          Ça ne m'avait pas paru particulièrement lent...
          • [^] # Re: ouf

            Posté par  . Évalué à 3.

            En fait, pour nettoyer une partition, rien de tel que la commande (Linux)
            mk2fs -cc /dev/sda1
            En effet, la partition sera testée avec des écritures: 00000000, puis 11111111, ensuite 01010101 et finalement 10101010.
            • [^] # Re: ouf

              Posté par  (site web personnel) . Évalué à 6.

              Sauf qu'on fait aussi efficace en 25% du temps avec dd

              (et qu'on fatigue moins le disque et qu'on économise plus d'énergie...)
        • [^] # Re: ouf

          Posté par  . Évalué à 2.

          euh je crois que tu te fourvoies sur "dd"
  • # Ecrasement partiel

    Posté par  . Évalué à 1.

    J'avais lu un jour (quelques années maintenant) que les têtes d'écritures n'écrivaient pas exactement au même endroit. Donc que le bit qu'on écrivait pour écraser le bit précédent n'occupait pas exactement la même surface que le bit précédent. Et donc qu'il était possible de retrouver le bit initial.
    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  (site web personnel) . Évalué à 6.

      Ce n'est plus valable depuis l'utilisation de l'enregistrement perpendiculaire. On peut rajouter aussi que l'électronique de chaque disque s'autocalibre, donc sans ces données, il est impossible de faire une corrélation entre une adresse disque et une position physique.

      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  (site web personnel) . Évalué à 10.

      C'est le genre « d'idée de bon sens » dont il faut se méfier et qu'il faut aller vérifier sur le terrain. ;-) Un papier (peut-être cité dans ce journal d'ailleurs) montrait une photo de la surface prise au microscope électronique.

      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à.
  • # Et pour les cartes flash ??

    Posté par  . Évalué à 3.

    Je me pose la question , car j'ai récemment réussi à récupérer une centaine de photos sur une carte SD. Et pourtant j'avais bien commencé a réécrire par dessus.

    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  . Évalué à 1.

      La vitesse d'écriture d'une SD est super lente, c'est possible que tout était encore dans le cache en écriture de ton ordinateur.
      (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  . Évalué à 3.

      Oui tu as eu de la chance car photorec (qui marche aussi sur un disque dur (merci à lui)) ne fait que fouiller le disque ou la carte à la recherche de fichier car quand tu supprimes des fichiers (ou formate avec la plupart des logiciels), tu ne fais que supprimer l'adresse de l'emplacement du fichier sur le disque mais tu ne supprime pas les données en elles-même (sauf si tu réécris dessus en copiant des fichiers sur le disque).

      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  . Évalué à 3.

    Méthode imparable : le pilon.

    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  . Évalué à 2.

      le démontage des plateaux et leur pulvérisation à grands coups de marteau.

      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  . É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.

        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  . Évalué à 2.

          moi je mettrais tout dans un acide suffisament puissant (style acide nitrique a 15 mol.l^(-1) , si ça existe)
          • [^] # Re: Et sinon...

            Posté par  . Évalué à 2.

            Pour la couche "utile" des disques, ça pourrait faire l'affaire effectivement. Mais le support étant en verre, je ne suis pas certain que l'acide soit la solution ultime.
      • [^] # Re: Et sinon...

        Posté par  . Évalué à 4.

        heu, le marteau c'est un peu grossier, les plateaux sont extrêment fragiles, ça se brise bien plus vite qu'un cd/dvd.

        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  . Évalué à 2.

          Ashram: il a parlé des plateaux, je sais bien que la coque est en adamantium :p.

          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  . Évalué à 2.

            moi j'ai essayé sur un dd de 40 (ou peut etre 100, je sais plus), ben meme avec tournevis+marteau, nada que dalle.
            alors peut etre que les nouveaux a 1To ils sont plus fragiles, mais les autres...
            • [^] # Re: Et sinon...

              Posté par  . Évalué à 2.

              Le plus dur, c'est d'ouvrir le disque. Après, tu dévisses les plateaux et tu bourrines avec un bon gros marteau bien lourd des familles (genre massette, voire masse). Si ça survit à ça, il y a un problème ;)
    • [^] # Re: Et sinon...

      Posté par  (site web personnel) . Évalué à 10.

      L'idéal, c'est le broyeur de disque dur :
      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  (site web personnel) . Évalué à 1.

    >> 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.

    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  . Évalué à 5.

      Et que si des agences de renseignement y sont parvenu, elle vont pas faire une publication avec conférence de presse en cosmovision pour le faire savoir.

      « 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  . Évalué à 7.

        euh... si je comprend bien...le fait qu'ils ne fassent PAS de publication sur une technique que l'on sait IMPOSSIBLE est clairement une preuve que l'on nous cache peut-être quelque chose...

        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  . Évalué à 3.

          Personne n'a dit ca.

          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  . Évalué à 2.

    Le week-end dernier je me suis posé la question d'effacer de manière à peu près fiable le contenu de vieux disque dur avant de m'en débarrasser (je déménage sous peu et j'ai un peu de matos informatique fonctionnel mais obsolète).

    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.
  • # Ca me rappelle quelque chose...

    Posté par  . Évalué à 2.

    Guttman, Guttman, mmmmhhh.... Ah oui, le type et son torchon sur Vista.

    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  . Évalué à -1.

    Si en une lecture j'ai 87% de chances de retrouver un bit, alors est-ce que en multipliant 1 milliard de fois la lecture sur le meme bit, je ne peux pas m'approcher de 100% ?

    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  (site web personnel) . Évalué à 5.

      Tu supposes que la lecture ne donne pas toujours le même résultat. D'où tiens-tu cette idée ? :-)
    • [^] # Re: Un truc que je ne comprends pas

      Posté par  . Évalué à 2.

      Gni?

      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  (site web personnel) . É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.

      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  . Évalué à 4.

        Moi j'aurais plutôt dit que tu regardes (toi-même) 100 fois le film, et tu le trouves bien 87% des vision nages, et les 13 autres fois, non.

        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.