Shell Item Format Explained: Inside a ShellBag Entry

TL;DR. Every numbered value under a BagMRU key is an ITEMIDLIST holding one shell item: a 2-byte size, a class type byte at offset 2, then a type-specific body. 0x1F is a root folder (a GUID such as My Computer), 0x2X a volume, 0x3X a file entry (folder or file, with the 8.3 name and a modification time), 0x4X a network location, 0x71 a Control Panel item, 0x74 a delegate. Most file entry items end with a 0xBEEF0004 extension block that adds created and accessed times, the NTFS MFT entry and sequence number, and the long name. The format is undocumented by Microsoft; libyal's libfwsi is the reference.

You do not need to decode shell items by hand to use ShellBags. You do need to know what the bytes can and cannot hold, because that decides what you can claim. This article walks through one real-layout item from the site's sample and the handful of structures that carry evidence.

ITEMIDLIST in one paragraph

The Windows shell addresses objects (folders, drives, Control Panel applets, devices) with ID lists. Microsoft documents the container: an ITEMIDLIST is a sequence of SHITEMID structures, each starting with a 2-byte cb size, ending with a zero-length terminator. The contents of each item are private to the shell folder that created it. The community specification that fills that gap is libyal's Windows Shell Item format (libfwsi). The same items appear in LNK files (the LinkTargetIDList of MS-SHLLINK) and in Jump Lists, so this knowledge transfers.

In a BagMRU value, the ID list contains a single item: the path component for that key. The full path comes from walking the key tree, not from one value.

Class types

The byte at offset 2 identifies the item. libfwsi groups them by the high nibble (class_type & 0x70) for volumes, file entries and network items:

A file entry item, byte by byte

Here is the finance_2026 folder from the ShellBags Parser sample. The data is synthetic (fictional story) but built with the real layout:

0000  66 00 31 00 00 00 00 00 2e 5d a0 55 10 00 46 49   f.1......].U..FI
0010  4e 41 4e 43 45 5f 32 30 32 36 00 00 4a 00 09 00   NANCE_2026..J...
0020  04 00 ef be 2e 5d a0 55 2e 5d a0 55 2e 00 00 00   .....].U.].U....
0030  24 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00   $...............
0040  00 00 00 00 00 00 00 00 00 00 66 00 69 00 6e 00   ..........f.i.n.
0050  61 00 6e 00 63 00 65 00 5f 00 32 00 30 00 32 00   a.n.c.e._.2.0.2.
0060  36 00 00 00 1c 00                                 6.....

Decoding the FAT values: the date word 0x5D2E holds year-since-1980 in bits 9–15 (46 → 2026), month in bits 5–8 (9), day in bits 0–4 (14). The time word 0x55A0 holds hour in bits 11–15 (10), minute in bits 5–10 (45), and seconds/2 in bits 0–4. Microsoft documents the same layout for DosDateTimeToFileTime. See FAT timestamp for the precision implications.

The 0xBEEF0004 extension block

Extension blocks follow the item body. Each starts with a 2-byte size, a 2-byte version and a 4-byte signature. The file entry extension, signature 0xBEEF0004, is the one that matters for ShellBags. Per libfwsi:

The version is itself evidence: an entry with a version 3 block was created on XP-era code, which can matter when a profile was migrated. The fields that move between versions sit before the long name, which is why a parser has to know the version to find the name. The ShellBags Parser shows the version in the entry details.

The MFT file reference

From version 7 onwards, offset 20 of the block (0x30 in the example) holds an 8-byte NTFS file reference: a 48-bit MFT entry number and a 16-bit sequence number, the layout Microsoft documents as MFT_SEGMENT_REFERENCE. This is the most underused field in ShellBags:

• Filter the $MFT or USN journal for entry 36: if the sequence number there is higher, the folder was deleted and the record reused.
• Folders on FAT/exFAT volumes have no MFT, so the field is zero or meaningless there.
• Items that do not come from NTFS directories (archive content, network items) do not carry a usable reference.

More in the glossary entry on MFT file references and the article on deleted folders.

Other items worth recognising

Root folder (0x1F). Byte 3 is a sort index (libfwsi lists 0x50 for My Computer, 0x58 for Network, 0x60 for Recycle Bin), followed by a 16-byte GUID. The sample's My Computer item is 20 bytes: 14 00 1f 50 then {20D04FE0-3AEA-1069-A2D8-08002B30309D} in mixed-endian form. Microsoft lists shell GUIDs in KNOWNFOLDERID; CLSIDs such as My Computer's come from older shell documentation and community tables.

Volume (0x2F). A drive letter string at offset 3: 19 00 2f 45 3a 5c 00 is E:\. The letter is what Windows assigned at the time, not a device identity.

Network (0x4X). Flags at offset 3, then a NUL-terminated location at offset 5. The sample's share item 1a 00 c3 00 00 5c 5c 46 49 4c 45 53 52 56 30 31 5c 46 69 6e 61 6e 63 65 00 reads \\FILESRV01\Finance. libfwsi documents flags 0x80 (description present) and 0x40 (comments present).

Delegate (0x74). On Windows 7 and later, folders under the user profile are often stored as a delegate item with the signature CFSF wrapping a normal file entry. A parser that ignores it loses the names of many profile folders.

What parsers do with the unknown

Shell extensions can define their own items, and Microsoft adds new ones with each release (phones over MTP, cloud providers, search results). A careful parser decodes what it knows and keeps the rest as hex. The ShellBags Parser shows the raw item in the details panel for every entry and falls back to the longest readable UTF-16 string for variable items. Its README lists MTP devices, ZIP-content (0x52) items and search results as not yet fully decoded; ShellBags Explorer covers more types, which is one reason to cross-check odd entries with it (see the tool comparison).

Further reading

• libfwsi: Windows Shell Item format
• Kaitai Struct: Windows shell items
• Microsoft: ITEMIDLIST, SHITEMID

Related articles

• ShellBags timestamps explained
• ShellBags on Windows XP, 7, 10 and 11
• ShellBags forensics: the complete guide