The File Forensics of a GIF file …

A bit of History

GIF files are still one of the most used formats for graphics files, even though it’s been around for nearly 20 years. In 1987 CompuServe released the GIF (Graphics Interchange Format) format as a free and open specification. In fact, I remember using CompuServe for my Internet access, just before I switched to using AOL (which, as I remember bought over CompuServe, and acquired all their customers). GIF quickly became a standard way to present graphics on the Web, and unfortunately many developers started to write software supporting GIF without even acknowledging the existence of CompuServe. Along with this GIF used a compression technique called LZW (Lempel-Ziv-Welch), which Unisys holds a patent on.

The GIF format became so successful that by at the end of December 1994, CompuServe Inc. and Unisys Corporation announced that developers would have to pay a license fee in order to continue to use technology patented by Unisys. This, though, only applied to certain categories of software supporting the GIF format. These first statements caused immediate reactions and some confusion. With all these legal discussions, it is likely that GIF will be replaced, in the future, by other formats which do not have any patent or licensing problem, especially the PNG format. The great strength of GIF over JPEG is that it supports transparent colours (which will show through the colour of the background), where JPEG does not. PNG also supports this.

After a great deal of anger (including an article in Time), and with statements like:

"The announcement by CompuServe and Unisys that users of the GIF image format must 
 register by January 10 and pay a royalty or face lawsuits for their past usage, 
is the online communications community's equivalent of the sneak attack at Pearl Harbor."

In the end it has been ruled the GIF file format cannot be patented, but the usage of the LZW algorithm is patented (by Unisys). So as long as you do not breach the patent for this, you are not breaching any patents. If you are you must pay a royalty for its usage.

File Format Analysis

So here are a few images (just click on the image to see the forensic analysis):

Click on image for forensic analysis
Click on image for forensic analysis
Click on image for forensic analysis
Click on graphic to analyse

Detailed File Format

The graphics interchange format (GIF) is the copyright of CompuServe Incorporated. Its popularity has increased mainly because of its wide usage on the Internet. CompuServe Incorporated, luckily, has granted a limited, non-exclusive, royalty-free license for the use of GIF (but any software using the GIF format must acknowledge the ownership of the GIF format).

Most graphics software supports the Version 87a or 89a format (the 89a format is an update the 87a format). Both have basic specification:

  • A header with GIF identification.
  • A logical screen descriptor block which defines the size, aspect ratio and color depth of the image place.
  • A global color table.
  • Data blocks with bitmapped images and the possibility of text overlay.
  • Multiple images, with image sequencing or interlacing. This process is defined in a graphic-rendering block.
  • LZW compressed bitmapped images.

Color tables

Color tables store the color information of part of an image (a local color table) or they can be global (a global table).

Blocks, extensions and scope

Blocks can be specified into three groups: control, graphic-rendering and special purpose. Control blocks contain information used to control the process of the data stream or information used in setting hardware parameters. They include:

  • GIF Header – which contains basic information on the GIF file, such as the version number and the GIF file signature.
  • Logical screen descriptor – which contains information about the active screen display, such as screen width and height, and the aspect ratio.
  • Global color table – which contains up to 256 colors from a palette of 16.7M colors (i.e. 256 colors with 24-bit color information).
  • Data subblocks – which contain the compressed image data.
  • Image description – which contains, possibly, a local color table and defines the image width and height, and its top left coordinate.
  • Local color table – an optional block which contains local color information for an image as with the global color table, it has a maximum of 256 colors from a palette of 16.7M.
  • Table-based image data – which contains compressed image data.
  • Graphic control extension – an optional block which has extra graphic-rendering information, such as timing information and transparency.
  • Comment extension – an optional block which contains comments ignored by the decoder.
  • Plain text extension – an optional block which contains textual data.
  • Application extension – which contains application-specific data. This block can be used by a software package to add extra information to the file.
  • Trailer – which defines the end of a block of data.

GIF header

The header is 6 bytes long and identifies the GIF signature and the version number of the chosen GIF specification. Its format is:

  • 3 bytes with the characters ‘G’, ‘I’ and ‘F’.
  • 3 bytes with the version number (such as 87a or 89a). Version numbers are ordered with two digits for the year, followed by a letter (‘a’, ‘b’, and so on).

Logical screen descriptor

The logical screen descriptor appears after the header. Its format is:

  • 2 bytes with the logical screen width (unsigned integer).
  • 2 bytes with the logical screen height (unsigned integer).
  • 1 byte of a packed bit field, with 1 bit for global color table flag, 3 bits for color resolution, 1 bit for sort flag and 3 bits to give an indication of the number of colors in the global color table
  • 1 byte for the background color index.
  • 1 byte for the pixel aspect ratio.

Global color table

After the header and the logical display descriptor comes the global color table. It contains up to 256 colors from a palette of 16.7M colors. Each of the colors is defined as a 24-bit color of red (8 bits), green (8 bits) and blue (8 bits). The format in memory is:

RRRRRRRR
GGGGGGGG
BBBBBBBB
RRRRRRRR
GGGGGGGG
BBBBBBBB
:    :
RRRRRRRR
GGGGGGGG
BBBBBBBB

The 24-bit color scheme allows a total of 16777216 (224) different colors to be displayed. Table B2.12 defines some colors in the RGB (red/green/blue) strength. The format is rrggbbh, where rr is the hexadecimal equivalent for the red component, gg the hexadecimal equivalent for the green component and bb the hexadecimal equivalent for the blue component. For example, in binary:

000000000000000000000000 represents black (000000h)
111111111111111111111111 represents white (FFFFFFh)
011101110111011101110111 represents gray (777777h)
111110101110010100000011 represents yellow (FCE503h)
001110100000101101011001 represents purple (3A0B59h)

Table Hexadecimal colors for 24-bit color representation

Color

Code

Color

Code

White

FFFFFFh

Dark red

C91F16h

Light red

DC640Dh

Orange

F1A60Ah

Yellow

FCE503h

Light green

BED20Fh

Dark green

088343h

Light blue

009DBEh

Dark blue

0D3981h

Purple

3A0B59h

Pink

F3D7E3h

Nearly black

434343h

Dark gray

777777h

Gray

A7A7A7h

Light gray

D4D4D4h

Black

000000h

Image descriptor

After the global color table is the image descriptor. Its format is:

  • 1 byte for the image separator (always 2Ch).
  • 2 bytes for the image left position (unsigned integer).
  • 2 bytes for the image top position (unsigned integer).
  • 2 bytes for the image width (unsigned integer).
  • 2 bytes for the image height (unsigned integer).
  • 1 byte of a packed bit field, with 1 bit for local color table flag, 1 bit for interlace flag, 1 bit for sort flag, 2 bits are reserved and 3 bits for the size of the local color table.

Local color table

The local color table is an optional block which defines the color map for the image that precedes it. The format is identical to the global color map, i.e. 3 bytes for each of the colors.

Table-based image data

The table-based image data follows the local color table. This table contains compressed image data. It consists of a series of subblocks of up to 255 bytes. The data consists of an index to the color table (either global or local) for each pixel in the image. As the global (or local) color table has 256 entries, the data value (in its uncompressed form) will range from 0 to 255 (8 bits). The tables format is:

  • 1 byte for the LZW minimum code size, which is the initial number of bits used in the LZW coding.
  • N bytes for the LZW compressed image data. The first block is preceded by the data size.

GIF coding uses the variable-length-code LZW technique where a variable-length code replaces image data (pixel color references). These variable-length codes are specified in a Huffman code table. The encoder replaces the data from the input and builds a dictionary with the patterns in the data. Every new pattern is entered into the dictionary and the index value of the table is added to coded data. When a previously stored pattern is encountered, its dictionary index value is added to the coded data. The decoder takes the compressed data and builds the dictionary which is identical to the encoder. It then replaces indexed terms from the dictionary.

The VLC algorithm uses an initial code size to specify the initial number of bits used for the compression codes. When the number of patterns detected by the encoder exceeds the number of patterns encodable with the current number of bits then the number of bits per LZW is increased by 1.

Graphic control extension

The graphic control extension is optional and contains information on the rendering of the image that follows. Its format is:

  • 1 byte with the extension identifier (21h).
  • 1 byte with the graphic control label (F9h).
  • 1 byte with the block size following this field and up to but not including, the end terminator. It always has a fixed value of 4.
  • 1 byte with a packed array of which the first 3 bits are reserved, 3 bits define the disposal method, 1 bit defines the user input flag and 1 bit defines the transparent color flag.
  • 2 bytes with the delay time for the encode wait, in hundreds of a seconds, before encoding the image data.
  • 1 byte with the transparent color index.
  • 1 byte for the block terminator (00h).

Comment extension

The comment extension is optional and contains information which is ignored by the encoder. Its format is:

  • 1 byte with the extension identifier (21h).
  • 1 byte with the comment extension label (FEh).
  • N bytes, with comment data.
  • 1 byte for the block terminator (00h).

Plain text extension

The plain text extension is optional and contains text information. Its format is:

  • 1 byte with the extension identifier (21h).
  • 1 byte with the plain text label (01h).
  • 1 byte with the block size. This is the number of bytes after the block size field up to but not including the beginning of the plain text data block. It always contains the value 12.
  • 2 bytes for the text grid left position.
  • 2 bytes for the text grid top position.
  • 2 bytes for the text width.
  • 2 bytes for the text height.
  • 1 byte for the character cell width.
  • 1 byte for the character cell height.
  • 1 byte for the text foreground color.
  • 1 byte for the text background color.
  • N bytes for the plain text data.
  • 1 byte for the block terminator (00h).

Application extension

The application extension is optional and contains information for application programs. Its format is:

  • 1 byte with the extension identifier (21h).
  • 1 byte with the application extension label (FFh).
  • 1 byte for the block size. This is the number of bytes after the block size field up to but not including the beginning of the application data. It always contains the value 11.
  • 8 bytes for the application identifier.
  • 3 bytes for the application authentication code.
  • N bytes, for the application data.
  • 1 byte for the block terminator (00h).

Trailer

The trailer indicates the end of the GIF file. Its format is:

  • 1 byte identifying the trailer (3Bh).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s