2

I'm creating a program that "hides" an encrypted file at the end of a JPEG. The problem is, when retrieving this encrypted file again, I need to be able to determine when the JPEG it was stored in ends. At first I thought this wouldn't be a problem because I can just run through the file checking for 0xFF and 0xD9, the bytes JPEG uses to end the image. However... I'm noticing that in quite a few JPEGs, this combination of bytes is not exclusive... So my program thinks the image has ended randomly half way through it.

I'm thinking there must be a set way of expressing that a JPEG has finished, otherwise me adding a load of bytes to the end of the file would obviously corrupt it... Is there a practical way to do this?

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
Stephen Cook
  • 171
  • 2
  • 11
  • 1
    There are much better ways of acheiving [steganography](http://en.wikipedia.org/wiki/Steganography). For example, with the proposed method, the "hidden" data will show up when `grep` is run. – Ben Voigt Feb 03 '11 at 23:37

4 Answers4

1

You should read the JFIF file format specifications

Benoit
  • 76,634
  • 23
  • 210
  • 236
  • Although reading that has greatly increased my understanding of JPEG FIF - I don't really see how anything in there can be used to solve my problem? Unless you're meaning that the first 0xFF 0xD9 is because of the end of the thumbnail, so I could check to see if the thumbnail exists, if so, run the function twice? – Stephen Cook Feb 03 '11 at 20:00
  • Actually my link was wrong. I think searching for a sequence of bytes is absolutely wrong, it could be in the middle of raw data. You should know what the bytes represent, decode the headers and extract the size of the raw data. – Benoit Feb 03 '11 at 20:17
  • Decoding the headers would definitely be a nice way to go, but I can't find anything (including in what you sent me) about a header value that states how long the file is. Or any way to deduce it. – Stephen Cook Feb 03 '11 at 20:32
  • Yes, on the website of the W3C you have a JPEG FAQ (I cannot find the link) – Benoit Feb 03 '11 at 20:48
  • Old question, I know, but for anyone looking: [JPEG FAQ Part1](http://www.faqs.org/faqs/jpeg-faq/part1/) and [JPEG FAQ Part2](http://www.faqs.org/faqs/jpeg-faq/part2/) – leanne Mar 08 '15 at 18:13
0

You're likely running into the thumbnail in the header, when moving through the file you should find that most marked segments contain a length indicator, here's a reference for which do and which don't. You can skip the bytes within those segments as the true eoi marker will not be within them.

Within the actual jpeg compressed data, any FF byte should be followed either by 00 (the zero byte is then discarded), or by FE to mark a comment (which has a length indicator, and can be skipped as described above).
Theoretically the only way you encounter a false eoi reading in the compressed data is within a comment.

IAmJersh
  • 742
  • 8
  • 25
0

Well, there are always two places in the file that you can find with 100% reliability. The beginning and the end. So, when you add the hidden file, add another 4 bytes that stores the original length of the file and a special signature that's always distinct. When reading it back, first seek to the end - 8 and read that length and signature. Then just seek to that position.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Yeah I was thinking about doing this, my only worry is that for big image files this won't work. And I know the image would have to be 4GB (if my Maths is correct) for this to not work, but I wanted to avoid the practise? Not that I went to better ones in order to avoid it, I suppose... – Stephen Cook Feb 03 '11 at 20:36
  • Well, use 8 bytes then, __int64. – Hans Passant Feb 03 '11 at 20:50
0

You should read my answer on this question "Detect Eof for JPG images".

Community
  • 1
  • 1
onemasse
  • 6,514
  • 8
  • 32
  • 37