Forum Programmation.shell Problème : découper un fichier sans connaitre la taille des morceaux

Posté par  . Licence CC By‑SA.
Étiquettes :
3
9
jan.
2018

Bonjour, une suite d'erreurs monstrueuses a fait perdre ses données à une amie. Photorec m'a (entre autres) récupéré un fichier de 280G(i?)o. Vu qu'il s'agit du dernier espoir de retrouver son dernier moi de travail, je cherche un moyen de découper le fichier binaire en allant rechercher dedans l'entête du format utilisé, et coller dans un autre fichier tout ce qu'il y aurait entre deux entêtes. Après si nettoyage des fichiers il y a à faire, ce sera toujours plus simple qu'avec un BLOB pareil. Bien évidemment, split a été ma première idée, mais s'il est utilisable comme je l'entends, c'est très mal documenté. En vous remerciant

  • # dd est ton ami

    Posté par  . Évalué à 3.

    tu peux essayer avec la commande dd, qui permet :
    - de gérer des bloc-size
    - des offsets,
    - le nombre de blocs traités.

    il y a aussi les éditeurs hexadécimaux.

    • [^] # Re: dd est ton ami (ou pas)

      Posté par  . Évalué à 1. Dernière modification le 09 janvier 2018 à 13:27.

      Le gros problème avec dd, c'est la taille des block-size, comme split. D'un block au suivant les tailles peuvent varier de quelques centaines de Ko à quelques dizaines de Mo, voire plus et me sont inconnues a priori.
      Les éditeurs hexa, je n'en connais pas, et pour naviguer dans un fichier de 280 Go afin d'extraire des données, ça risque d'être coton.
      En gros, tel que je vois le problème, je pensais à un truc comme cut, mais en binaire et capable de couper avec un séparateur sur plusieurs octets, voire avec plusieurs outils, un pour trouver les adresses dans le fichier, et un pour extraire les données. Il a aussi moyen que j'ai pas compris les subtilités de dd et ses blagues de comptoir (dd-solé). En tout cas, merci pour la réponse super rapide.

      • [^] # Re: dd est ton ami (ou pas)

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

        c est gros long et lourd mais tu as bvi, et tu fais des recherche comme dans vi pour trouver et ensuite tu fait tes coupes.

        si tu a juste 1 ou 2 fichiers a récupérer ça devrait être ok
        si tu en as 1000, faudra scripter un peu :p

  • # hachoir-subfile

    Posté par  . Évalué à 6.

    As tu essayé:
    http://hachoir3.readthedocs.io/subfile.html

    hachoir-subfile is a tool based on hachoir-parser to find subfiles in any binary stream.

  • # C

    Posté par  (Mastodon) . Évalué à 3.

    Si l'en-tête n'est pas trop complexe, un petit bout de code C devrait faire ton bonheur. Tu lis les octets et tu les envoies au fur-et-à-mesure dans un nouveau fichier. Dès que tu as la séquence en question, tu changes de fichier.

    Tu as le format en question qu'on se fasse une idée ?

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # FS complet?

    Posté par  . Évalué à 8.

    Un fichier d'une taille pareille, est-ce que ce ne serait pas une image complète de la partition (voir du disque complet)?
    Si tu demande simplement à file de te dire ce qu'est ce fichier, est-ce qu'il te donne une information pertinente?

    Si c'est une image de la partition (avec donc le système de fichiers dedans), tu peux essayer de la monter en loopback (en lecture seule!!) pour voir si tu accède aux fichiers.
    S'il y a bien un FS dedans mais qu'il ne peut pas être monté parce qu'il est corrompu, fais-en une copie (pour garder un original non modifié) puis fais un fsck dessus, en espérant qu'il arrive à le remettre suffisamment en état pour récupérer les données importantes.

  • # exemple

    Posté par  . Évalué à 3.

    Tu peux t'inspirer de cette méthode :

    http://linuxfr.org/users/kikoun/journaux/grosse-boulette-exemple-de-r%C3%A9cup%C3%A9ration-de-donn%C3%A9es

  • # Bravo pour la réactivité

    Posté par  . Évalué à 2.

    Bonjour et merci à tous. Histoire de vous tenir au courant, je fais un point avec quelques détails en sus. Vu qu'il y a des détails inutiles à la résolution du problème que je n'avais pas donnés, il y a des hypothèses fausses dans vos réponses, mais vous ne pouviez le savoir :
    - Le blob a été extrait par photorec d'une partition NTFS jamais retouchée depuis l'achat de la machine et faisant son petit To, donc ce n'est pas une image de la partition
    - file me donne : GIF image data, version 89a, 38 x 19
    - je n'ai malheureusement pas d'accès physique au disque, l'ordinateur a dû retourner chez l'amie qui m'appelât au secours, et je n'aurais ni le temps ni le courage de me lancer dans une récupération héroïque comme celle de KiKouN
    - Je viens d'installer hachoir3 pour aller à la pêche aux données.-

    À tous, merci, je vous donne des nouvelles dès que hachoir a commencé à sortir des trucs (ou pas)

    • [^] # Re: Bravo pour la réactivité

      Posté par  . Évalué à 1.

      Re, hachoir a presque fini (moins de 3% restant). Dans le blob, en plus du fichier GIF, il a trouvé un JPEG. Pas la réussite que j'espérais, mais les données que je cherchait ne devaient être dedans. Au final je suis déçu, certes pas par l'outil, mais par la situation. Encore gros merci

Suivre le flux des commentaires

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