Open m0rtalis opened 4 years ago
@m0rtalis the windows shell item list format are undocumented by Microsoft and varies per version of Windows. Could you
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.
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:
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.
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.
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
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?
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?
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
.
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
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
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
: Size2e
: Class Type Indicator -> Volume shell item80
: Unknown Flag3a cc bf b4 2c db 4c 42 b0 29 7f e9 9a 87 c6 41
: GUID not documented1e 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 documented00 00
: Terminal IdentifierAm I missing something or are the GUID and Extension Block missing in the Table in Secion 3.3?