Since I have gone over the basic structure of the jpeg file, I now need to show some of the headers needed to parse a jpeg file. I will include their byte signatures and structures as well as their names from the official JPEG standard. That way when you read other literature it wont be as confusing.  This will probably be a boring read, but it will be useful for reference purposes later. (I’m half writing this for myself so I have it written down somewhere)

Headers

Start of Image:

• Abbreviation – SOI
• Length – 2 bytes
• Byte Value – 0xFFD8
• Description – The simplest of the markers. This marker is the first two bytes of every jpeg file and has nothing following it. These two bytes imply that this file is most likely a jpeg file.
• Example:

Application Data:

• Abbreviation – APP1 – APP15
• Byte Value – 0xFFE0 – 0xFFEF
• Description – Not to be confused with comments, this marker identifies applications information that is not defined in the official standard. The APP0 marker is special however and holds information specific to the JFIF and EXIF implementations of the jpeg. From what I can tell the jpeg standard was too vague so some guy came up with the JFIF standard and it stuck, EXIF is newer but definitely sticking, especially with digital cameras. Other than the APPo segment the data is application specific, so just skip the data unless you want to write a lot of parsers for it. Otherwise the structure of the APP0 segment (as defined by JFIF) is below.
• Structure -
  1. Marker – 2 bytes
     1. Byte Value – 0xFFE0 – 0xFFEF
  2. Length – 2 bytes
     1. Again, this includes the length bytes
  3. identifier – 5 bytes
     1. 0x4A46494600 (“JFIF” in ascii) (if this was an EXIF image then this would be “EXIF”)
  4. version – 2 bytes
     1. the most significant byte is used for major revisions
     2. the least significant byte for minor revisions
  5. units – 1 byte:
     1. Units for the X and Y densities
     2. 0 => no units, X and Y specify the pixel aspect ratio
     3. 1 => X and Y are dots per inch
     4. 2 => X and Y are dots per cm
  6. Xdensity – 2 bytes
     1. Horizontal pixel density
  7. Ydensity – 2 bytes
     1. Vertical pixel density
  8. Xthumbnail size – 1 byte
     1. 0 = no thumbnail
  9. Ythumbnail size – 1 byte
     1. 0 = no thumbnail
  10. Thumbnail data – 3n bytes
      1. packed (24-bit) RGB values for the thumbnail pixels
      2. n = Xthumbnail * Ythumbnail

Example:

Filled in:

Huffman Tables:

• Abbreviation – DHT
• Byte Value – 0xFFC4
• Description – This segment defines the Huffman tables to be used to decompress the jpeg data. More information about it can be found here.
• Structure -
  1. Marker signature (2 bytes)
     1. 0xFFC4
  2. Length of data (2 bytes)
     1. Remember length of data includes the 2 length bytes

     Everything after this point is repeated (usually for 4 tables) until the length is exhausted

  3. Table Identifier (1 byte)
     1. The 4 high bits determine the class: 0=DC table, 1=Ac table. The 4 low bits specify the table identifier (0,1,2, or 3).
  4. Number of values for each bit length (16 bytes)
     1. The position of each byte represents the bit length of the Huffman table and each byte value is the number of values for that bit length. For example, if the data is 0×000105 then there will be 0 values with a bit length of 1, 1 value with a bit length of 2 and 5 values with a bit length of 3.
  5. Actual values (*Sum of values above* bytes)
     1. Length is equal to the sum of the values in # 4. So for the example above 0×000105 would translate to 6 bytes.

0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
FF	C4	#2		#3	#4
#4 cont.					#5 …

Quantization Table:

• Abbreviation – DQT (Define Quantization Table)
• Byte Value – 0xFFDB
• Description – This segment defines the Quantization tables to be used. All of the Quantization tables are defined in this one definition, there can’t me multiple DQT headers. The data almost always consists of 3 tables which are made up of 1 table information byte and 64 table elements. The byte length of the table elements are determined by the information byte.
• Structure -
  1. Marker signature (2 bytes)
     1. 0xFFDB
  2. Length of data (2 bytes)
     1. Remember length of data includes the 2 length bytes

     Everything after this point is repeated (usually for 3 tables) until the length is exhausted

  3. Table Identifier (1 byte)
     1. The 4 high bits determine how many bytes make up an element
        1. 0 = 1 byte per element so 64 bytes per table
        2. 1 = 2 bytes per element, so 128 bytes per table
     2. The 4 low bits are the number associated with the table (0-3)
  4. The 64 elements of the table (64 or 128 bytes depending on #3)
     1. Each element is used to fill in the table in a zig-zag formation as shown below.

Table Layout

Restart Interval:

• Abbreviation – DRI  (Define Restart Interval)
• Byte Value – 0xFFDD
• Description – This market specifies the number of MCUs (Minimum Coded Units) between restart markers. If the value is 0 then there are no reset markers. This can be used for parallel processing of jpeg images.
• Structure -
  1. Marker signature (2 bytes)
     1. 0xFFDD
  2. Length of data (2 bytes)
     1. Always = 4 (Remember length of data includes the 2 length bytes)
  3. Number of coded units between restart markers

Frame Header:

• Abbreviation – SOF  (Start of Frame)
• Byte Value – 0xFFC0
• Description – This is a marker to indicate the start of a frame. There can be only one.
• Structure -
  1. Marker signature (2 bytes)
     1. 0xFFC0
  2. Length of data (2 bytes)
     1. Remember length of data includes the 2 length bytes
  3. Data precision (1 byte)
     1. 8 or 12 bits
  4. Image Height in pixels (2 bytes)
  5. Image Width in pixels (2 bytes)
  6. Number of components (1 byte)
  7. Component 1-N
     1. Component ID (1 byte)
        1. JPEG defines it as 0-255 but JFIF restricts it to 1,2,3
     2. Horizontal Sampling (high 4 bits)
        1. Values: 1,2,3, or 4
     3. Vertical Sampling (low 4 bits)
        1. Values: 1,2,3, or 4
     4. Quantization table ID (1 byte)
        1. Can be 0,1,2,3

Comment:

• Abbreviation -COM  (Comment)
• Byte Value – 0xFFFE
• Description – This is a marker to indicate a comment.
• Structure -
  1. Marker signature (2 bytes)
     1. 0xFFFE
  2. Length of data (2 bytes)
     1. Remember length of data includes the 2 length bytes
  3. Comments
     1. Any information, often application specific

Start of Scan:

• Abbreviation -SOS  (Start of Scan)
• Byte Value – 0xFFDA
• Description – This is the last header before the compressed image data.
• Structure -
  1. Marker signature (2 bytes)
     1. 0xFFDA
  2. Length of data (2 bytes)
     1. Remember length of data includes the 2 length bytes
  3. Component Count (1 byte)
  4. Component Descriptions (2 * Component Count) (Note, the order these components appear is the order in the compressed data)
     1. Component ID (1 byte)
     2. DC Huffman Table ID (4 high bits)
     3. AC Huffman Table ID (4 low bits)
  5. Spectral Selection Start (1 byte)
     1. 0-63
  6. Spectral Selection End (1 byte)
     1. 0-63
  7. ‘Successive Approximation’ (two 4-bit fields, each in the range 0-13)

End Of Image:

• Abbreviation – EOI  (End of Image)
• Byte Value – 0xFFD9
• Description – This is a marker to indicate the end of an image. These are the last two bytes of a file.
• Structure -
  1. Marker signature (2 bytes)
     1. 0xFFD9

That took forever to make but now that it’s over I hope to get more motivated and post something more interesting.

Java Web Start

For those of you that do now know what Java Web Start applications are, check out this site and this one. For simplicities sake, Java Web Start enables java applications to be downloaded and run off of someone’s computer via a website or an application. Basically the program is downloaded, cached and run to allow for developers to easily provide java applications to the end user. These programs are usually in a sandbox so they cant access any files that aren’t specific to the application. However, if the java application is signed, the application can access anything that the user has permission on.

Problem

According to the Zero Day Initiative, Java Web Start suffers from a “JPEG Header Parsing Integer Overflow”. From my post earlier, we learned how the Microsoft Library was vulnerable to the manipulation of JPEG headers. From the title, and subsequent description of this zero day vulnerability, I think it is pretty obvious that Java Web Start suffers from the exact same problem.

Attack Vector

Really the best avenue would be to attack a signed application so you could get the best access to the computer. Fortunately, (or unfortunately depending how you look at it?) Java Web Start is still relatively new I believe (or just not that widely used) so there aren’t too many programs to attack. That being said, if you find an application that is vulnerable, then that is a good way in as most people don’t even think of things like buffer overflows in java applications. As I’ve said before, the java application can be run through a web site link, so if you click on something that launches java, maybe be a little careful.

Impact

Java Web Start is not widely used and it is probably not that common to have the program load too many images. That being said, the application can be launched through a web link, so it’s possible that someone could start posting links to a java application and tricking uses to click on them. If an attacker has access to your local network he can substitute legitimate pictures traveling across the net with malicious ones so there is some risk there. If you have an anti-virus then you might get lucky depending on how the application works. If the jpeg is stored in an intermediate location then the anti-virus will probably detect and delete it. If the jpeg is loaded directly to memory then you’ll be out of luck.

Mitigation

Java has issued a patch to solve this issue, so update java. Read More

Lessons Learned

Old vulnerabilities are still relevant today and can show up in trusted products. With my previous post one could easily craft something to break the java application and, with a little work and knowledge, one could easily form a respectable exploit. So don’t run random programs you don’t need and always keep your software up to date. Also, as a developer, always do sanity checking on lengths. These problems are all avoidable if you just practice good programming practices.

Most jpeg files use Huffman encoding for compression. This compression relies on Huffman trees which are stored in the jpeg file and are used to decompress the image data.  (If you are not familiar with Huffman encoding there is a good explanation on wikipedia) Therefore, we need to understand the structure of the Huffman trees in the jpeg file in order to extract them and then extract the image.

Huffman Table Marker Structure

Ok, so to start we need to identify the marker that identifies a Huffman Table (0xFFC4). The structure of this marker is as follows:

1. Marker signature (2 bytes)
   1. 0xFFC4
2. Length of data (2 bytes)
   1. Remember length of data includes the 2 length bytes

   Everything after this point is repeated (usually for 4 tables) until the length is exhausted

3. Table Identifier (1 byte)
   1. The 4 high bits determine the class: 0=DC table, 1=Ac table. The 4 low bits specify the table identifier (0,1,2, or 3).
4. Number of values for each bit length (16 bytes)
   1. The position of each byte represents the bit length of the Huffman table and each byte value is the number of values for that bit length. For example, if the data is 0×000105 then there will be 0 values with a bit length of 1, 1 value with a bit length of 2 and 5 values with a bit length of 3.
5. Actual values  (*Sum  of values above* bytes)
   1. Length is equal to the sum of the values in # 4. So for the example above 0×000105 would translate to 6 bytes.

Parsing the table

Now, assuming you’ve read the Wikipedia entry, you know that we need to figure out how to translate the bit length to the tree aspect. While I may provide code for that later, I figured I would at least step through how to create it. I should also add that, from what I’ve read, most jpeg decoders do not create an actual tree, but instead create look-up tables to improve performance. I am going to try to explain it in tree form and then you may convert it as you see necessary. Let us assume that the first section of our data is as follows:

The first two bytes are the marker data so we skip those (in green). The next two bytes are the length (in blue) so we read them in and since the length is 0x01A2 then the actual length is 418 bytes (only one table is shown so this length does not match correctly!). After the length there is the table identifier 0×00 (purple) which means that this is a DC table (higher 4 bits = 0) and the identifier is 0. After that we have the values for each bit length (pink).  Now each byte in this segment represents a level in the tree. The value of each byte represents the number of endpoints on that level. So for example, the first 3 bytes are  0×000105. This means that on the first level of the tree there are no endpoints, on the second level there is one endpoint, and on the third level there are five endpoints. All of the values are filled in from the left side of the tree to the right and, therefore, the tree would look something like the following (please excuse by horrible ascii drawing):

           -------   Level 1
          |       |
       ----       -----   Level 2
      x    |     |     |
          ---   ---   -----   Level 3
         x   x  x  x  x   |
                         ---

Now that the structure is understood, how are those values filled in? Well the sum of all of the endpoints will equal how many additional bytes we need to read in. So we add up the level bytes and get: 00+01+05+01+01+01+01+01+01+00+00+00+00+00+00+00 = 12 bytes. So we read in the next 12 bytes, fill in the empty spots as we go, and we get the following (only partial tree shown):

           -------   Level 1
          |       |
       ----       -----   Level 2
      0    |     |     |
          ---   ---   -----   Level 3
         1   2  3  4  5   |
                         ---

Parsing the Data

So now that the tables are filled in, how are they used? Well, the tree is traversed by a zero bit going down the left side of a decision and a 1 bit navigating the right. For example, the byte 0×00 (shown above on the far left of the tree as just 0) is represented by the bits: 00 whereas the byte 0×01 ( shown above as 1) would be the bits 010. So if you had a byte of compressed data like 0xA5 then that would translate to 1010 0101 in binary. If we use the above Huffman Tree then we will find that would translate to 101 = 0×04, 00 = 0×00, 101 = 0×04. At this point we have successfully decoded 3 bytes from the original one.

Caveats

Now I should mention a few things. First, the decoded bytes will not always rest on a byte boundary. In the bigger Huffman tables you can and will have bit strings with 16bits in length. You ask why it makes sense to represent a single byte with 16bits? Well the Huffman encoding relies on some byte values appearing much more common than others. This means that bytes that are extremely rare can be represented in 16bits and it will still equal a considerable compression since the extremely common bytes are only represented in a small number of bits. This also means that parsing data will be difficult as one cannot just read in a pre-determined number of bytes and parse them. This will also stand as a huge barrier to overcome once we look into carving jpeg pieces that have become fragmented. But I’ll deal with that when the time comes.

Second, the compressed data in jpeg files isn’t just raw pixel data compressed using Huffman encoding. Instead of simply the red/blue/green values for a pixel, the compressed data contains a lot of information that allows the decode to create those values. I’ll go into all of that in a later post, but with the above knowledge you will be able to successfully parse through the compressed data once you know how it’s structured.

As promised, I said I would look into why the jpeg format was exploitable for a period to the windows OS and various applications. The answer I came up with was actually pretty interesting. (If you aren’t already familiar with the jpeg format then take a look at my previous post first)

Intro

As you can probably remember (or just read), jpeg files consist of various markers before the actual image data. The interesting thing about the markers happen to deal the length of the data which is represented as 2 bytes. The important part is that these two bytes include the length bytes (for example a length of 6 is actually 2 length bytes and 4 bytes of data). This means that technically a value of 1 or 0 for the length is invalid and parsing should be halted immediately.

Explanation and Impact

So, the problem arose when the library to decode jpeg files would read in a length and then subtract 2 from it to know how many more bytes to read in. This would result in a -2 or -1 for the length. Well it turns out that, before any verification, the length was transformed into a 32bit integer. This would make -2 into approximately 4GB and the subsequent read would trigger a buffer overflow.

So how severe was the problem? Well it turns out that the vulnerable code resided in the GDI, or Graphics Device Interface, which is basically a library that Microsoft provided for many programs to use. Therefore, all of the programs relying on this library were vulnerable and Microsoft had a fairly long list of programs using it.

Detection and Removal

Since the exploit was proven, how would one detect this attack? Well it seems fairly straightforward once you know all of the facts. Basically one would just need to parse the markers as usual and attempt to detect a length of less than 2. An example script demonstrating this can be found at the end of this post. If you decide to test this then I should warn you that if you create a jpeg file with a manipulated marker length then it seems all of the common anti-virus seem to detect it. This will probably result in it removing your image and either way it’s reported in the AV stats… So I wouldn’t test it at work (like I did… that’s a fun one to explain).

The normal anti-virus removal seems a little harsh as I would be rather upset if my personal images were deleted. Instead, lets investigate if we can remove the infection. For a jpeg, obviously what we truly care about is the ability to show the picture. Since it is possible to exploit any of the headers except for the SOS (Start of Scan-> 0xFFDA) marker then it is possible that the compressed image data could be unmodified. So, we need to determine which markers we actually need in order to decompress an image…they are as follows:

• The Main Marker (Usually JFIF marker: xFFE0)
• Quantization table marker (0xFFDB)
• Huffman table markers (FFC4)
• Start of frame marker (FFC0)
• Start of Scan marker (FFDA)

If all of these markers are present and non-malicious then remove the others and save the file. This means that the maliciousness is most likely in the comments section of the jpeg and that is used primarily by image editors like photoshop to store other interesting information about the file.

If any of these markers are NOT present or are malicious, then it becomes tricky. Basically this will probably depend on whether or not the image is a digital camera image or one processed using an image editor. The reason lies in the structure of jpeg compression. I will elaborate further on this in another post, but basically jpeg compression uses binary trees to create shorter bit strings to represent common bytes. This is called Huffman compression and if you don’t want to wait for my explanation there are plenty on the net. The important fact is that the tree used is then stored in the jpeg file. Since digital cameras do not have a lot of processing power, they often use a hard-coded huffman tree for compression. This results in smaller files but not optimal compression. In contrast, photoshop forms its tables based on the image data. This results in optimal compression, but it uses different trees for each file.

So what does this all mean? Well if you have two images from the same digital camera (and using the same compression settings) then in all likelihood you can use the same tables from the other image to fix the corrupted image. This would actually have a pretty good chance of success but, in all fairness to the AV companies, it would be hard to automate. If I get a chance later, I’ll try to show an example in a later post. For now, I’ll leave you with the code I wrote that verifies a jpeg file is not malicious. If you want more information about the vulnerability and its exploitation then have a look here as it was an excellent writeup on all of the very technical details about the problem.

Code

NOTE: this is not optimized, nor should it be used in production environments. I just wrote this to give you a quick look into how jpeg files are structured and how simple it is to detect a malicious one:

[EDIT] The first program is in perl and I have added a second in C# below it. The C# program does not do as much checking as the perl version, but it will still detect malicious jpeg files.

use warnings;
my $buffer;
my $numRead;
my %verified;
my %signatures = ( "APPS"=> "^\xFF[\xE0-\xE9]", "QT"=>"^\xFF\xDB", "Huff"=>"^\xFF\xC4","SOF"=>"^\xFF\xC0","SOS"=>"^\xFF\xDA");

#quit if user did not provide a file name or the file doesn't exist
die "You must provide a filename" if(!$ARGV[0] || !(-f $ARGV[0]));

#open the file
open($IN,"<".$ARGV[0]);

#use binary reading
binmode($IN);

#read in the first two bytes
$numRead = read($IN,$buffer,2);

#Die if it doesn't look like a jpeg file
die "File is not a JPEG" if!($buffer =~ /^\xFF\xD8/);

#loop forever
while(1)
{
	$numRead = read($IN,$buffer,4);

	#if there is nothing else to read
	if($numRead < 4)
	{
		#exit the program
		determineSuccess();
		last;
	}

	#exit if we are at the compressed data segment
	if($buffer =~ /^\xFF\xDA/)
	{
		$verified{"SOS"} = 1;
		#exit the program
		determineSuccess();
		last;
	}

	#if the header does not start with \xFF then it's corrupt
	if(!($buffer =~ /^\xFF/))
	{
		print "Could not find marker, file appears corrupt\n";
		last;
	}

	#check to see if we're at a known header
	foreach $key (keys(%signatures))
	{
		if($buffer =~ /$signatures{$key}/)
		{
			$verified{$key} = 1;
		}
	}

	#unpack the length as an unsigned short in big-endian
	$len = unpack("n",substr($buffer,2,2));

	#check to see if the length is bad
	if($len < 2)
	{
		print "Jpeg appears to have malicious content\n";
		last;
	}

	#skip the header data
	$numRead = read($IN,$buffer,$len-2);
}

sub determineSuccess
{
	#Success if all of the necessary segments were found
	if($verified{"APPS"} && $verified{"QT"} && $verified{"Huff"} && $verified{"SOF"} && $verified{"SOS"})
	{
		print "Verified! - Jpeg appears to have no malicious content\n";
	}
	else
	{
		print "Jpeg appears to be missing a segment(s)\n";
	}
}

And an example in C#

using System;
using System.IO;
namespace JpegVerifier
{
	///
	/// This class will verify the jpeg sent to it
	///
	class Class1
	{
		///
		/// The main entry point for the application.
		///
		[STAThread]
		static void Main(string[] args)
		{
			byte[] header;
			int length;
			BinaryReader br;

			if(args.Length < 0)
			{
				return;
			}

			br = new BinaryReader(File.OpenRead(args[0]));

			try
			{
				header = br.ReadBytes(2);

				if(header[0] != '\xff' ||
					header[1] != '\xd8')
				{
					System.Console.WriteLine("File is not a JPG");
					return;
				}

				while(true)
				{
					//if the header is 0xffda then we're at the image data
					header = br.ReadBytes(2);
					if(header[0] == '\xff' &&
						header[1] == '\xda')
					{
						//Assume jpg is well formed
						System.Console.WriteLine("Jpeg File is Clean");
						return;
					}

					//if the header does not start with 0xff then it's not a header
					if(header[0] != '\xff')
					{
						System.Console.WriteLine("Jpeg Marker is corrupt");
						return;
					}

					//assume marker is valid for our purposes
					//read in length
					length = br.ReadUInt16();

					//convert to BigEndian
					length = ((0x00FF & length) << 8 | (0xFF00 & length) >> 8 );

					if(length < 2)
					{
						System.Console.WriteLine("Jpeg is MALICIOUS!");
						return;
					}

					//skip the marker data
					br.ReadBytes(length-2);
				}
			}
			catch(Exception e)
			{
				System.Console.WriteLine(e.Message);
			}
		}
	}
}

I have made progress on breaking down the basic JPEG format. Through reading the ISO standard and various sites online I have found that a JPEG file normally consists of the hex values 0xFFD8 followed by a number of JPEG “markers” until the marker 0xFFD9 which indicates an end of file.

Basically a JPEG Marker is the bytes 0xFF followed by a marker byte which signifies a different piece of the JPEG file. In addition, each JPEG Marker (except for one) follows this pattern…

1. Header
   1. 2 bytes beginning with 0xFF
2. Length of data (including length bytes)
   1. 2 bytes
3. Data
   1. [Length] bytes

The view on disk would be as follows:

The data can then follow a variety of formats depending on what the marker was. For a breakdown of the major ones visit this site but there are also a variety of proprietary ones that can often tell you a lot about the tools used to create the pictures. For example.. many pictures will actually have the photoshop version and date the picture was edited. Have you ever wondered if a photo was edited? A quick look at the picture’s internals can often tell you a lot about the picture.

So, what is the one that breaks the pattern? 0xFFDA or the “Start of Scan” marker which is the beginning of the actual compressed image data. I will dive into much detail on this later but to start this field should contain no other markers except for possibly 0xFFD[1-7] or the reset marker. (This marker will make it possible to simultaneously decompress different parts of the image) Finally, the image is finished with the bytes 0xFFD9. An overall view would be as follows:

I’ve decided that the first stop is an intricate look into the JPEG file format. I’ve always wanted to write a JPEG parser/carver and this seems like a good time to start. For those of you that are thoroughly confused as to why this would be helpful I know numerous people who have “lost” pictures on corrupt hard drives in the past and while i have researched some tools there aren’t any decent tools that I have found.

So what do I hope to cover in the next few days/weeks/months?

• Examine and understand the jpeg file format
• Create a basic jpeg carver/analyzer capable of jpeg analysis and basic error correction (or at least understandable error messages)
• Look into jpeg exploitations of the past (Example)

Also, since there are different variations of jpeg file formats, I am going to analyze formats more common with digital cameras since that is my primary interest.

Lastly, once we start diving into things I will try my best to provide the pictures I am working with and examples. If you can’t follow what I’m doing then what’s the point right?

I am going to be using this blog to document my explorations into everything digital.  In particular, I hope to post some useful information regarding digital exploitation and forensics. With the combination of the two I hope to run into some interesting examples and hopefully we can both learn something