Journal ZIP et fcrackzip

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
21
4
jan.
2018

Bonjour à tous,

Je viens de passer quelques heures là-dessus et j'ai envie de partager ça avec vous :)

J’ai récemment retrouvé une vielle archive au format ZIP datant de 2004, une époque à laquelle j’utilisais encore, mais plus pour longtemps, le système d’exploitation privateur Windows de Microsoft. Il s’avère que je l’aurais apparemment protégé avec un mot de passe … que j'ai oublié :(

J’ai alors installé et utilisé sans succès le logiciel libre fcrackzip (# apt install fcrackzip), « force brute ».

https://github.com/hyc/fcrackzip
Dernier commit en juin 2013 :/
Connaissez-vous ce logiciel ? Est-il obsolète au bénéfice d’un autre ? Lequel ?

Dans le manuel, j’ai remarqué qu’il manquait certains caractères ASCİİ dans les jeux proposés (option -c). Mais il n’était rien précisé quant au jeu par défaut.

J’ai alors téléchargé le code source ($ apt source fcrackzip) et farfouillé dedans à la recherche de réponse et peut-être de solutions.

Dans un premier temps, il m’a été facile de déceler un bug, probablement inconnu et aussi d’étendre le jeu de caractère par défaut à l’ensemble ASCİİ complet.

https://github.com/hyc/fcrackzip/blob/master/main.c
ligne 208 (301 dans la version Debian)

   strcpy ((char *) p, "!:$%&/()=?{[]}+-*~#");
   p += 18;

Erreur ! Car il y a 19 caractères ! J’ai testé, et effectivement, un mot de passe tel que A#2 est introuvable contrairement à A~2.

Ensuite, voici ma version :

   strcpy ((char *) p, "!\"#$%&'()*+,-./:;<=>?@[\\]^_`{|}~");
   p += 32;

Je n’ai pas pour l’instant le temps de proposer un correctif :(
Il faudrait d'ailleur modifier la doc', etc. peut-être même prévoir une autre option pour ne pas casser la compatibilité, etc. :(
J’aimerais avoir votre avis également avant d'envisager de consacrer du temps pour cela, car si ça se trouve, c’est inutile car obsolète ou déjà une autre version ailleurs, etc. Qu’en pensez-vous ?

Il y a d’autres problèmes tels que la version ou le type de fichier ZIP, l’algorithme de chiffrement, etc. J’ai pas trop investigué car le fichier en question date de 2004 et je penses pas que ce soit dépassé par fcrackzip de 2013. Mais s’il fallait "refaire" fcrackzip, je le ferais en C++ et il faudrait prévoir les différents formats et algo’ de chiffrement…

  • # Rainbow table

    Posté par  . Évalué à 1.

    moi aussi j'ai un fichier zip de 2010 dont j'ai perdu le mot de passe. J'avais tenté la force brute avec je ne sais plus quel logiciel de crackage en 2013 mais il aurait fallu faire tourner le logiciel pendant des mois. Du coup j'ai laissé tomber.

    J'ai ensuite tenté d'étudier la structure du zip pour :
    - en extraire le mot de passe chiffré
    - en trouver la correspondance dans des rainbows table.

    Mais là encore j'ai laissé tombé car le contenu de cette archive ne vaut pas la peine que j'y consacre du temps.

    • [^] # Re: Rainbow table

      Posté par  . Évalué à 2.

      Du coup j'ai laissé tomber.

      Même expérience, même résultat. Il faut vraiment que le contenu du fichier ait de la valeur, et même dans ce cas, je pense qu'il faut louer une ferme de calcul, parce que ça prend vraiment trop de temps.

  • # Couplage avec John the ripper ?

    Posté par  . Évalué à 2. Dernière modification le 04 janvier 2018 à 13:44.

    Si le soft en question pouvait prendre une liste de mots de passe à tester en entrée, un John the ripper (ou équivalent) pourrait lui produire une liste de trucs à tester (avec variantes automatiques), judicieusement ordonnée par probabilité décroissante d'occurrence.

    • [^] # Re: Couplage avec John the ripper ?

      Posté par  . Évalué à 6.

      JtR version jumbo sait craquer du zip, comme d'ailleurs noté par le mainteneur de fcrackzip

      I believe this program is
      largely obsoleted now if you have John the Ripper with the Jumbo patch.
      In john-1.7.9-jumbo-7 you can just use zip2john and then run john.

      avec le support d'OpenMP et aussi de OpenCL/Cuda et les nombreux modes configurés de base, ce serait dommage de s'en priver

      • [^] # Re: Couplage avec John the ripper ?

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

        Merci pour cette piste intéressante.
        J'ai donc installé John the ripper (# apt install john)
        J'ai bien une commande john mais aucune commande zip2john :(
        D'où est sensée venir la commande zip2john ? quel paquetage dois-je installer ?
        Merci d'avance.

        • [^] # Re: Couplage avec John the ripper ?

          Posté par  . Évalué à 6.

          ah mais debian (?) contient la version "officielle" de base.

          Il faut aller chercher et compiler la version jumbo monstrueusement plus complète sur http://www.openwall.com/john/

          Je te conseille de prendre la version github ( https://github.com/magnumripper/JohnTheRipper/archive/bleeding-jumbo.tar.gz ) pour compiler sur une distribution récente car la version 1.8.0-jumbo-1 n'aime pas openssl 1.1.

          Voir les fichiers doc/INSTALL{,-UBUNTU}, 

          sudo apt-get install build-essential libssl-dev git
tar xaf bleeding-jumbo.tar.gz
cd JohnTheRipper-bleeding-jumbo/src
./configure
make

          Les programmes sont dans run/ (je ne sais si "make install" fonctionne, et de toute façon je le déconseille pour ne pas interférer avec le "john" de la distribution)

          cd ..
          run/zip2john fichier.zip > zip.password
          run/john --plein-d-options-qui-vont-bien zip.password

    • [^] # Re: Couplage avec John the ripper ?

      Posté par  . Évalué à 2.

      Le soft sait justement faire des attaques basées sur un dictionnaire comme le dit la page de man (pointée par un autre commentateur plus bas):

      http://cvs.schmorp.de/fcrackzip/fcrackzip.html

      DICTIONARY MODE
      This mode is similar to brute force mode, but instead of generating passwords using a given set of characters and a length, the passwords will be read from a file that you have to specify using the -p switch.

  • # Du temps? Oui!

    Posté par  . Évalué à 2.

    J'ai eu besoin, et j'ai pas réussi à attaquer un zip avec john the ripper. Cela demandait d'écrire un script. Donc oui cela me semble pertinent de mettre à jour ce logiciel!

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # Quel rapport ?

    Posté par  . Évalué à -10.

    une époque à laquelle j’utilisais encore, mais plus pour longtemps, le système d’exploitation privateur Windows de Microsoft

    Pourquoi se sentir obliger de cracher sur Microsoft ? C'est quoi le rapport avec le sujet initial ?

    C'est quoi cette manie de cracher sur l'un ou l'autre ? Le problème se rencontre du côté des forums Microsoft également qui crachent sur du Linux… J'ai jamais compris le principe.

    • [^] # Re: Quel rapport ?

      Posté par  . Évalué à 10.

      peut-être qu'il n'a pas craché,
      mais simplement justifié pourquoi il avait fait un zip,
      et pas un gzip, ou un bzip2, ou un tar czf dans un monde (obscur ?) qui ne connaissait que zip…

    • [^] # Re: Quel rapport ?

      Posté par  . Évalué à 10.

      Cette phrase est purement factuelle et ne crache sur rien du tout, merci de ne pas confondre mention et dénigrement.

  • # Dernier commit

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

    Dernier commit en juin 2013 :/

    Je ne comprends pas pourquoi tu as ce smiley. Quand un logiciel est fini, on arrête de le modifier…
    Certes, tu as trouvé un bug, et c'est bien d'envoyer un correctif, mais d'une manière générale, les produits stables n'ont pas besoin de mise à jour. (Commentaire similaire.)

    • [^] # Re: Dernier commit

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

      Vous avez tous les deux raison, tout dépend du contexte en fait.

      Un logiciel peut être fini et ne plus nécessiter d'améliorations selon l'auteur, y'a rien de mal à ca, c'est même sain de ne pas vivre avec la peur au ventre à l'idée que des bugs peuvent surgir d'une minute à l'autre sur un bon vieux logiciel qui marche.

      On voit aussi des logiciels libres qui grandissent, évoluent, puis un jour le ou les auteurs arrêtent de le faire évoluer, alors qu'il y aurait encore beaucoup de boulot, y'a plein de raisons à ca: plus le temps, plus l'envie, plus la force… Mais comme c'est du libre, ben quelqu'un d'autre peut le forker, et continuer à le faire évoluer. Mais il faut que quelqu'un le fasse.

      Dans le cas de frackzip, on dirait que c'est plus simplement hyc qui a forké le logiciel original (dont la dernière release date de 2008 et était estampillée 1.0), l'a simplement adapté pour le faire marcher chez lui comme il le souhaite, mais n'a pas plus envie que ca de faire évoluer sa version.

      En fait, c'est une des particularités du logiciel libre qui est souvent oubliée: tu as le droit de l'utiliser, le modifier, le redistribuer, etc. Mais sans aucune garantie. C'est cette dernière partie qui est oubliée la plupart du temps.
      Qu'il y ait des gens qui se chargent de maintenir et faire évoluer certains logiciels n'oblige pas tous les logiciels libres à être maintenus.

    • [^] # Re: Dernier commit

      Posté par  . Évalué à 0. Dernière modification le 05 janvier 2018 à 11:19.

      Je ne comprends pas pourquoi tu as ce smiley. Quand un logiciel est fini, on arrête de le modifier…

      Définir "logiciel fini".

      On sait juste qu'il n'est plus maintenu. Un logiciel 100% "fini"/"mature" pour les éons à venir, ça n'existe pas.

      Sinon, on ne réinventerait pas sans cesse la même chose (lecteur de musiques, gestionnaire d'archive, …)

      Y'a les logiciels qui sont maintenus, d'autres qui ne le sont plus. Point.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Dernier commit

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

        Ton argument ne tient pas la route : on voit régulièrement ici-même plein de moules qui réinventent la roue juste parce qu'elles en avait envie, ou parce qu'elles ne connaissaient pas les logiciels qui répondaient déjà à leur besoins. Il y a aussi ceux qui réinventent la roue parce qu'ils n'aiment pas la licence de base. Tant qu'il y aura des gens qui découvrent l'informatique, la roue sera réinventée.

        Un logiciel est fini quand il résout le problème pour lequel il a été conçu. Mon ~/bin est rempli de programmes que j'ai écrits il y a des années et qui n'ont aucun besoin de mise à jour. Oui, on peut probablement rajouter des features à un logiciel à tout moment. Mais pour moi, ls, grep, awk, sed, ou winamp étaient finis il y a 15-20 ans, et je n'ai pas l'impression d'avoir eu des manques terribles à combler quand je les utilisais alors.

        • [^] # Re: Dernier commit

          Posté par  . Évalué à 2. Dernière modification le 08 janvier 2018 à 16:46.

          Mais pour moi, ls, grep, awk, sed, ou winamp étaient finis il y a 15-20 ans

          Et pourtant, ils reçoivent toujours des patchs (et des plugins pour Winamp).

          Comme quoi, mon argument tient la route. ;-)

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Dernier commit

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

            Oui, probablement que winamp doit lire les nouveaux formats. Probablement que "ls" doit comprendre les nouveaux systèmes de fichier. Mais il y a tout plein de logiciels qui n'ont pas besoin de mises à jour fréquentes car ils ont toutes les features nécessaires à leur bon fonctionnement, et n'ont pas de bugs détectés pendant longtemps:

            Tu vois le truc. Quand ça marche, ça marche. Pas besoin d'un dev qui pousse des commits toutes les 2 semaines pour être un logiciel utile et "fini". Et là, on pare des coreutils de linux, hein. Un truc sacrément répandu et utilisé…

            • [^] # Re: Dernier commit

              Posté par  . Évalué à 2.

              Mais il y a tout plein de logiciels qui n'ont pas besoin de mises à jour fréquentes

              Je dis pas le contraire. Je dis qu'un logiciel n'est jamais fini, nuance.

              Merci de ne pas me faire dire ce que je ne dis pas, hein…

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

            • [^] # Re: Dernier commit

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

              Merci pour la bonne tranche de rigolade. Prenons bool :

              Bool is a utility for finding files that match a boolean expression

              Oui effectivement c'est un bon mètre-étalon d'une application classique grand public, qui pourra donc se contenter d'évoluer aussi peu fréquemment.

              Ceci dit quand on creuse…

              The program has separate text processing and HTML processing algorithms; the former separates patterns separated by newlines or words separated by hyphens. The latter understands many features of the HTML 4.01 standard.

              Ah d'accord en fait le machin fait carrément parseur HTML. Sauf qu'il est bloqué en 1998. Si on veut s'en servir convenablement maintenant il faudrait gérer HTML5 en… le faisant évoluer.

              Bon j'arrête là, merci de nous avoir apporté des arguments pour la quasi-universalité du besoin d'évolution des logiciels.

    • [^] # Re: Dernier commit

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

      Voir le débat similaire sur Bison 3.0 en 2013.

  • # Intérêt d'un patch

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

    Si tu as découvert un bug, et que le logiciel est packagé pour Debian, alors oui, je pense que cela vaut le coup de fournir un correctif pour la version debian. En revanche eux se basent encore sur la version de l'auteur initial datant de 2008, qui n'utilisait pas de système de gestion de version, donc difficile d'envoyer un patch upstream.

    Le gars qui a importé le code dans github a quand même fait un changement utile, donc ça vaudrait peut être le coup que Debian se base sur cette version là. Essaie de lui faire une pull request avec déjà juste le correctif pour les 19 caractères, ça prend 2 minutes, et tu verras s'il est réactif.

    • [^] # Re: Intérêt d'un patch

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

      Et puis on dirait qu'il y a encore des gens qui l'utilisaient en 2017 :)
      https://www.zenzla.com/astuces/1415-trouver-de-passe-dun-zip-fcrackzip.html

    • [^] # Re: Intérêt d'un patch

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 04 janvier 2018 à 16:43.

      Ensuite, pour ajouter des caractères à ceux à tester, c'est expliqué dans la page de man, donc pas besoin de patch pour cela:
      http://cvs.schmorp.de/fcrackzip/fcrackzip.html

      Au final, il n'y a que le bug sur le dièse ignoré à corriger. Tu peux essayer d'envoyer un mail à l'auteur d'origine et lui demander de mettre son projet sur github ou autre, en pointant le clone existant, lui parlant du bug, peut être qu'il répondra.

    • [^] # Re: Intérêt d'un patch

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

      difficile d'envoyer un patch upstream

      L'auteur a une adresse e-mail clairement indiquée sur le site upstream et dans la page de man. Lui envoyer un patch de cette manière me semble plus simple que d'ouvrir un compte github.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Intérêt d'un patch

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

        Que ça suffise, OK. Que tu préfères pour quelque raison, OK. Mais ouvrir un compte sur github, compliqué ?

        • [^] # Re: Intérêt d'un patch

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

          J'ai jamais ouvert de compte github mais envoyer un e-mail m'a certainement l'air plus simple.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: Intérêt d'un patch

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

            Le problème du mail pour un logiciel pas mis à jour depuis 2008 c'est que le gars peut tout à fait avoir changé de mail, ou ne pas être réactif, ce qui a l'air tout à fait possible vu que dans les faits il ne maintient pas le logiciel. Dans tous les cas ça vaut pas un espace public de communication, que ce soit une mailing list ou mieux, un gestionnaire de version public genre github où ton patch peut être retrouvé par quelqu'un d'intéressé. Donc, quand je dis "difficile d'envoyer un patch upstream", c'est pas la difficulté de l'action dont je parle, c'est du fait que même si tu le fais, il y a très peu de chances que le gars réponde. Tu as encore moins de chances qu'il sorte un release pour ça vu qu'il n'est pas actif depuis 10 ans sur le projet.

            Il vaut mieux le prévenir du friendly fork sur github: soit il s'en fout et laisse faire, soit il se joint au projet sur github qui devient le nouveau dépôt de référence. Dans tous les cas, cela fait une excuse pour pouvoir indiquer à Debian de changer d'upstream: il y en a au moins un qui peut être mis à jour par les gens intéressés.

            La version de github a de plus un patch qui améliore grandement les performances apparemment en utilisant la bibliothèque de décompression au lieu de spawner un process à chaque tentative.

  • # s’il fallait "refaire"...

    Posté par  . Évalué à 2.

    s’il fallait "refaire" fcrackzip, je le ferais en C++

    Pas Eric S. Raymond…

    "Why ESR Hates C++, Respects Java, and Thinks Go (But Not Rust) Will Replace C":

    https://m.slashdot.org/story/334151

    • [^] # Re: s’il fallait "refaire"...

      Posté par  . Évalué à 3.

      Tout ce qu'il dit c'est que quand il y a des développeurs médiocres, le C++ est une plaie, et que sur de gros projets il y a forcément de mauvais développeurs (variante de 'il y a toujours la même proportion de cons quelle que soit la population').

      Sur de petits projets où se restreindre à des fonctionnalités sûre du C++ est une politique qu'il est possible d'imposer, il l'utiliserait sans problème.

      Le gros avantage du C++ est sa compatibilité immédiate avec le C et donc toutes les bibliothèques et noyaux qui vont avec sans avoir à écrire et maintenir des wrappers. C'est cela qui est aussi son plus gros inconvénient (il hérite donc des problèmes du C en sûreté mémoire et typage).
      Le C++ est un très bon langage, polyvalent (bas à haut niveau si besoin), très largement disponible, et performant. La difficulté est de bien l'utiliser.

  • # Et hashcat

    Posté par  . Évalué à 1.

    As-tu essayé avec l’outil hashcat. Je pense qu’il gère les mots de passe zip et peut utiliser ta carte graphique.

  • # Un indice chez vous.

    Posté par  . Évalué à 2.

    Il y a … 15 ans?
    Pour un besoin pro j'avais utilisé une version d'essai d'un outil qui trouvait les mots de passe d'un zip.
    La version d'eval ne donnait que les 2 premiers caractères mais j'avais quand même testé, pour voir.
    la réponse étant "az", j'avais essayé en ajoutant des lettres de azerty jusqu'à pouvoir l'ouvrir ;)

    J'ai la flemme d'essayer de retrouver cet outil, mais un outil de ce genre peut peut-être te donner un indice sur ton mot de passe.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.