How to find hidden files inside image files (Jpg/Gif/Png) [closed]

Question

I came across a link that shows how to hide number of files inside an image file: http://lifehacker.com/282119/hide-files-inside-of-jpeg-images more discussion on detection here: http://ask.metafilter.com/119943/How-to-detect-RARsEXEs-hidden-in-JPGs

I'm trying to find out what is a good way to programmatically detect whether an image file has other files hidden inside it? Should I try unzipping the file to see if other files come out of it?

I'm not bound programmatically but something that works well on the JVM would be great.

Update

One Approach:

Would something like this work (suggested by someone on metafilter)

$ cat orig.jpg test.zip > stacked.jpg
$ file stacked.jpg 
stacked.jpg: JPEG image data, JFIF standard 1.01
$ convert stacked.jpg stripped.jpg  # this is an ImageMagick command
$ ls -l
 11483 orig.jpg
322399 stacked.jpg
 11484 stripped.jpg
310916 test.zip

I could use JMagick for this approach.

Answer 1

Great question!

If all you want to check for is a RAR or ZIP file appended to the end of an image file, then running it through the unrar or unzip command is the easiest way to do it.

If you want a faster but less exact check, you can check for some of the special file format signatures that indicate certain types of files. The usual UNIX tool to identify file format is file. It uses a database of binary file signatures, whose format is defined in the magic(5) man page. It won’t find a RAR file for you at the end of a JPEG, because it only looks at the start of files to try to identify them quickly, but you might be able to modify its source code to do what you want. You could also reuse its database of file signatures. If you look at the archive file part of its database in the Rar files section, it shows this:

# RAR archiver (Greg Roelofs, newt@uchicago.edu)
0   string      Rar!        RAR archive data,

which indicates that if your JPEG file contains the four bytes Rar! that would be suspicious. But you would have to examine the Rar file format spec in detail to check whether more of the Rar file structure is present to avoid false positives—this web page also contains the four bytes Rar! but there are no hidden files attached to it :P

But if someone knows the details of your automated checks, they could easily work around them. The simplest workaround would be to reverse all the bytes of the files before appending them to the JPEG. Then none of your signatures would catch the reversed version of the file.

---

If someone really wants to hide a file inside an image, there are all sorts of ways to do that that you won’t be able to detect easily. The general term for this is “steganography.” The Wikipedia page, for example, shows a picture of trees that has a picture of a cat hidden inside it. For simpler steganographic methods, there are statistical tests that can indicate something funny has been done to a picture, but if someone spends a lot of time to come up with their own method to hide other files inside images, you won’t be able to detect it.

Answer 2

You could search for the file signature. http://en.wikipedia.org/wiki/List_of_file_signatures e.g. for 7z file the sigature is 37 7A BC AF 27 1C for rar files it's 52 61 72 21 1A 07 00 and for zip it's 50 4B 03 04 Take a look at a compressed file in a hex editor e.g. HxD

Answer 3

To see if there's any metadata or other information appended to the file, you could decode the image and re-encode it to see if the size decreases dramatically. For a JPEG file you would want to do something like a lossless rotate that retains the original DCT data, otherwise the file size might change just through encoding differences.

A smaller result wouldn't be proof of hidden data, but it would be an indicator that you need to take a closer look.

You never shared your motivation for asking the question, but I'm going to guess that it's about downloading images to a public site. In that case you really shouldn't care whether the submitted image contains extraneous data, you should just cleanse the input regardless. The decode/re-encode process would be perfect for this.