cleasbycode/jdvrifOutil de stéganographie pour images JPG
jdvrif (JPG Data Vehicle) est un outil en ligne de commande de stéganographie rapide et facile à utiliser, permettant de dissimuler et d'extraire tout type de fichier via une image JPG. Linux uniquement.
Votre fichier de données est compressé avec libdeflate/zlib, puis chiffré avec XChaCha20-Poly1305 (secretstream de libsodium) sous une clé dérivée par Argon2id à partir d'un PIN de récupération généré aléatoirement, et enfin intégré dans l'image de couverture. Le PIN est affiché une seule fois, à la fin de conceal, et n'est jamais stocké nulle part : sans lui, le fichier dissimulé ne peut pas être récupéré.
En utilisant le mode de dissimulation par défaut, vous pouvez dissimuler tout type de fichier, l'image finale étant plafonnée à 2GiB. Les autres modes de dissimulation par plateforme et les sites de médias sociaux compatibles (listés ci-dessous) ont leurs propres limites de taille bien plus petites et d'autres exigences.
Il existe une édition Web de jdvrif, que vous pouvez utiliser immédiatement, comme alternative pratique au téléchargement et à la compilation du code source de la CLI. Les téléversements de fichiers via le Web sont limités à 20MiB.
Un port expérimental en Rust jdvrif-rs est également disponible pour ceux qui s'intéressent à ce langage. Il est compatible au niveau du format : l'une ou l'autre version peut récupérer les images de l'autre.
jdvrif dérive en partie de la technique mise en œuvre par le chercheur en sécurité David Buchanan.
Image de démonstration : "A place of concealment" / PIN : 7912872750612437051
Contrairement à la méthode de stéganographie LSB (Least Significant Bit, bit de poids faible) courante, qui dissimule les données dans les pixels d'une image de couverture, jdvrif cache principalement les données dans les segments applicatifs d'une image JPG (ICC, EXIF, XMP, etc.).
| Mode de dissimulation | Où vont les données | Où partager l'image de sortie |
|---|---|---|
| (aucune option) | Segments APP2/profil ICC | X-Twitter, Tumblr, Mastodon, Pixelfed, PostImage, ImgBB, ImgPile, Flickr |
| -b | Segments EXIF / Photoshop / XMP encadrés | Bluesky uniquement |
| -r | Coefficients DCT JPEG (QIM) | Reddit uniquement |
| -x | Coefficients DCT JPEG (J-UNIWARD/STC) | X-Twitter uniquement |
Les deux exceptions de plateforme à la méthode de stockage par segments par défaut sont Reddit et X-Twitter. Toutes deux disposent de leur propre mode de dissimulation, et aucun de ces modes n'utilise de segments de métadonnées : -r et -x transportent la charge utile dans les coefficients DCT de l'image JPG à la place.
Reddit réencode les images téléversées et supprime les segments de métadonnées sur lesquels repose le mode par défaut, de sorte que -r est le seul mode qui y fonctionne. X-Twitter préserve bien un unique petit segment ICC, donc le mode par défaut fonctionne encore sur cette plateforme, mais uniquement pour une charge utile minuscule.
Pour le mode de dissimulation Reddit (-r), nous utilisons la méthode de stéganographie QIM (Quantization Index Modulation dans le domaine DCT JPEG), car c'est la seule méthode de stockage qui fonctionne actuellement pour Reddit. La couverture est transcodée en baseline Q75 4:2:0 et la charge utile est transportée dans ses blocs DCT de luminance.
Pour maximiser la capacité de stockage pour la plateforme Reddit, utilisez une image de couverture de grandes dimensions, 2048x2048, 4096x4096, 8192x8192 (max), etc.
La qualité de l'image de couverture n'est pas importante pour cette méthode et doit rester basique pour les plus grandes dimensions afin d'aider à minimiser la taille du fichier de l'image de couverture.
Bien que la plateforme X-Twitter puisse utiliser la méthode par défaut fournie par jdvrif, où les données sont dissimulées dans des segments APP2/ICC, X-Twitter limite cela à un seul segment ICC d'une taille maximale d'à peine ~10KiB.
Pour transporter plus que ces ~10KiB, utilisez le mode de dissimulation de la plateforme X-Twitter (-x). Il abandonne entièrement les segments de métadonnées — rien n'est écrit dans un profil ICC — et utilise à la place la méthode de stéganographie adaptative J-UNIWARD avec Syndrome-Trellis Coding (STC). La couverture est transcodée en progressif 4:2:0 à sa qualité dérivée de la source (plafonnée à Q97).
Pour maximiser la capacité de stockage pour la plateforme X-Twitter, utilisez une image de couverture de haute qualité/détaillée avec de grandes dimensions, 1024x1024, 2048x2048, 4096x4096 (max), etc.
Les porteurs -r et -x chiffrent vos données et lient leur emplacement à votre PIN de récupération à l'aide d'Argon2id, mais l'intégration modifie tout de même les statistiques DCT de l'image, de sorte qu'une stéganalyse dédiée peut révéler qu'une image contient des données cachées.
Les images -r et -x créées avec jdvrif v9.0 restent récupérables, mais v9.0 ne peut pas récupérer les images -r ou -x créées avec v9.1.
Les deux modes DCT transportent bien moins de données que le mode par défaut, utilisez donc capsize pour mesurer une image de couverture avant de choisir une charge utile (voir Vérification de la capacité).
La compilation nécessite CMake 3.20 ou plus récent, flock de util-linux, et soit Ninja (préféré) soit Make. Le compilateur doit être GCC 14 ou plus récent, ou Clang 18 ou plus récent associé à une bibliothèque standard C++23 qui implémente des fonctionnalités telles que std::format et std::print. Les bibliothèques natives requises sont libsodium, libjpeg-turbo (à la fois les API turbojpeg et libjpeg), zlib et libdeflate. OpenMP est facultatif : lorsqu'il est présent, il parallélise la passe de coût J-UNIWARD de -x.
$ sudo apt update
$ sudo apt install g++ cmake ninja-build util-linux libsodium-dev libturbojpeg0-dev libjpeg-dev zlib1g-dev libdeflate-dev
$ g++ --version # confirm the reported version is 14 or newer
$ chmod +x compile_jdvrif.sh
$ ./compile_jdvrif.sh
$ sudo cp jdvrif /usr/bin
Si votre distribution fournit GCC 14 sous forme de paquet versionné, installez g++-14 et compilez avec CXX=g++-14 ./compile_jdvrif.sh.
Le wrapper conserve les fichiers objets suivis par les dépendances sous src/build/, de sorte que les invocations ultérieures ne reconstruisent que ce qui a changé, et il ne remplace le binaire jdvrif publié qu'après une compilation complète et réussie. Définissez JDVRIF_JOBS=<count> pour modifier la limite de parallélisme (par défaut : nombre de CPU, plafonné à 8), JDVRIF_BUILD_DIR=<path> pour utiliser un cache de compilation séparé, ou BUILD_MODE=sanitize pour une compilation ASan/UBSan.
$ jdvrif