Stéganographie hors des fichiers : cacher des données directement dans les secteurs

Une brève introduction

La stéganographie, si quelqu'un ne s'en souvient pas, consiste à cacher des informations dans divers conteneurs. Par exemple, dans des images (déjà discuté ici et ici). On peut également cacher des données dans les tables de fichiers systèmes (déjà abordées ici), et même dans les paquets de protocole TCP. Malheureusement, toutes ces méthodes présentent un inconvénient : pour insérer discrètement des informations dans un conteneur, il faut des algorithmes astucieux tenant compte des spécificités internes du conteneur. Et avec la résistance du conteneur aux manipulations, des problèmes peuvent survenir : par exemple, si l'on modifie légèrement une image, les informations cachées peuvent être perdues.

Peut-on contourner ces algorithmes complexes et ces manipulations délicates, tout en garantissant le bon fonctionnement du conteneur et un niveau acceptable de préservation des données cachées ? Pour le dire en avance, oui, c'est possible ! Et je vais même proposer un utilitaire.

Les détails sanglants de la méthode

L'idée principale est simple, comme un coup de massue sur la tête : sur le disque, il existe des zones dans lesquelles le système d'exploitation n'écrit jamais (ou seulement dans de rares cas). Pour éviter de devoir chercher ces zones avec des algorithmes astucieux, nous allons utiliser la redondance — c'est-à-dire dupliquer notre information cachée plusieurs fois dans tous les secteurs du disque. Ensuite, on peut créer les partitions nécessaires, formater les systèmes de fichiers, écrire des fichiers et installer des systèmes d'exploitation — une partie des données secrètes sera toujours préservée et pourra être extraite, tandis que cette duplication aidera à reconstituer l'ensemble à partir des morceaux.

L'avantage de cette méthode est évident : nous ne dépendons ni du format des fichiers, ni même du type de système de fichiers utilisé.

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

• Les données secrètes ne peuvent être modifiées qu'en réécrivant complètement l'intégralité du disque, suivie de la reconstitution du contenu visible pour l'utilisateur. De plus, il est interdit d'utiliser un logiciel qui recrée le disque à partir d'une image : il recréera également les anciennes données secrètes.
• Plus le volume des données secrètes est important, plus la probabilité de perte d'une partie des informations est élevée.
• L'extraction des données d'un disque peut prendre beaucoup de temps. De quelques minutes à quelques jours (les disques modernes sont plus grands).

Passons maintenant aux détails.

Il est clair que simplement étaler des données sensibles sur tout le disque les rendra invisibles seulement à l'œil nu. Si l'on utilise un outil, tel qu'un éditeur de disque, les données apparaîtront alors dans toute leur splendeur. Par conséquent, il serait judicieux de chiffrer les données pour les dissimuler davantage. Nous allons chiffrer simplement mais avec finesse : selon l'algorithme aes256-cbc. Nous demanderons à l'utilisateur de nous fournir la clé de chiffrement et de choisir un bon mot de passe.

La question suivante est de savoir comment distinguer les « bonnes » données des données corrompues. Un hash, et pas n'importe lequel, mais un SHA1, nous sera utile ici. Pourquoi pas ? Pour git, il est suffisamment bon, donc il nous conviendra aussi. Décidé : nous allons doter chaque fragment d'information sauvegardé d'un hash, et si après déchiffrement celui-ci correspond, cela signifie que le déchiffrement a réussi.

Il sera également nécessaire d'avoir un numéro de fragment et la longueur totale des données sensibles. Le numéro de fragment est pour suivre quels morceaux nous avons déjà déchiffrés et lesquels restent à faire. La longueur totale sera utile lors du traitement du dernier fragment, afin de ne pas écrire de données superflues (c'est-à-dire du padding). Et puisque nous en sommes déjà à mentionner un en-tête, ajoutons-y le nom du fichier secret. Celui-ci sera utile après déchiffrement pour savoir comment l'ouvrir.

Testons la méthode en pratique.

Pour le test, prenons le support le plus courant : une clé USB. J'ai trouvé une vieille clé de 1 Go, ce qui est tout à fait adéquat pour les expériences. Si, comme moi, vous avez pensé à ne pas vous embêter avec des supports physiques et à tester sur un fichier—une image disque, je vais vous le dire tout de suite : ça ne fonctionnera pas. Lors de la formatage d'un tel « disque », linux crée le fichier à nouveau, et tous les secteurs non utilisés seront remplis de zéros.

En tant que machine avec linux, j'ai malheureusement dû utiliser une station météo délaissée sur le balcon, à base de Raspberry Pi 3. Il n'y a pas beaucoup de mémoire là-bas, donc nous ne cacherons pas de gros fichiers. Nous limiterons la taille maximale à 10 mégaoctets. Des fichiers trop petits ne valent pas non plus la peine d'être cachés : l'outil écrit les données sur le disque en clusters de 4 Ko. Donc, en bas, nous allons nous limiter à un fichier de 3 Ko—il tient dans un tel cluster.

Nous allons procéder progressivement avec la clé USB, vérifiant après chaque étape si les informations cachées sont lisibles :

1. Formatage rapide en FAT16 avec une taille de cluster de 16 Ko. C'est ce que propose Windows 7 pour une clé USB dépourvue de système de fichiers.
2. Remplissage de la clé USB avec toutes sortes de fichiers indésirables à 50%.
3. Remplissage de la clé USB avec toutes sortes de fichiers indésirables à 100%.
4. Formatage « long » en FAT16 (avec réécriture complète).

Les deux premiers tests se sont logiquement soldés par un succès total : l'outil a pu extraire avec succès 10 mégaoctets de données secrètes de la clé USB. Cependant, après avoir saturé la clé avec des fichiers, une erreur s'est produite :

Total des clusters lus : 250752, décryptés : 158
ERREUR : impossible d'écrire le secretFile incomplet

Comme nous le voyons, seuls 158 clusters (632 Ko de données brutes, soit 636424 octets de charge utile) ont pu être déchiffrés avec succès. Il est évident que 10 mégaoctets ne peuvent être obtenus ainsi, et il y a clairement des doublons parmi ces clusters. Même 1 mégaoctet ne pourra plus être récupéré de cette manière. Cependant, nous pouvons garantir que 3 Ko de données secrètes seront récupérées de la clé USB même après qu'elle aura été formatée et remplie à ras bord. Néanmoins, les expériences montrent qu'il est possible d'extraire un fichier de 120 Ko de cette clé.

Le dernier test a malheureusement montré que la clé USB a été complètement réécrite :

$ sudo ./steganodisk -p password /dev/sda
Taille du périphérique : 250752 clusters
250700 99%
Total des clusters lus : 250752, déchiffrés : 0
ERREUR : impossible d'écrire le secretFile incomplet


Aucun cluster n'a été conservé… C'est triste, mais pas tragique ! Essayons de créer une partition sur la clé avant de la formater, et d'y mettre le système de fichiers. D'ailleurs, elle est arrivée d'usine avec un tel formatage, donc nous ne faisons rien de suspect.
Il est tout à fait prévisible que l'espace disponible sur la clé USB ait légèrement diminué.

Il est également assez prévisible que 10 mégaoctets n'aient pas pu être cachés sur un disque totalement saturé. Mais maintenant, le nombre de clusters déchiffrés avec succès a doublé !

Total des clusters lus : 250752, déchiffrés : 405

Malheureusement, il ne sera pas possible de rassembler des mégaoctets à partir des morceaux, mais il sera facile d'obtenir deux cents kilooctets.

Et maintenant, la nouvelle réjouissante du dernier, 4e test : le formatage complet de cette clé USB n'a pas entraîné la destruction de toutes les informations ! 120 Ko de données secrètes ont parfaitement trouvé leur place dans l'espace non utilisé.

Tableau récapitulatif des tests :

Un peu de théorie : à propos de l'espace libre et des secteurs inutilisés

Si vous avez déjà partitionné un disque dur, vous avez pu remarquer qu'il n'est pas toujours possible d'utiliser tout l'espace libre sur le disque. La première partition commence toujours avec un certain décalage (généralement 1 mégaoctet, ou 2048 secteurs). Il arrive aussi qu'il reste un petit « queue » de secteurs non utilisés après la dernière partition. De plus, il reste parfois des espaces entre les partitions, même si c'est rare.

En d'autres termes, il y a des secteurs sur le disque auxquels il n'est pas possible d'accéder lors d'une utilisation normale, mais il est possible d'y écrire des données ! Par conséquent, il est aussi possible de les lire. Cela, en tenant compte du fait qu'il existe également une table de partitions et un code de démarrage qui se trouvent précisément dans la zone vide au début du disque.

Détournons notre attention des partitions et regardons le disque d'une perspective différente. Imaginons qu'il y ait une partition vide sur le disque. Nous allons y créer un système de fichiers. Peut-on dire que certains secteurs sur le disque sont restés non écrasés ?

Et — roulement de tambour ! La réponse sera pratiquement toujours — oui ! En effet, dans la plupart des cas, la création d'un système de fichiers revient à n'écrire que quelques blocs d'informations de service sur le disque, tandis que le reste du contenu de la partition reste inchangé.

De plus — empiriquement parlant — on peut supposer que le système de fichiers ne peut pas toujours utiliser tout l'espace qui lui est attribué jusqu'au dernier secteur. Par exemple, le système de fichiers FAT16 avec une taille de cluster de 64 kilooctets ne pourra évidemment pas occuper entièrement une partition dont la taille n'est pas un multiple de 64 kilooctets. À la fin d'une telle partition, il faudra laisser une « queue » de quelques secteurs, inaccessible pour le stockage de données utilisateurs. Cependant, cette hypothèse n'a pas pu être confirmée expérimentalement.

Ainsi, pour maximiser l'espace disponible pour la stéganographie, il est nécessaire d'utiliser un système de fichiers avec une taille de cluster plus grande. On peut aussi créer une partition, même si ce n'est pas nécessaire (par exemple sur une clé USB). Il n'est pas nécessaire de créer des partitions vides ou de laisser des zones non allouées - cela attirera l'attention des personnes intéressées.

Outil pour les expérimentations

Vous pouvez jeter un œil aux sources de l'outil ici

Pour la compilation, Qt version 5.0 ou supérieure et OpenSSL sont nécessaires. Si quelque chose ne compile pas, il faudra peut-être ajuster le fichier steganodisk.pro.

Vous pouvez modifier la taille du cluster de 4 Ko à, disons, 512 octets (dans secretfile.h). Cela augmentera les coûts liés aux informations de service : l'en-tête et le contrôle de redondance cyclique occupent 68 octets fixes.

Bien sûr, vous devez lancer l'outil avec les droits de l'utilisateur root, et ce, avec prudence. Aucune question ne sera posée avant la réécriture du fichier ou du périphérique spécifié !

Profitez-en.

Source : habr.com