Loading ...
Sorry, an error occurred while loading the content.

Shellbag research

Expand Messages
  • Sebastien Bourdon-Richard
    Hi everyone, I don t have a blog, so I will publish my finding here. Big thanks to everyone who is doing research in this area! Here s my small contribution to
    Message 1 of 2 , Oct 31, 2012
    View Source
    • 1 Attachment
    • 192 KB

    Hi everyone,


    I don't have a blog, so I will publish my finding here. Big thanks to everyone who is doing research in this area! Here's my small contribution to shellbag research.

     

    These are not extensive research and they were done on my spare time.

     

     

    Introduction

     

    I will not introduce shellbags because they have been described in a lot of places. Good introduction can be found here [1].

     

    What we found in registry are refered as IProperty by MSDN [2]. Each property is described with a name, whose value is stored in a VARIANT [3]

     

    Actually, those VARIANT seems to contains (or  are) ITEMIDLIST. 

     

    "An ITEMIDLIST is nothing more than a list of ITEMID/SHITEMID (IID) which are contiguous. It is terminated by an empty IID which is defined as a 0-size IID. The size for each IID accounts for the size member itself as well. The ITEMIDLIST has to be NULL-IID terminated" [4]

     

    ITEMIDLIST are not only found in Shellbags. These structures are also found in:

    • ViewView2
    • Lnk files
    • Clipboard

     

     

    ItemPos Structure

     

    What we found in ItemPos and BagMRU are ITEMIDLIST structure. 

     

    typedef struct _ITEMIDLIST {
      SHITEMID mkid;
    } ITEMIDLIST;

     

    ITEMIDLIST are a list of SHITEMID

     

    typedef struct _SHITEMID {
      USHORT cb;
      BYTE   abID[1];
    } SHITEMID;

     


    I will take Jamie Levy blog post as an example (http://volatility-labs.blogspot.ca/2012/09/movp-32-shellbags-in-memory-setregtime.html)

     

     

    Let's take the key ItemPos1171x730(1) as an example.

     

    Inline image 1


     

    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

     

    First offset filed with 00, not sure what it is.

     

    17 00 00 00 02 00 00 00

     

    More reseach need to be done on those.

     

    17 00 00 00: Repeated in the ItemPos key. Maybe it's related to PIDL, but I'm not sure

    02 00 00 00: Icon position, in this case on the desktop

     

     

    14 00 1f 48 ba 8f 0d 45 25 ad d0 11 98 a8 08 00 36 1b 11 03

     

    This is not an invalid entry.  It's a SHITEMID structure

     

    14 00 is the size of this structure.

    1F 48 - ?

    ba 8f 0d 45 25 ad d0 11 98 a8 08 00 36 1b 11 03 is a CLSID

     

    {450d8fba-ad25-11d0-98a8-0800361b1103} = My Document

    (Description of CLSID can be found here: http://www.autohotkey.com/docs/misc/CLSID-List.htm or in HKCR\CLSID)

     

     

    17 00 00 00 4f 00 00 00 14 00 1f 50 e0 4f d0 20 ea 3a 69 10 a2 d8 08 00 2b 30 30 9d

     

    Icon position: 0x4F

    SHITEMID structure

    • CLSID: {20d04fe0-3aea-1069-a2d8-08002b30309d} = My Computer

     

     

    17 00 00 00 9c 00 00 00

    14 00 1f 58 60 2c 8d 20 ea 3a 69 10 a2 d7 08 00 2b 30 30 9d bf

    03 00 00 6a 02 00 00

    14 00 1f 60 40 f0 5f 64 81 50 1b 10 9f 08 00 aa 00 2f 95 4e

     

    Icon position: 0x9C

    SHITEMID structure

    • {208d2c60-3aea-1069-a2d7-08002b30309d} = My Network Place

    Icon position: 0x6A02

    SHITEMID structure

    • {645ff040-5081-101b-9f08-00aa002f954e} = Recycled bin

     

     

    17 00 00 00 e9 00 00 00

     

    Icon position: 0xE9

     

     

    4e 00 32 00 c0 f8 f7 00 …

     

    This is another SHITEMID structure (FILE_ENTRY structure as described by Jamie).

     

    The only thing I would like to add about Jamie's description is about the SHELL_ITEM_TYPES (i.e: 0x32). I found that this structure is actually a TRANSFER_SOURCE_FLAGS structure.

     

    typedef enum _TRANSFER_SOURCE_FLAGS {
      TSF_NORMAL                      = 0,
      TSF_FAIL_EXIST                  = 0,
      TSF_RENAME_EXIST                = 0x1,
      TSF_OVERWRITE_EXIST             = 0x2,
      TSF_ALLOW_DECRYPTION            = 0x4,
      TSF_NO_SECURITY                 = 0x8,
      TSF_COPY_CREATION_TIME          = 0x10,
      TSF_COPY_WRITE_TIME             = 0x20,
      TSF_USE_FULL_ACCESS             = 0x40,
      TSF_DELETE_RECYCLE_IF_POSSIBLE  = 0x80,
      TSF_COPY_HARD_LINK              = 0x100,
      TSF_COPY_LOCALIZED_NAME         = 0x200,
      TSF_MOVE_AS_COPY_DELETE         = 0x400,
      TSF_SUSPEND_SHELLEVENTS         = 0x800
    } TRANSFER_SOURCE_FLAGS;

     

     

    0x32 means

    • TSF_OVERWRITE_EXIST 
    • TSF_COPY_CREATION_TIME
    • TSF_COPY_WRITE_TIME  

     

    0x31 is the value for a folder. This is because when you copy paste a folder, and if the destination already exists, the folder will be renamed automatically ( TSF_RENAME_EXIST). For a file, Windows will ask if you want to overwrite the existing file.

     

    I also noticed a behavior under Windows 7 (not sure if it's apply to all windows version). If the FILE_ENTRY structure is located on the public desktop (i.e: c:\users\public\desktop), there's no security associated to this file and TSF_NO_SECURITY flag will be set. So files on the default desktop will have an id of 0x3A and a folder will have the id 0x39.

     

     

    17 00 00 00 36 01 00 00

    Icon position:  0x3601

     

    5c 00 3a 00 cc 06 00 00 5a ..

     

    This is another SHITEMID structure (FILE_ENTRY structure).

     

    17 00 00 00 36 01 00 00 00 00 00 00

    The ITEMIDLIST is NULL-IID terminated as describe by CyanLab [4]

     

     

     

    Conclusion

     

    More research needs to be done on this topic and this is just the tip of the iceberg.

     

    To conclude and speed up research, clipboard can be used to analyse ITEMIDLIST structure. Clipboard will use the same type of structure when copying/pasting files. With InsideClipboard, you can view "live" the FILE_ENTRY structure and play with it (just do a Ctrl-C on the file(s) you want to see the ITEMIDLIST). The structure is stored in the Shell IDList Array (CFSTR_SHELLIDLIST). The array begins with a CIDA structure (http://msdn.microsoft.com/en-us/library/windows/desktop/bb773212(v=vs.85).aspx) followed by the ITEMIDLIST structures we find in the shellbags key.

     

     

    Here's the references and tools I used for my tests (thanks to everyone)

     

    Willi Ballenthin - http://www.williballenthin.com/forensics/shellbags/index.html

    Harlan Carvey - http://code.google.com/p/regripper/wiki/ShellBags

    Joachim Metz - http://liblnk.googlecode.com/files/Windows%20Shell%20Item%20format.pdf

    Jamie Levy - http://volatility-labs.blogspot.ca/2012/09/movp-32-shellbags-in-memory-setregtime.html

    InsideClipboard - http://www.nirsoft.net/utils/inside_clipboard.html

     

     

    [1] http://www.dfrws.org/2009/proceedings/p69-zhu.pdf

    [2] http://msdn.microsoft.com/en-us/library/windows/desktop/bb776161(v=vs.85).aspx

    [3] http://msdn.microsoft.com/en-us/library/windows/desktop/aa768196(v=vs.85).aspx

    [4] CyanLab - http://blog.0x01000000.org/2010/08/13/lnk-parsing-youre-doing-it-wrong-ii/

     

     

    Sebastien Bourdon-Richard

  • Harlan Carvey
    Sebastien, Thanks for providing this research... ... 45 25 ad d0 11 98 a8 08 00 36 1b 11 03 ... is not an invalid entry.  It s a SHITEMID structure   Yes, I
    Message 2 of 2 , Nov 1, 2012
    View Source
    • 0 Attachment
      Sebastien,

      Thanks for providing this research...

      14 00 1f 48 ba 8f 0d
      45 25 ad d0 11 98 a8 08 00 36 1b 11 03
      >
      > This
      is not an invalid entry.  It's a SHITEMID structure
       
      Yes, I think that Joachim and Willi had documented this, and that this was documented
      in the code that Kevin Moore provided for the Registry Decoder.

      > The
      only thing I would like to add about Jamie's description is about the SHELL_ITEM_TYPES
      >  (i.e: 0x32). I found that this structure is actually a
      TRANSFER_SOURCE_FLAGS structure.

      How were you able to correlate that structure to the specific data (ie, 0x32)?

      Again, thanks for providing this information...it looks as if it will be extremely helpful.

      ------------------------------------------
      Harlan Carvey
      "Windows Forensic Analysis"
      http://windowsir.blogspot.com
      ------------------------------------------


      From: Sebastien Bourdon-Richard <sebastienbr@...>
      To: win4n6@yahoogroups.com
      Cc: William Ballenthin <william.ballenthin@...>; Harlan Carvey <keydet89@...>; jamie.levy@...; joachim.metz@...
      Sent: Wednesday, October 31, 2012 10:11 PM
      Subject: Shellbag research

      Hi everyone,

      I don't have a blog, so I will publish my finding here. Big thanks to everyone who is doing research in this area! Here's my small contribution to shellbag research.
       
      These are not extensive research and they were done on my spare time.
       
       
      Introduction
       
      I will not introduce shellbags because they have been described in a lot of places. Good introduction can be found here [1].
       
      What we found in registry are refered as IProperty by MSDN [2]. Each property is described with a name, whose value is stored in a VARIANT [3]
       
      Actually, those VARIANT seems to contains (or  are) ITEMIDLIST. 
       
      "An ITEMIDLIST is nothing more than a list of ITEMID/SHITEMID (IID) which are contiguous. It is terminated by an empty IID which is defined as a 0-size IID. The size for each IID accounts for the size member itself as well. The ITEMIDLIST has to be NULL-IID terminated" [4]
       
      ITEMIDLIST are not only found in Shellbags. These structures are also found in:
      • ViewView2
      • Lnk files
      • Clipboard
       
       
      ItemPos Structure
       
      What we found in ItemPos and BagMRU are ITEMIDLIST structure. 
       
      typedef struct _ITEMIDLIST {
        SHITEMID mkid;
      } ITEMIDLIST;
       
      ITEMIDLIST are a list of SHITEMID
       
      typedef struct _SHITEMID {
        USHORT cb;
        BYTE   abID[1];
      } SHITEMID;
       

       
       
      Let's take the key ItemPos1171x730(1) as an example.
       
      Inline image 1

       
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       
      First offset filed with 00, not sure what it is.
       
      17 00 00 00 02 00 00 00
       
      More reseach need to be done on those.
       
      17 00 00 00: Repeated in the ItemPos key. Maybe it's related to PIDL, but I'm not sure
      02 00 00 00: Icon position, in this case on the desktop
       
       
      14 00 1f 48 ba 8f 0d 45 25 ad d0 11 98 a8 08 00 36 1b 11 03
       
      This is not an invalid entry.  It's a SHITEMID structure
       
      14 00 is the size of this structure.
      1F 48 - ?
      ba 8f 0d 45 25 ad d0 11 98 a8 08 00 36 1b 11 03 is a CLSID
       
      {450d8fba-ad25-11d0-98a8-0800361b1103} = My Document
      (Description of CLSID can be found here: http://www.autohotkey.com/docs/misc/CLSID-List.htm or in HKCR\CLSID)
       
       
      17 00 00 00 4f 00 00 00 14 00 1f 50 e0 4f d0 20 ea 3a 69 10 a2 d8 08 00 2b 30 30 9d
       
      Icon position: 0x4F
      SHITEMID structure
      • CLSID: {20d04fe0-3aea-1069-a2d8-08002b30309d} = My Computer
       
       
      17 00 00 00 9c 00 00 00
      14 00 1f 58 60 2c 8d 20 ea 3a 69 10 a2 d7 08 00 2b 30 30 9d bf
      03 00 00 6a 02 00 00
      14 00 1f 60 40 f0 5f 64 81 50 1b 10 9f 08 00 aa 00 2f 95 4e
       
      Icon position: 0x9C
      SHITEMID structure
      • {208d2c60-3aea-1069-a2d7-08002b30309d} = My Network Place
      Icon position: 0x6A02
      SHITEMID structure
      • {645ff040-5081-101b-9f08-00aa002f954e} = Recycled bin
       
       
      17 00 00 00 e9 00 00 00
       
      Icon position: 0xE9
       
       
      4e 00 32 00 c0 f8 f7 00 …
       
      This is another SHITEMID structure (FILE_ENTRY structure as described by Jamie).
       
      The only thing I would like to add about Jamie's description is about the SHELL_ITEM_TYPES (i.e: 0x32). I found that this structure is actually a TRANSFER_SOURCE_FLAGS structure.
       
      typedef enum _TRANSFER_SOURCE_FLAGS {
        TSF_NORMAL                      = 0,
        TSF_FAIL_EXIST                  = 0,
        TSF_RENAME_EXIST                = 0x1,
        TSF_OVERWRITE_EXIST             = 0x2,
        TSF_ALLOW_DECRYPTION            = 0x4,
        TSF_NO_SECURITY                 = 0x8,
        TSF_COPY_CREATION_TIME          = 0x10,
        TSF_COPY_WRITE_TIME             = 0x20,
        TSF_USE_FULL_ACCESS             = 0x40,
        TSF_DELETE_RECYCLE_IF_POSSIBLE  = 0x80,
        TSF_COPY_HARD_LINK              = 0x100,
        TSF_COPY_LOCALIZED_NAME         = 0x200,
        TSF_MOVE_AS_COPY_DELETE         = 0x400,
        TSF_SUSPEND_SHELLEVENTS         = 0x800
      } TRANSFER_SOURCE_FLAGS;
       
       
      0x32 means
      • TSF_OVERWRITE_EXIST 
      • TSF_COPY_CREATION_TIME
      • TSF_COPY_WRITE_TIME  
       
      0x31 is the value for a folder. This is because when you copy paste a folder, and if the destination already exists, the folder will be renamed automatically ( TSF_RENAME_EXIST). For a file, Windows will ask if you want to overwrite the existing file.
       
      I also noticed a behavior under Windows 7 (not sure if it's apply to all windows version). If the FILE_ENTRY structure is located on the public desktop (i.e: c:\users\public\desktop), there's no security associated to this file and TSF_NO_SECURITY flag will be set. So files on the default desktop will have an id of 0x3A and a folder will have the id 0x39.
       
       
      17 00 00 00 36 01 00 00
      Icon position:  0x3601
       
      5c 00 3a 00 cc 06 00 00 5a ..
       
      This is another SHITEMID structure (FILE_ENTRY structure).
       
      17 00 00 00 36 01 00 00 00 00 00 00
      The ITEMIDLIST is NULL-IID terminated as describe by CyanLab [4]
       
       
       
      Conclusion
       
      More research needs to be done on this topic and this is just the tip of the iceberg.
       
      To conclude and speed up research, clipboard can be used to analyse ITEMIDLIST structure. Clipboard will use the same type of structure when copying/pasting files. With InsideClipboard, you can view "live" the FILE_ENTRY structure and play with it (just do a Ctrl-C on the file(s) you want to see the ITEMIDLIST). The structure is stored in the Shell IDList Array (CFSTR_SHELLIDLIST). The array begins with a CIDA structure (http://msdn.microsoft.com/en-us/library/windows/desktop/bb773212(v=vs.85).aspx) followed by the ITEMIDLIST structures we find in the shellbags key.
       
       
      Here's the references and tools I used for my tests (thanks to everyone)
       
       
       
       
       
      Sebastien Bourdon-Richard


    Your message has been successfully submitted and would be delivered to recipients shortly.