Shell items and shellbags: structure, contents and evidential limits

Why shellbags exist

Open a folder in Explorer, switch it to Details view, sort by date, resize the window. Close it. Opened again a month later, it returns exactly as it was left. That memory is the feature, and Shellbags are where it lives.

It is a convenience feature with no security purpose whatsoever, which is precisely what makes it evidence. Windows is not recording navigation for any benefit but the user's own, so it does not stop, it does not ask, and it keeps the record for folders that no longer exist: a USB stick removed years ago, a network share that was mapped once, a folder deleted the same afternoon it was made.

What a shell item is

A path is how a person names a file. It is not how Windows' shell names anything. The shell keeps a namespace that is larger than the filesystem - This PC, Control Panel, a phone attached over MTP, a vendor's own tree grafted in beside them - and most of what is in it has no path to have. So the shell names things with an ID list — a PIDL, short for pointer to an identifier list — and a shell item is one entry in one.

An item begins with two bytes of size and one byte of type, and after that it is whatever the owner of that corner of the namespace decided to put there. There is no schema. That is why this one machine holds a dozen different type bytes, why their sizes run from 14 bytes to over 9,000, and why every parser that reads them needs a fallback rather than a table - the next Windows feature to add a namespace extension adds a shell item layout with it, and does not publish one.

A list is a chain, read outside in: the desktop, then This PC, then a volume, then each folder, then the thing. Each link is an item of some type, and the type changes along the way - a GUID at the root, a drive string at the volume, a name for each folder after it. A Shellbag value is a chain of exactly one link, because the key it sits under supplies the rest; the ComDlg32 keys further down this page store the whole chain in one value.

The artifacts built from shell items

Shell items are not one artifact. They are the unit a dozen different records are built from, and each record keeps them for its own reason: Explorer remembering how a folder looked, a file dialog remembering where it last pointed, a shortcut remembering what it opens. This section names every one of those records and what each proves, before the rest of the page takes the item itself apart.

What an MRU is

MRU stands for most recently used. An MRU key is a short list kept in the registry: a set of numbered values, each holding one remembered entry, plus one extra value that records the order in which they were last used. A new entry takes the next free number. Using an old entry again does not move or rewrite it - only the order value changes. Three ways of recording that order occur:

• MRUList - a string of letters, each naming a value (a, b, c ...), newest first. Used by RunMRU and by the dialog keys of Windows XP.
• MRUListEx - an array of 4-byte little-endian value numbers, newest first, ending in 0xFFFFFFFF. Used by Shellbags, RecentDocs, the ComDlg32 PIDL keys and WordWheelQuery.
• Numbered names with no order value at all - in TypedPaths, url1 is always the newest.

Whatever the scheme, the key carries one timestamp: its last-write time, which belongs to the change that put the newest entry on top. Every other entry in the list has a position, not a date. The order value is decoded byte by byte in MRUListEx: the access order, and every MRU key is compared side by side in the MRU family.

Every record that holds shell items

Paths below sit under NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer unless another hive is named. Three of the keys are listed although they hold no shell item, because they live beside the ones that do and are read together with them.

Every shell item type, and what it names

The third byte of every item is its class type. The high bits choose a family and the low bits are flags within it: 0x31 is the file-entry family (0x30) with the directory flag (0x01) set, and 0x32 is the same family with the file flag (0x02). The rows below cover every type documented in the libyal Windows Shell Item format specification, the standard public reference for structures Microsoft never published. Table 2 further down counts which of them the reference system actually carries.

Anything outside these families is undocumented. On the reference system that means 0x79 and 0x7E, which Crow-Eye keeps through the fallback described under one shell item, byte by byte rather than discarding.

One shell item, byte by byte

Six real items, read out of the reference system's BagMRU and redrawn here. The tabs are item types, not versions of one thing: a root, a volume, a folder, a file, an item the parser does not recognise, and the extension block that carries the timestamps, on its own. The same structure appears inside .lnk files and Jump Lists, which is why decoding it is not registry work at all.

This tree holds 859 values across 12 item type bytes. 833 of them fall inside a range parse_shell_item_id() has a branch for; the other 26 reach the fallback, which keeps a plausible name and records the type as unknown. Every one of the 859 is a one-item list - a shell item followed by a two-byte end-of-list marker - which is why the last field of every map here is that marker.

Structure is real and measured. Names are replaced with a placeholder of the same byte length, so every offset still adds up and nothing here identifies the machine it came from.

Full dissection reference

The same fields as a table. Both are drawn from one definition, so the map and the table cannot disagree with each other.

Twelve type bytes, and what actually separates them

Everything above is one item of one type. A type byte is not a label on the same structure - it decides what the rest of the item is, and the families have almost nothing in common past the size and the type itself. One carries a GUID and no name. One carries a drive string and no times. One carries another item inside it. The table is measured off this tree rather than listed from documentation, so the counts are what is there.

5 of the 12 types above have a byte map in the tabs earlier on this page. The other 7 - 0x00, 0x01, 0x37, 0x3E, 0x71, 0x79, 0x7E - do not, because there is nothing decoded to draw: 4 of them are a single value, 1 carries nothing that reads as a name, and none of them has a published field map. A map of undocumented bytes would be a picture of a guess.

Types Windows writes that this machine does not hold

The table above is a census of one tree, and a census is not a specification. These exist and would appear in another capture.

The structure is not a registry structure

A Shellbag value is a shell item ID list - the same structure Windows writes inside a .lnk shortcut, and the same one it passes around internally to mean "this thing in the shell namespace". The registry is storing it, not describing it. To the hive it is a REG_BINARY blob and nothing more, which is why decoding it lives in Crow-Eye's shared binary parser beside the LNK code rather than in the registry parser.

That sharing is the point: an examiner who understands one has understood the other. A shell item in a Jump List, a shell item in a shortcut and a shell item in a Shellbag are the same bytes with the same meanings. Explained in full: Jump Lists

The BEEF0004 block, and what it carries

The fixed part of a file entry carries an 8.3 short name and a DOS timestamp with two-second resolution. Neither is much use. The extension block that follows carries the real name in UTF-16, the created and accessed times, and on many systems the folder's MFT reference.

Its signature is 0xBEEF0004, and where it lands inside an item is not fixed - it sits after the short name, whose length varies, which is why it is found by searching for the signature rather than by counting. The map above shows where it falls in each of the items it draws. It carries a version word that decides where the long name starts. That offset is not fixed: it moved between Windows XP, Vista, 7 and 8. A parser that hardcodes one of them reads a name that begins a few bytes into itself on every other version, and returns something that still looks like a name.

MRUListEx: the access order

Each BagMRU key holds numbered values - the shell items - and one called MRUListEx: a list of four-byte indices, most recent first, terminated by 0xFFFFFFFF. On the reference system the sample key's order runs 8, 0, 9, 7, 6, 3, 5, 4, 1, 2.

The numbers on the values are allocation order. The MRU list is visit order. They are not the same, and reporting the values in numeric order silently reorders the user's history into the order Windows happened to allocate slots. Entry 8 here was touched most recently despite whatever its slot number suggests.

The MRU family: same idea, different payloads

A shellbag is one MRU key among several, and the shell item taken apart above turns up inside four of the others. They are usually listed together as if they were one artifact with several names. They are not. What separates them is not how they order themselves - two of them do not order the same way at all - but what a single value contains, and that is what decides which sentence a row can support.

Three of the columns below need a word first. Ordering says how the key records which entry was used last: MRUListEx is the modern form, a list of 4-byte little-endian value numbers in most-recent-first order terminated by 0xFFFFFFFF; MRUList is the older form that does the same job with single letters; and none means the key keeps no order at all, so its values can only be read as a set. What one value holds is the payload - a shell item, a plain string, or a structure of its own - and it is what decides what a row supports, the sentence a single entry can honestly be used to write.

RecentDocs exists on the reference system and holds nothing. An empty key is a finding - it is what a cleared history looks like, and it is not the same as a key that was never there.

Three ways to say "most recent"

MRUListEx is an array of four-byte indices, most recent first, closed by 0xFFFFFFFF. On the reference system LastVisitedPidlMRU opens 1, 4, 20, 19, 5, 18…, so the value named 1 was the last one used.

RunMRU is older and uses MRUList: a string of letters rather than numbers, and its values are named a, b, c to match. Here it reads ba, which is 2 entries in use order.

TypedPaths has no ordering value at all. Its values are named url1 to url17 and the number is the order - url1 is the most recent, and Windows renumbers the rest down when a new path arrives. A parser that goes looking for an MRUListEx here finds none and reports the key as unordered, which is the one case where numeric order is the right answer.

What the one timestamp is worth

An MRU key has a single last-write time and no per-entry time anywhere. It dates the newest entry, and it dates nothing else: the other nineteen values under the same key were written earlier, by an unknown amount. Crow-Eye stores it as key_last_write and leaves access_date empty rather than assigning the key's time to whichever entry the ordering value happens to name first - which would be an invention and would look exactly like evidence.

What one value looks like in each key

The same values as a table. Names are replaced with a placeholder of the same byte length, so every size field still points where it pointed.

Every shell-item and MRU table, one by one

Each table below is one tab in Crow-Eye, and each has an Anatomy button that opens its own section here. Its Charts button opens the User Activity dashboard, where it shares one timeline with every other shell-item and registry user-activity source. Shellbags have the rest of this page: start there.

RecentDocs

Explorer's list of the files and folders this user recently opened, kept once overall and once per file extension. The value data starts with the item's name and is followed by the shell item of the shortcut Explorer wrote into the Recent folder.

OpenSaveMRU (OpenSavePidlMRU)

Files chosen in the common Open and Save dialogs, by any program that uses them. Vista and later store a shell item ID list per entry; XP stored plain strings under OpenSaveMRU.

LastSaveMRU (LastVisitedPidlMRU)

For each program that used a common dialog: the program's executable name and the folder the dialog was last in. Crow-Eye's table is called LastSaveMRU.

TypedPaths

Paths typed or pasted into the Explorer address bar.

RunMRU

Commands typed into the Run box (Win+R).

WordWheelQuery (Explorer search)

Terms typed into the Explorer search box (Windows 7 and later).

CIDSizeMRU

Programs that opened a common Open/Save dialog, with the dialog's window size. No path at all.

Taskband (taskbar pins)

The items pinned to the taskbar, stored by Explorer as a list of shell items.

MountPoints2 and the mapped network drive MRU

One subkey for every volume and network share this user's Explorer mounted - removable drives included - and the list of shares typed into Map Network Drive.

Explained in full: what was plugged in

User shell folders

Where each known folder - Desktop, Documents, Downloads - actually points for this user.

Shell extensions: open commands, icon overlays, delayed-load objects

Three registrations that make Explorer run code, read from three tables.

Explained in full: what will run again

A bag is a view, and a view is not a person

A shellbag is written when a shell view of a container is created, or when its settings change. Explorer hosts shell views. So does every common File Open and Save dialog, inside whatever program opened it, and so do Windows' own broker processes - two of the programs this capture records as having used a dialog are PickerHost.exe and OpenWith.exe, which nobody launches. None of that requires a person to navigate anywhere, and in BagMRU none of it looks any different.

Windows records the difference itself, one level over. A BagMRU key carries a NodeSlot number naming a subkey of the Bags tree beside it, and that subkey holds the view settings - filed under Shell when an Explorer window made the view, and under ComDlg when a common dialog did. On the reference system 799 of 859 items resolve to a bag that way. The other 60 are keys that have never been given a view of their own, and Crow-Eye leaves the columns empty on those rather than guessing.

227 of the 801 bags on this machine carry a dialog's view - more than a quarter of them. A report that reads every row as somebody browsing is wrong about a quarter of its rows, and there is nothing in the row itself to say which quarter.

Nor is everything with a bag a directory. Sorted by the view class Windows recorded against it, this tree holds 17 CompressedFolder views - a zip file opened as though it were a folder - 49 storage-provider views, which are a cloud provider's namespace rather than a path on disk, 15 search-result views and 3 control panel pages. A control panel page is not a folder anybody walked to.

What a row does support, then: a container with that name was rendered as a shell view under that account, by some process running as that account, at some point. Whether a person chose it is a separate question, and it needs a separate artifact.

Crow-Eye stores the answer it can: node_slot is the number on the key, and bag_views is which subkeys the bag actually has. For the program's name, ComDlg32\LastVisitedPidlMRU records which executable last used a dialog in which folder, and Crow-Eye parses it into LastSaveMRU with an application column. On the reference capture that column names twenty programs, two of which - PickerHost.exe and OpenWith.exe - are Windows' own brokers, launched by no one. UserAssist, RecentDocs, Jump Lists and Prefetch say what was running at the time; the key's own last-write time says when. Those are what answer who, and a Shellbag on its own does not.

What a shell item supports, and what it does not

What it does prove, and what nothing else proves as well: a container with that name existed on this machine at some point, and a shell view of it was created under that user account - by some process running as that account, which is not necessarily a person and not necessarily Explorer. For removable media and network shares that are long gone, the Shellbag may be the only record they were ever attached. Which process, and how to tell

How Crow-Eye reads shell items

Both hives, both trees: UsrClass.dat and NTUSER.DAT, per user profile. The decoding is registry_binary_parser, shared with the LNK and Jump List parsers because a shell item is a shell item wherever it is stored.

Every Shellbag key Crow-Eye reads

Four BagMRU trees, each read together with its sibling Bags key, which holds the view settings for the slots the tree points at. On a live system the UsrClass.dat trees are reached through the merged Software\Classes view; on an image, UsrClass.dat is opened directly and the same keys sit under Local Settings\... with no Classes prefix. An absent tree reads as empty, not as an error, because most systems carry only one or two of the four.

The same four keys appear in the registry anatomy's full key list. Every key Crow-Eye reads for user activity

Deleted Shellbags are carved out of the hive's freed cells and written with the key path reconstructed where the parent chain survives - and left blank where it does not, because a guessed path on a recovered artifact is worse than no path. The registry internals guide covers how that carving works and why most recovered keys cannot be placed at all: of the 533 keys carved from free space on the reference system, 384 - 72.0 per cent - resolve to no parent, and each is recorded with an empty path rather than a guessed one.

How Shellbags changed across Windows

Each row below records a change that alters what a reader may conclude, not only how the bytes are arranged. A parser written against one Windows release returns nothing against another, and does so without raising an error.

Reference

BEEF0004 versions

Anti-forensic handling, and what survives it

The preceding sections describe what intact shell items support. This section describes them after an attempt to remove or evade it, which is the condition in which it is frequently encountered. In most rows the attempt leaves a trace of its own.