Jpeginsert is an open source program for Linux/Unix by Karel 'Clock' Kulhavý from Twibright Labs. Jpeginsert is written in the C programming language and has only 1 source file and a makefile. Jpeginsert inserts data of unlimited length without using steganography (subtle change in picture pixels) and without using EXIF (tags to carry additional information).
How to test:
find /lib /usr/lib -iname 'libgmp.so'
should find a file.
find /lib /usr/lib -name 'libgmp.a'
should find a file.
If not found, install statically linked GMP library by these commands. If your system still doesn't support static linking,
remove -static
from the Makefile later during compilation.
libgmp-dev
gmp-devel
gmp-devel, gmp-static
libgmp-devel
libgmp-devel, libgmp-devel-static
gmp-dev
lib64gmp-devel
gmp
libgmp10
cc
should print an error different from "cc: command not found".
If it doesn't work, install by:
build-essential
build-essentials
devel_basis
gcc
sudo yum groupinstall "Development Tools"
build-base
disable-static
to enable-static
in the instructions, example: LFS 6.9.11 GMP 6.2.0,
make --version
should say "GNU Make". Other types of the Make program may work as
well.
gmake
make
*.sh
scripts yourself. Package name:
mpv
/bin/bash
. Normally is pre-installed except on OpenBSD, FreeBSD, NetBSD.
sha256sum jpeginsert_20220817T03.tgz md5sum jpeginsert_20220817T03.tgzResults should be as follows. If they are wrong, someone is trying to hack your computer by giving you tampered infected files, or I made a mistake while updating these numbers.
SHA-256: 587845ebf1f2abb3161a031370118e57bdd2b001e93a4ce104757b0af712e379 jpeginsert_20220817T03.tgz MD5: 1425a838d246b60b8f0090e2a8ad4c7b jpeginsert_20220817T03.tgz
tar xvf jpeginsert_20220817T03.tgz
). It will create the directory jpeginsert_20220817T03
.
cd jpeginsert_20220817T03
-static
from the Makefile.
make jpeginsert
sudo make install
Run the following commands and they should print messages similar to these:
Command to run | Should print something like this |
---|---|
jpeginsert
|
Usage: jpeginsert i carrier_picture.jpg - inserts data from stdin into the carrier_picture.jpg and outputs the resulting enlarged .jpg onto the stdout jpeginsert x - takes .jpg that contains data inside, on stdin, extracts the data and outputs the data on stdout |
jpeginsert_play_file.sh
|
Usage: /usr/bin/jpeginsert_play_file.sh JPEG_with_embedded_multimedia_to_play.jpg |
jpeginsert_play_music_file.sh
|
Usage: /usr/bin/jpeginsert_play_music_file.sh JPEG_with_embedded_multimedia_to_play.jpg |
jpeginsert_play_url.sh
|
Usage: /usr/bin/jpeginsert_play_url.sh URL_with_JPEG_with_embedded_multimedia_to_play |
carrier.jpg
into which nothing has been inserted yet
movie.mkv
into carrier.jpg
and create a big bloated JPEG file
bloated.jpg
jpeginsert i carrier.jpg < movie.mkv > bloated.jpg
bloated.jpg
still shows the original picture by e.g. gmic bloated.jpg
. It may take
a long time. It will not take more RAM.
bloated.jpg
from the previous step (insertion) and want to see the movie inside it.
jpeginsert_play_file.sh bloated.jpg
and the movie will play directly
jpeginsert x < bloated.jpg > movie_extracted.mkv
jpeginsert_play_music_file.sh bloated.jpg
and the picture
will show as an artwork, the music playing at the same time.
bloated.jpg
is on the Internet, we don't need to download it, we can directly play it with
jpeginsert_play_url.sh
*.sh
scripts can be edited in /usr/bin
to accomodate your favorite movie player (mplayer, VLC, etc.) and their options.
Warning: some of these files are huge, they may incur Internet fees, slow down your Internet, hang up your program or consume all the RAM and crash your computer (depending on the quality of the software which looks at them)
The original JPEG standard from 1992 prescribes quantization tables which have to be in every image, otherwise it cannot be displayed. There are 4 tables, slots 0-3. These quantization tables can be defined in blocks of several quantization tables and each of these tables in the block can go into a slot 0-3. The standard allows to redefine a slot over and over. So we redefine these tables over and over with nonsensical data which are the data we want to carry. At the end, we insert the original quantization tables, which will overwrite the nonsensical data and the JPEG will work as normally.
The coefficients are prohibited from being 0 so out of the 256 combinations 0-255 we have only 255 available: 1-255. So we need to do some heavy arithmetic using the GMP library to recalculate base 256 information into base 255 information.
The process is fast and highly efficient, the overhead is only few %. The algorithm has been heavily manually optimized for speed.
It adds tons of information which has the form of quantization tables which have to be present in the JPEG anyway, otherwise it cannot be displayed. It doesn't change the pixels and also doesn't add EXIF tags which are for additional data.
Yes, you can make an infinitely big JPEG. Of course it cannot be stored on a hard disk or a server, it can be only made on the fly in a pipe between programs, as dynamically generated web content from a CGI script, streaming etc.
Some softwares (and smartphones) sometimes strip EXIF metadata, but they cannot blindly strip quantization tables, otherwise the JPEG couldn't be viewed at all. These softwares will not destroy the data. Jpeginsert doesn't use EXIF metadata to store information.
However other software like Facebook decodes the JPEG, changes size, compression quality and reencodes. This will delete the information (e. g. video file, audio file) embedded inside. This process will make the JPEG small again.
Lossless rotation program Jpegtran deletes the information, even when you specify -perfect
and -copy all
For email, IRC chat and web IRC chat see Twibright Labs contact to Karel Kulhavy