I have just seen this within the past few days and cannot figure out how it works. The video I talk about is here:
It's the top rated answer from this Stack Overflow question: Why was this program rejected by three compilers?
How is this bitmap able to show a C++ program for "Hello World"?
A BMP (DIB) image is composed by a header followed by uncompressed1 color data (for 24 bpp images it's 3 bytes per pixel, stored in reverse row order and with 4 bytes row stride).
The bytes for color data are used to represent colors (i.e. none of them are "mandated" by the file format2, they all come from the color of each pixel), and there's a perfect 1:1 correspondence between pixel colors and bytes written in the file; thus, using perfectly chosen colors you can actually write anything you want in the file (with the exception of the header).
When you open the generated file in notepad, the color data will be shown as text; you can still clearly see from the header (the part from BM to the start of the text), that is mandated by the file format.
In my opinion this video was done this way: first the author calculated the size needed for the bitmap, and created a DIB file of the correct size filled with a color that expands to a simple pattern (e.g. all bytes 65 => 'A'); then replaced such pattern with the "payload" code, as shown in the video.
Notice however that it's not impossible to hand-craft the whole thing with notepad - with the color chooser dialog, an ASCII table and a basic knowledge of the DIB format it can be done, but it would be much much slower and error-prone.
More info about the DIB format
There are RLE compressed DIBs, but in this case uncompressed bitmaps are used (and they are used really rarely anyway).
With the exception of the stride, that was avoided using rows multiple of 4 bytes.
I assume you're referring to the answer to one of the April Fools questions.
My guess is that each pixel has a binary representation for it. And that each character in source code has a binary representation for it.
The person who created the program must have worked out the color for each pixel that'd have a binary representation that'd correspond to each character.
From a theoretical computer science point of view, it would be interesting to ask, if every program can be written in such a way so that, viewed as a bitmap, you actually saw the source code that does the same thing. If you are seriously interested in such results, read e.g. about the Kleene's fixed point theorem.
Program-as-an-image can also be viewed as a form of code obfuscation. Not that it were particularly practical...
Related
I was reading an article explaining How to Hide Files in JPEG Pictures.
I am wondering how it's possible for a file to contain both jpeg data and a rar file without any visible distortion either to the image or to the compressed file.
My guess is that it has something to do with how either the compressed file or the jpeg file is represented in binary form, but I have no idea how this works.
Can someone elaborate on that?
All that is doing is adding the archive to the end of a JPEG stream. You then hope your JPEG decoder will not read past the EOI marker, find data there, and say something is wrong.
A JPEG image is a stream of bytes starting with an SOI marker and ending with an EOI marker.
ZIP and RAR are streams of byte. A ZIP stream starts with 50 4B. A RAR stream starts with 52 61 72 21 1A 07.
The method described in the link above takes a binary copy of (multiple) a JPEG stream and appends a ZIP or RAR stream to it.
The RAR/ZIP decoders scan the stream until they find the signature for RAR or ZIP (ignoring the JPEG stream).
This answer does not address the exact case in the link you gave, but it provides another way of hiding data:
It would also be theoretically possible to hide a file within the JPEG picture itself, but you would need a complicated program to write the encoded data and then read it again.
Basically, a JPEG photograph contains a lot of information which, if it changed, would not be noticeable to the human eye. Imagine you have a photo of a person in a blue shirt. If you zoom in on that shirt you will see that it is not an even blue colour, but made up of a multitude of flecks of colour, most of which are a bluish tone (but some could be other colours as well). You could easily change some of those flecks to a slightly different tone and it would make no obvious visible difference to the picture.
A clever program could embed a code in the photo by subtly changing pixels to a pattern that represents data. A very simple example: if the "hue" (i.e. colour tone) is represented by a number between 0 and 255, pixels of an even hue could represent a "0" bit and pixels of odd hue a "1" bit. It would be hard for the human eye to detect such a difference in the picture.
It is an old idea and this article discusses how much data could be hidden in this way: High capacity data hiding in JPEG-compressed images (2004)
In general, hiding a file within another file is a practice known as Steganography. The method described in the link you provided simply concatenates the .rar to the end of the .jpg using the + operator, taking advantage of the different headers of each file type. #user3344003 does an excellent job of explaining why this works in his/her answer. This doesn't distort the image because the image data is left unaltered.
Another common method of hiding a file within an image is to use the Least Significant Bit (LSB) of each byte. The way this is performed is to replace every 8th bit in the image's bitstream with the next bit of the file you wish to hide. This works because the image's colors can be distorted slightly without being easily perceived by the human eye. In this approach, the image's size on disk will not grow as it would in the method from your link. This makes evidence of the hidden file much harder to detect. For a detailed look at this and other Steganographic methods, see this paper by Bret Dunbar.
there is a simple algorithm that I implemented it with matlab. if you division your image to 8 bit. the most significant bit has most valuable information and you can remove bit 0 and bit 1 without any change on original image. so you can put your file instead of bit 0 and 1. I saw this algorithm in anil.k.jain book.
Can anyone tell me how can an JPEG image be divided in 8 x 8 blocks in C++.
Thanks.
Ah, the die-hard approach. My heart goes out to you. Expect to learn a lot, but be forewarned that you will lose time, blood and pain doing so.
The Compression FAQ has some details on how JPEG works. A good starting point is Part 2: Subject 75: Introduction to JPEG.
In a nutshell, for a typical JPEG file, you will have to reverse the encoding steps 6 to 4:
(6) extract the appropriate headers and image data from the JFIF container
(5) reverse the Huffman coding
(4) reverse the quantization
You should then be left with 8x8 blocks you could feed into an appropriate inverse DCT.
Wikipedia has some details on the JFIF format as well as Huffman tables and structure of the JPEG data within the JFIF.
I'm assuming you're looking to play with JPEG to learn about it? Because access to the raw encoded blocks is almost certainly not necessary if you have some practical application.
EDIT after seeing comments: If you just want to get a part of a very large JPEG without reading/decompressing the whole file, you could use ImageMagick's stream command. It allows you to get a subimage without reading the whole file. Use like e.g. stream -extract 8x8+16+16 large.jpeg block.rgb to get a 8x8 block starting at (16,16).
You have to decompress the image, use the turbojpg library (it's very fast), which will give you an array of unsigned char as RGB (or RGBA). Now you have an uncompressed image, which has a byte value for R G and B respectively.
You can from here, go and make a simple for loop that will go through 3*8 char blocks and copy them, using memcpy to some other memory location.
You have to keep in mind that the array returned from the turbojpg library is a one dimensional linear array of bytes. So the scanlines are stored one after the other. Take this into account when creating your blocks, cause depending on your needs, you'll have to traverse the array differently.
I'm currently doing a steganography project (for myself). I have done a bit of code already but after thinking about it, I know there are better ways of doing what I want.
Also - this is my first time using dynamic memory allocation and binary file I/O.
Here is my code to hide a text file within a BMP image: Link to code
Also note that I'm not using the LSB to store the message in this code, but rather replacing the alpha byte, assuming its a 32 bit per pixel (bbp) image. Which is another reason why this won't be very flexible if there are 1, 4, 8, 16, 24 bpp in the image. For example if it were 24 bbp, the alpha channel will be 6 bits, not 1 byte.
My question is what is the best way to read the entire BMP into memory using structures?
This is how I see it:
Read BITMAPFILEHEADER
Read BITMAPINFOHEADER
Read ColorTable (if there is one)
Read PixelArray
I know how I to read in the two headers, but the ColorTable is confusing me, I don't know what size the ColorTable is, or if there is one in an image at all.
Also, after the PixelArray, Wikipedia says that there could be an ICC Color Profile, how do I know one exists? Link to BMP File Format (Wikipedia)
Another thing, since I need to know the header info in order to know where the PixelArray starts, I would need to make multiple reads like I showed above, right?
Sorry for all the questions in one, but I'm really unsure at the moment on what to do.
The size of the color table is determined by bV5ClrUsed.
An ICC color profile is present in the file only if bV5CSType == PROFILE_EMBEDDED.
The documentation here provides all that information.
Then, 24-bit color means 8 red, 8 green, 8 blue, 0 alpha. You'd have to convert that to 32-bit RGBA in order to have any alpha channel at all.
Finally, the alpha channel DOES affect the display of the image, so you can't use it freely for steganography. You really are better off using the least significant bits of all channels (and maybe not from all pixels).
I've implemented a method that takes an input image and flips it around a vertical line through the center and saves it to an output image file. So whats on the left becomes on the right and vice versa. The image looks great and looks like it flipped perfectly. However, we are given the actual flipped image file that its supposed to look like, and I used the diff utility in terminal to compare the two, and it states that there are indeed differences. Using a program called Kaliedoscope, I was able to find out the difference:there are a handful of pixels that for some reason are colored differently than they should be. Not sure why it is. My code doesnt even manipulate RGB values.
What image format did you save as? If you used a lossy compression, such as JPEG, then the image colours will always be slightly different, as they have been re-compressed. You should use a non-lossy format such as PNG.
You should also not use 'diff' to look at images. I don't know what Kaleidoscope is, but the ImageMagick 'compare' utility is good for looking at the difference between two images. 'diff' will almost always tell you there is a difference between two images, even if they are identical and you used a non-lossy format, due to the fact that when you recompressed it, it might use a different compression technique.
Also, you say you were given the flipped image file (assuming this is a homework thing). In that case, it's possible that the person who generated that file made the mistake (e.g., using a lossy compression). I would not worry about minor pixel differences in that case.
If your function works well, it should be its own inverse (as a necessary condition, although not enough to prove correctness).
Check if
a == flipleft(flipleft(a))
What if you trusted third party testing software has a bug?
HTH!
Edit
Also check the vertical center of the image, to be sure that when the number of horizontal pixels is even you are swapping the two in the middle.
There doesn't seem to be anything obviously wrong with your code.
Since you have a reference image, you can tell the precise pixel positions where there is a difference. I suggest that you step through your program with a debugger (gdb if you're a Linux user, or Visual Studio if that's what floats your boat) and put breakpoints in the inner loop of your code at the problem positions. Using those breakpoints, look for the first point in the program where the problem manifests itself. This will help you find the cause.
Working with smaller images (something that you can print to the command-line at each iteration, for example 8x8 pixels) may save you some time when debugging.
It may be good to post images -- your result and the expected reference.
Modify your code so that you read the input image into an Image and then write it into an output file (without reversal) and compare the input file to the output file.
If they do not match then either the file->Image->file process is corrupting the data (perhaps with a pixel member that is the wrong size, leading to roundoff or use of uninitialized memory) or the comparator (e.g. Kaleidoscope) is wrong, and you can test by just copying the input file and comparing.
If they do match then either your reversal procedure is wrong (which seems unlikely) or the reference file (which the output "is supposed to look like") is wrong, and you can test by altering the code to read in the reference file as well, and report the first disagreement-- that is, construct three Images, Before (read from the input file), After (which will be written to the output file) and Reference (which was read from the reference file), then iterate over x and y, comparing After(x,y) to Reference(x,y). As soon as you find a disagreement, see which one matches Before(width-x-1, y); if Reference matches then your reversal routine is wrong, and if After matches then the reference file is wrong (and you can point to a pixel that proves it).
I'm writing an application that handles metadata for images and all kinds of animations, so I'm looking for a way to find basic info about an animation file, e.g:
length (in minutes/seconds/frames)
aspect ratio of pixels
resolution of individual frames
framerate
Right now, I let my program execute
mplayer -identify animfile.avi
and parse its console output, which contains all the info I need in a machine-readable format. This works fine, but I know that some potential users of the program prefer vlc as a media player so I'd rather avoid having a hard dependence on mplayer being installed.
I've tried
vlc -vv animfile.avi
which prints an ungodly amount of junk on the console, sometimes containing the stuff I'm looking for. The formatting and what data gets printed seems to vary depending on the file format of the animation though.
Is there an easier way to extract basic info from an animation of any format one has a decoder for (especially the length of the animation) using vlc or som other app/library that is usually available on a typical Linux installation?
Edit: I'd rather use another program to do the dirty work, as this is supposed to work for any animation format, e.g avi, mpg, mov, wmv, vob etc.
Edit: totem-video-indexer seems more promising, and was also included with the standard installation. Enough codecs to make it useful, however, was not. That could be fixed by installing the "non-free-codecs" package from medibuntu.
The output of totem-video-indexer is very easy to parse:
TOTEM_INFO_DURATION=5217
TOTEM_INFO_HAS_VIDEO=True
TOTEM_INFO_VIDEO_WIDTH=720
TOTEM_INFO_VIDEO_HEIGHT=480
TOTEM_INFO_VIDEO_CODEC=XVID MPEG-4
TOTEM_INFO_FPS=30
TOTEM_INFO_HAS_AUDIO=True
TOTEM_INFO_AUDIO_BITRATE=50
TOTEM_INFO_AUDIO_CODEC=MPEG 1 Audio, Layer 3 (MP3)
TOTEM_INFO_AUDIO_SAMPLE_RATE=48000
TOTEM_INFO_AUDIO_CHANNELS=Stereo
mediainfo is a pretty useful program. It's LGPL, and is just a frontend for libmediainfo, which should be exactly what you want.
http://mediainfo.sf.net/
This is a little more difficult question than you may realize. The AVI file format grew over time, and often has nearly the same information in two or three different places. In some cases those are really supposed to agree (but sometimes don't) and in other cases they're subtly different.
Just for example, you asked about the width and height. There are actually four different width/height specs for a single frame: the screen width/height, the pixel width/height (from which you derive the pixel aspect ratio), the active width/height, and the compressed width/height. The frame width and height is the (theoretical) size of the screen. The active width/height excludes the overscan area. The compressed width/height takes into account rounding -- for example, JPEG compresses in blocks of 8x8 pixels, so the compressed width and height have to be multiples of 8 for a motion JPEG file. The active width/height tells you if (for example) some pixels at the border should be ignored.
In any case, since your question is tagged C++, I'm going to guess you'd rather read the file and get the data directly than depend on spawning something else to do the dirty work. If so, you probably want to look at the OpenDML AVI file spec. You can get at least some idea of the length, resolution, and framerate just from reading the basic AVI header, which is in a fixed spot at the beginning of the file, so that much is trivial to get. It'll take a bit more work to get to the pixel aspect ratio though...