Thumbs.db forensics: Catalog, Type 1 images and shares
How Thumbs.db stores thumbnails, original file names and modified times, why old Type 1 images look corrupt, and where modern Windows still creates Thumbs.db.
Thumbs.db is the per-folder thumbnail cache of older Windows versions. It
still turns up in modern cases: on external drives last used with XP-era
machines, in archives and backups, and on file servers, where current Windows
still creates it. Unlike the modern thumbcache,
it often records the original file name and its last-modified time, which
makes it very valuable.
Container: an OLE compound file
Thumbs.db is a Microsoft Compound File (the same container as legacy .doc
files), signature D0 CF 11 E0 A1 B1 1A E1. Inside are storage streams:
Catalog: the index (Windows 98 → XP);- one stream per thumbnail, named after its catalog index with the digits
reversed (index 12 is stream
21); - on Vista+ network-share variants, streams named like
256_<cache id>, and no Catalog.
The Catalog stream
| Offset | Size | Field |
|---|---|---|
| 0 | 2 | Header length (usually 16) |
| 2 | 2 | Version |
| 4 | 4 | Number of entries |
| 8 | 4 | Thumbnail width |
| 12 | 4 | Thumbnail height |
Each entry then holds:
| Offset | Size | Field |
|---|---|---|
| 0 | 4 | Entry length |
| 4 | 4 | Index (→ stream name, digits reversed) |
| 8 | 8 | FILETIME: last-modified time of the source file |
| 16 | … | File name, UTF-16LE, NUL-terminated |
The FILETIME is the source file's modification time when the thumbnail was generated. It is not the time the folder was viewed. It lets you tie a thumbnail to a specific version of a file, and it survives when the file itself is gone.
Thumbnail streams: Type 2 and Type 1
Most XP thumbnails ("Type 2") are a 12-byte header (header length 0x0C, a
constant, the data size) followed by an ordinary JFIF JPEG. Any viewer can open them.
Type 1 thumbnails, from Windows 98, ME, 2000 and some early XP systems, are
different. After the first header comes a second one (marker 1, a size, the
width and height), and then a JPEG fragment:
- it has SOI, SOF and SOS markers but no DQT or DHT: the quantization and Huffman tables are missing, because Windows always used the standard ones from the JPEG specification (Annex K);
- its four components are labelled RGBA but contain Y, M, C and an alpha channel;
- the picture is stored upside down.
To view one, splice the standard tables back in, decode, convert R = 255 − C, G = 255 − M, B = 255 − Y, and flip vertically. The Thumbcache Parser does this automatically and marks the result Rebuilt. The hashes it reports are those of the original stream, so the evidence itself is never altered.
Where to look
- User data folders, especially picture folders, on XP-era images.
- Removable media: a folder copied with Explorer takes its hidden
Thumbs.dbalong, including thumbnails of files deleted before the copy. - Network shares: Vista+ clients still write
Thumbs.dbthere by default. Browsing a share with thumbnails can leave evidence on the server, not the client. - Anywhere on a volume. Unlike thumbcache it is not tied to a profile, so search the whole file system (e.g. with Disk Image Parser's Thumbnail cache preset).
Also look for ehthumbs.db and ehthumbs_vista.db, the same format written by
Windows Media Center.
Reporting notes
Report the full path of the Thumbs.db (it tells you which folder was browsed),
the Catalog name and FILETIME for each thumbnail, the stream name and the hash of
the stream bytes. For Type 1 images, state that the displayed image was
reconstructed with standard JPEG tables.