Journal LUKS et forensics

Posté par  .
Étiquettes : aucune
0
10
fév.
2007
Bien le bonsoir amis linuxFRiens.

J'écris ce journal peiné après avoir été victime de ma propre bêtise.
J'ai en effet involontairement écrasé les 512 premiers octets d'une partition LUKS, dont évidemment la partie du header contenant le hash de la clé maîtresse. Du coup je me retrouve avec une partition inutilisable et des données irrécupérables (backup partiel uniquement).

En bidouillant un peu avec la doc du format de structure LUKS et avec les informations dont je dispose toujours (notamment une clé de chiffrement dont le hash devrait pouvoir être recalculé, la taille, le FS de la partition, ...) je me suis dit qu'il serait éventuellement possible de récupérer ces fameux 512 octets qui me font maintenant défaut. Est-ce que certains d'entre-vous ont déjà utilisé des outils de forensics (la partition est contenue sur un support magnétique : un bon vieux disque-dur) et pourraient me donner quelques pistes / conseils pour mener ma mission à bien ?

Merci d'avance.

  • # Sparse ?

    Posté par  . Évalué à 6.

    Je ne connais pas l'implémentation de LUKS, mais une idée me traverse la tête:
    - tu crée un fichier sparse de la même taille que le block device (celui dont as perdu les 512 premiers octets)
    - tu attribue un loop-device à ce fichier sparse
    - tu repasse LUKS sur ce loop-device (avec les mêmes options qu'initialement)
    Il est possible (mais pas du tout certain) que tu puisse en extraire les 512 premiers octets pour les remettre sur ton block device...
    Il y a des tas de raisons pour que ça ne marche pas, la première qui me vient à l'esprit étant que le hash passe peut-être à travers un vecteur d'initialisation ("salt") ?

    Bon courage.

    • [^] # Re: Sparse ?

      Posté par  . Évalué à 2.

      Je te remercie pour l'idée qui en effet est une bonne idée :-)

      Cependant je me suis penché sur l'implémentation de LUKS (les catastrophes peuvent être une excellente excuse pour s'instruire) et le hash est bien "salé".
      C'est pour ça que mon idée de base était plutôt de chercher à passer sous la première couche de données (sachant que les 512 octets n'ont été écrasés qu'une seule fois) et tenter de récupérer les données brutes avant écrasement avec comme indicateur de réussite le placement des différents champs du bloc LUKS et notamment le magic number placé au début de l'en-tête. Ceci dit je ne suis pas sur que ce soit possible sans un démontage en règle du disque dur et une étude de magnétisme + une expertise et l'utilisation de matériel couteux dont je ne dispose pas et qui feraient un peu "overkill" par rapport à l'importance des données à récupérer...

      • [^] # Re: Sparse ?

        Posté par  . Évalué à 2.

        Tu peux toujous essayer d'en fabriquer un toi même ;-)

        http://www.google.fr/search?hl=fr&q=homebrew+stm

      • [^] # Re: Sparse ?

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

        Essaye de regarder les 512 derniers octets de la partition.

        Il a été question a un moment d'y copier un backup de sécurité de ce genre de donnée (au temps anciens où je lisais la ml correspondante).

        Sinon tu peux toujours les contacter ici pour leur demander quoi tenter :
        dm-crypt TAGADA saout.de

        C'est une mailing list, mais tu dois peut-être t'inscrire.

  • # La réponse est connue :

    Posté par  . Évalué à 9.

    LUKS, Je suis ton père.

    (hop, je suis déja dehors)

  • # smuroF

    Posté par  . Évalué à -3.

    Non mais vraiment ! On se demande à quoi ils servent !

    Rien à foutre de tes petits problèmes personnels, pour rester poli...

  • # Pas de chatte

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

    J'ai en effet involontairement écrasé les 512 premiers octets d'une partition LUKS

    Alors là... pas de bol. C'est un peu comme faire tomber ses clés dans une bouche à égoux. Ça me rappelle un fait divers : un mec dont la tête était coincée dans une bouche d'égoux, je ne me souviens plus s'il s'était noyé ou pas... L'accident bête qui fait gagner 10 points Darwin.
    http://www.darwinawards.com/

    Tout ça pour dire que 32 octets de sel... faut être patient pour les retrouver, cf. "PHDR layout" dans les annexes de http://luks.endorphin.org/LUKS-on-disk-format.pdf
    ---
    Ca serait bien de contacter les auteurs de LUKS pour leur parler de ton problème. S'il n'existe aucune copie du PHDR, il faudrait en prévoir une copie (ou plusieurs) dans la prochaine version de LUKS. Dans ton cas, c'est une erreur de manipulation, mais il arrive aussi que le disque dur déconne (secteur illisible). EXT2, par exemple, conserve un grand nombre de copie de l'entête (superblock), 13 sur un disque de 60 Go par exemple.
    ---
    Sauvergarder ses données, c'est bien.

Suivre le flux des commentaires

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