New variant of a volume shell item?

[m0rtalis]

I try to manually verify a windows shell item of type volume shell item.
I will use the second example in the Windows Shell Item format specification document for the explanation as the structure is identical to the one I need to parse.
Hex:
32 00 2e 80 3a cc bf b4 2c db 4c 42 b0 29 7f e9 9a 87 c6 41 1e 00 00 00 25 00 ef be 11 00 00 00 fa 66 a2 86 36 74 cf 01 2d 81 fe bc ba 9b cf 01 14 00 00 00
As described in the document I could identify the following bytes (GUID and Extension Block are assumptions from me):
32 00: Size
2e : Class Type Indicator -> Volume shell item
80: Unknown Flag
3a cc bf b4 2c db 4c 42 b0 29 7f e9 9a 87 c6 41: GUID not documented
1e 00 00 00 25 00 ef be 11 00 00 00 fa 66 a2 86 36 74 cf 01 2d 81 fe bc ba 9b cf 01 14 00: Extension Block not documented
00 00: Terminal Identifier

Am I missing something or are the GUID and Extension Block missing in the Table in Secion 3.3?

[joachimmetz]

@m0rtalis the windows shell item list format are undocumented by Microsoft and varies per version of Windows. Could you

1. provide more context where the shell item list originated from
2. provide me with the raw data / hexdump instead of an annotated one (preferably of the full shell item list)

[m0rtalis]

The shell item in my example is the one you have in "libsfwsi/documentation/Windows Shell Item format.asciidoc" in Section 3.3 as one of the three examples.

I looked into my registry and found a similar key from the following location:
Path: HKCR\Local Settings\Software\Microsoft\Windows\Shell\BagMRU\0
Keyname: 3
Value: 3A-00-2E-80-05-39-8E-08-23-03-02-4B-98-26-5D-99-42-8E-11-5F-26-00-01-00-26-00-EF-BE-11-00-00-00-E3-88-C7-C4-67-80-D6-01-CC-2B-60-7C-71-80-D6-01-C8-90-AB-6C-74-80-D6-01-14-00-00-00
The dump of the value is here: BagMRU_MyComputer_Downloads.txt
I'm using Windows 10 Pro

Parsing it with ShellBags Explorer from Zimmerman shows it as:
Value: Downloads
Absolute Path: Desktop\My Computer\Downloads
Shell Type: "Root folder: GUID"
Type Indicator: 0x2E
Extension Blocks: Beef0026
Extension Block Count: 1

which is a bit confusing as the Type Indicator 0x2E points to a Volume shell item as it's in the range 0x20 - 0x2f but it's being recognized as "Root folder: GUID", which I think corresponds to Root folder shell item which has the type indicator 0x1f and the structure would fit better, except for the Extension Block Signature.

Also my other example which I unfortunately can't share and the examples in your documentation have an extension block signature of Beef0025 instead of Beef0026 as this one has.

[joachimmetz]

which is a bit confusing as the Type Indicator 0x2E points to a Volume shell item as it's in the range 0x20 - 0x2f but it's being recognized as "Root folder: GUID"

Per documentation: https://github.com/libyal/libfwsi/blob/master/documentation/Windows%20Shell%20Item%20format.asciidoc#21-shell-item

The class type indicator has proven not to be a foolproof indicator for all shell items, but it appears to be a strong one for others hence (for now) we divide the shell items into two categories:

Again this documentation is not an official definition of the format, but observations regarding the format by various people.

This is Microsoft's official documentation:

• https://docs.microsoft.com/en-us/windows/win32/api/shtypes/ns-shtypes-itemidlist
• https://docs.microsoft.com/en-us/windows/win32/api/shtypes/ns-shtypes-shitemid

Many parts of the shell items are not yet understood or sufficiently researched. Shell items are likely serialized internal states of CLSID_ShellItem variants. These differ between Windows versions, even when different application are installed.

Absolute Path: Desktop\My Computer\Downloads
Shell Type: "Root folder: GUID"

There are sources that link 088e3905-0323-4b02-9826-5d99428e115f to the namespace of the 32-bit Downloads folder, but I've not looked into this. Seeing the location in the BagMRU of this shell item this could be a plausible hypothesis.

Also my other example which I unfortunately can't share and the examples in your documentation have an extension block signature of Beef0025 instead of Beef0026 as this one has.

Unfortunately if no reproduce-able test data can be made, it will remain some level of speculation what the values mean.

[joachimmetz]

Actually for Windows 10 Absolute Path: Desktop\My Computer\Downloads is incorrect and presumably needs to be Desktop\This PC\Downloads (Since This PC is an "auto list" which looks like it is different from the "My Computer" view of earlier versions of Windows). And possibly that Type Indicator: 0x2E has a different meaning with an "auto list" parent.

Doing some experimentation, the display name of 20d04fe0-3aea-1069-a2d8-08002b30309d is This PC on an US English Windows 10 installation. So the path reconstruction is definitely incorrect for Windows 10. In on of my test files the shell item of This PC is an auto list (which seems to contain the name), but looking at a runtime item list for This PC is of root folder type.

[joachimmetz]

00000000  3a 00 2e 80 05 39 8e 08  23 03 02 4b 98 26 5d 99  |:....9..#..K.&].|
00000010  42 8e 11 5f 26 00 01 00  26 00 ef be 11 00 00 00  |B.._&...&.......|
00000020  e3 88 c7 c4 67 80 d6 01  cc 2b 60 7c 71 80 d6 01  |....g....+`|q...|
00000030  c8 90 ab 6c 74 80 d6 01  14 00 00 00              |...lt.......|

Has a lot of similarities with some the shell items in Desktop from another Windows 10 2004 installation

00000000: 3a 00 1f 44 47 1a 03 59  72 3f a7 44 89 c5 55 95   :..DG..Y r?.D..U.
00000010: fe 6b 30 ee 26 00 01 00  26 00 ef be 10 00 00 00   .k0.&... &.......
00000020: ce e7 50 61 f6 fa d1 01  b0 18 85 ef fd fa d1 01   ..Pa.... ........
00000030: b0 18 85 ef fd fa d1 01  14 00 00 00               ........ ....

Which seems to be user account related

[m0rtalis]

Again this documentation is not an official definition of the format, but observations regarding the format by various people.

I know, it just seems that this is the best documentation about the Shell Item Lists on the web so that's why I raised the issue here.

Actually for Windows 10 Absolute Path: Desktop\My Computer\Downloads is incorrect and presumably needs to be Desktop\This PC\Downloads

Oh yes that makes sense. Probably just an issue in ShellBags Explorer that it uses an old name.

So is there anything else I can do to help with this new variant?

[joachimmetz]

So is there anything else I can do to help with this new variant?

Not much, I'll try to get back to this format when I can. Think I finally found one of the leads I was looking for a while.

Anything you can tell about the shell item (list) you cannot share? type? extension blocks? what data is roughly in it? in what context it was found?

[m0rtalis]

Yes I replaces the metadata in the extension block with FF. The rest I can share:

00000000  3a 00 2e 80 05 39 8e 08  23 03 02 4b 98 26 5d 99  |:....9..#..K.&].|
00000010  42 8e 11 5f 26 00 01 00  25 00 ef be ff ff ff ff  |B.._&...%.......|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000030  ff ff ff ff ff ff ff ff  ff ff 00 00              |............|
0000003c

Found on Win10 Home in HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU\BagMRU\3\12.

[joachimmetz]

thx and the sanitized metadata is that a string? or similar to: https://github.com/libyal/libfwsi/blob/master/documentation/Windows%20Shell%20Item%20format.asciidoc#622-extension-block-0xbeef0025

[m0rtalis]

Ah totally didn't see that the extension block is described. Was worried that there are some things in it I don't want to disclose. But in that case it's fine to share it. Here is the full data:

00000000  3a 00 2e 80 05 39 8e 08  23 03 02 4b 98 26 5d 99  |:....9..#..K.&].|
00000010  42 8e 11 5f 26 00 01 00  25 00 ef be 11 00 00 00  |B.._&...%.......|
00000020  c8 46 90 ad 86 c1 d0 01  4b a7 6c 6e 82 d8 d0 01  |.F......K.ln....|
00000030  4b a7 6c 6e 82 d8 d0 01  14 00 00 00              |K.ln........|
0000003c