Fichiers passés de stéganographie : cacher les données directement dans les secteurs

Petite préface

La stéganographie, si quelqu’un ne s’en souvient pas, cache des informations dans certains conteneurs. Par exemple, en images (discuté ici и ici). Vous pouvez également masquer les données dans les tables de service du système de fichiers (cela a été écrit à propos de ici), et même dans les paquets de service du protocole TCP. Malheureusement, toutes ces méthodes présentent un inconvénient : pour « insérer » imperceptiblement des informations dans un conteneur, il faut des algorithmes astucieux qui prennent en compte les particularités de la structure interne du conteneur. Et des problèmes surviennent avec la résistance du conteneur à la manipulation : par exemple, si vous modifiez légèrement l’image, les informations cachées sont perdues.

Est-il possible de se passer d'algorithmes astucieux et de manipulations subtiles des données, tout en garantissant la fonctionnalité du conteneur et un niveau acceptable de sécurité des données cachées ? Pour l’avenir, je dirai : oui, vous pouvez ! Je vais même proposer un utilitaire.

Détails sanglants de la méthode

L'idée de base est aussi simple qu'un coup dans le front : il y a des zones sur le disque sur lesquelles le système d'exploitation n'écrit jamais (ou écrit dans de rares cas). Pour éviter d'avoir à rechercher ces zones à l'aide d'algorithmes astucieux, nous utiliserons la redondance, c'est-à-dire que nous dupliquerons nos informations cachées plusieurs fois dans tous les secteurs du disque. Ensuite, en plus de toute cette splendeur, vous pourrez créer les partitions nécessaires, formater les systèmes de fichiers, écrire des fichiers et installer des systèmes d'exploitation - tout de même, une partie des données secrètes sera enregistrée et pourra être récupérée, et la duplication répétée nous aidera assembler le tout original à partir des morceaux.

L’avantage de cette méthode est évident : on ne dépend pas du format de fichier, ni même du type de système de fichiers utilisé.

Les inconvénients sont également, je pense, évidents :

• Les données secrètes ne peuvent être modifiées qu'en réécrivant complètement l'intégralité du disque, puis en recréant le contenu visible par l'utilisateur. Cependant, vous ne pouvez pas utiliser de logiciel qui recrée le disque à partir d'une image : il recréera également les données secrètes précédentes.
• Plus le volume de données secrètes est important, plus le risque de perdre certaines informations est élevé.
• La récupération des données du disque peut prendre beaucoup de temps. De quelques minutes à plusieurs jours (les disques modernes sont gros).

Passons maintenant aux détails.

Il est clair que si vous répartissez simplement des données secrètes sur tout le disque, elles ne seront cachées qu'à l'œil nu. Si vous équipez votre regard, par exemple, d'un éditeur de disque, les données apparaîtront dans toute leur splendeur. Par conséquent, ce serait une bonne idée de crypter les données afin qu’elles n’apparaissent pas. Nous chiffrerons simplement, mais avec goût : en utilisant l'algorithme aes256-cbc. Nous demanderons à l'utilisateur la clé de cryptage et le laisserons trouver un bon mot de passe.

La question suivante est de savoir comment distinguer les « bonnes » données des mauvaises données. Ici, une somme de contrôle nous aidera, mais pas simple, mais SHA1. Et quoi? C'est assez bien pour git, donc ça nous conviendra aussi. C'est décidé : nous fournissons à chaque information stockée une somme de contrôle, et si après le décryptage elle correspond, cela signifie que le décryptage a réussi.

Vous aurez également besoin du numéro de fragment et de la longueur totale des données secrètes. Le numéro de fragment sert à garder une trace des morceaux que nous avons déjà déchiffrés et de ceux qui restent. La longueur totale nous sera utile lors du traitement du dernier fragment, afin de ne pas écrire de données inutiles (c'est-à-dire du remplissage). Eh bien, puisque nous avons toujours un en-tête, nous y ajouterons le nom du fichier secret. Il sera utile après le décryptage, pour ne pas deviner comment l'ouvrir.

Tester la méthode en pratique

Pour vérifier, prenons le support le plus courant : une clé USB. J'en ai trouvé un ancien d'une capacité de 1 Go, ce qui est tout à fait adapté aux expérimentations. Si, comme moi, vous avez eu l'idée de ne pas vous soucier du support physique, mais de le tester sur un fichier - une image disque, alors je dirai tout de suite : ça ne marchera pas. Lors du formatage d'un tel « disque », Linux crée à nouveau le fichier et tous les secteurs inutilisés seront remplis de zéros.

En tant que machine sous Linux, j'ai malheureusement dû utiliser une station météo posée sur le balcon sur le Raspberry Pi 3. Il n'y a pas beaucoup de mémoire là-bas, nous ne cacherons donc pas de gros fichiers. Nous nous limitons à une taille maximale de 10 mégaoctets. Il ne sert également à rien de masquer les fichiers trop petits : l'utilitaire écrit les données sur le disque par clusters de 4 Ko. Par conséquent, ci-dessous, nous nous limiterons à un fichier de 3 Ko - il s'inscrit dans l'un de ces clusters.

Nous allons nous moquer de la clé USB par étapes, en vérifiant après chaque étape si les informations cachées sont lisibles :

1. Formatage rapide au format FAT16 avec une taille de cluster de 16 Ko. C'est ce que Windows 7 propose de faire avec une clé USB dépourvue de système de fichiers.
2. Remplir la clé USB avec toutes sortes de déchets à 50 %.
3. Remplir la clé USB avec toutes sortes de déchets à 100 %.
4. Formatage « long » au format FAT16 (tout écrasant).

Comme prévu, les deux premiers tests se sont soldés par une victoire totale : l'utilitaire a réussi à extraire 10 mégaoctets de données secrètes du lecteur flash. Mais après que le lecteur flash ait été rempli au maximum de fichiers, une panne s'est produite :

Total clusters read: 250752, decrypted: 158
ERROR: cannot write incomplete secretFile

Comme vous pouvez le constater, seuls 158 clusters ont été déchiffrés avec succès (632 kilo-octets de données brutes, ce qui donne 636424 10 octets de charge utile). Il est clair qu'il n'y a aucun moyen d'obtenir 1 mégaoctets ici, et pourtant, parmi ces clusters, il existe clairement des doublons. Vous ne pouvez même pas récupérer 3 mégaoctet de cette façon. Mais nous pouvons garantir que nous récupérerons 120 kilo-octets de données secrètes à partir d'un lecteur flash même après son formatage et son écriture au maximum. Cependant, des expériences montrent qu'il est tout à fait possible d'extraire un fichier de XNUMX kilo-octets à partir d'un tel lecteur flash.

Malheureusement, le dernier test a montré que l'intégralité de la clé USB avait été écrasée :

$ sudo ./steganodisk -p password /dev/sda
Device size: 250752 clusters
250700 99%
Total clusters read: 250752, decrypted: 0
ERROR: cannot write incomplete secretFile


Pas un seul cluster n’a survécu… Triste, mais pas tragique ! Avant le formatage, essayons de créer une partition sur le lecteur flash, et déjà un système de fichiers dedans. À propos, il est sorti de l'usine avec exactement ce formatage, nous ne faisons donc rien de suspect.
On s'attend à ce que l'espace disponible sur le lecteur flash ait légèrement diminué.

On s'attend également à ce que 10 mégaoctets ne puissent pas être cachés sur un disque complètement plein. Mais maintenant, le nombre de clusters déchiffrés avec succès a plus que doublé !

Total clusters read: 250752, decrypted: 405

Malheureusement, il est impossible d’assembler un mégaoctet à partir de morceaux, mais deux cents kilo-octets, c’est facile.

Eh bien, la nouvelle du dernier, 4ème contrôle, cette fois-ci est joyeuse : le formatage complet d'une telle clé USB n'a pas entraîné la destruction de toutes les informations ! 120 kilo-octets de données secrètes s'intègrent parfaitement dans l'espace inutilisé.

Tableau récapitulatif des tests :

Un peu de théorie : sur l'espace libre et les secteurs inutilisés

Si vous avez déjà divisé votre disque dur en partitions, vous avez peut-être remarqué qu'il n'est pas toujours possible d'allouer tout l'espace libre sur le disque. La première section commence toujours par une certaine indentation (généralement 1 mégaoctet ou 2048 XNUMX secteurs). Derrière la dernière section, il arrive aussi qu'il reste une petite « queue » de secteurs inutilisés. Et parfois, il y a des écarts entre les sections, bien que rarement.

En d'autres termes, il existe des secteurs sur le disque auxquels il est impossible d'accéder lors d'un travail normal avec le disque, mais des données peuvent être écrites sur ces secteurs ! Et cela signifie aussi le lire. Ajusté pour le fait qu'il existe également une table de partition et un code de chargeur de démarrage, qui sont situés dans la zone vide au début du disque.

Faisons une pause dans les sections pendant un moment et regardons le disque à vol d'oiseau, pour ainsi dire. Ici nous avons une partition vide sur le disque. Créons-y un système de fichiers. Peut-on dire que certains secteurs du disque restent non effacés ?

E-e-e - roulement de tambour ! La réponse sera presque toujours oui ! En effet, dans la plupart des cas, créer un système de fichiers revient à écrire seulement quelques blocs d'informations de service sur le disque, sinon le contenu de la partition ne change pas.

Et aussi - de manière purement empirique - on peut supposer que le système de fichiers ne peut pas toujours occuper tout l'espace qui lui est alloué jusqu'au dernier secteur. Par exemple, un système de fichiers FAT16 avec une taille de cluster de 64 kilo-octets ne peut évidemment pas occuper complètement une partition dont la taille n'est pas un multiple de 64 kilo-octets. À la fin d'une telle section, il devra y avoir une « queue » de plusieurs secteurs inaccessibles pour stocker les données utilisateur. Cependant, cette hypothèse n’a pas pu être confirmée expérimentalement.

Ainsi, pour maximiser l'espace disponible pour le stéganogramme, vous devez utiliser un système de fichiers avec une taille de cluster plus grande. Vous pouvez également créer une partition, même si cela n'est pas nécessaire (sur une clé USB par exemple). Il n'est pas nécessaire de créer des sections vides ou de laisser des zones non allouées - cela attirera l'attention des citoyens intéressés.

Utilitaire pour les expériences

Vous pouvez toucher le code source de l'utilitaire ici

Pour construire, vous aurez besoin de Qt version 5.0 ou supérieure et d'OpenSSL. Si quelque chose ne fonctionne pas, vous devrez peut-être modifier le fichier steganodisk.pro.

Vous pouvez modifier la taille du cluster de 4 Ko à, disons, 512 octets (dans secretfile.h). Dans le même temps, le coût des informations de service augmentera : l'en-tête et la somme de contrôle occupent 68 octets fixes.

Vous devez bien sûr exécuter l’utilitaire avec les droits d’utilisateur root et avec prudence. Aucune question ne sera posée avant d'écraser le fichier ou le périphérique spécifié !

Profiter.

Source: habr.com