1

In Windows 10 looking at ntoskrnl!IopParseDevice I'm trying to work out the name / purpose of the flags in this check, which seem to be testing for values in a DEVICE_OBJECT Characteristics property and the flags property. In particular checking for device object characteristics 40001h and flags 600100h

What what I can tell the 0x40000 device characteristic and flags adding up to 0x600000h aren't defined in the Windows Driver kit.

The section of code is:

    PAGE:00000001404197CC                                                 ; 825:     Characteristics = DEVICE_OBJECT->Characteristics;
PAGE:00000001404197CC
PAGE:00000001404197CC                                                 loc_1404197CC:                          ; CODE XREF: IopParseDevice+CFD↑j
PAGE:00000001404197CC                                                                                         ; IopParseDevice+D17↑j ...
PAGE:00000001404197CC 8B 4E 34                                                        mov     ecx, [rsi+34h]
PAGE:00000001404197CF                                                 ; 826:     if ( (Characteristics & 0x40001) == 0 || (DEVICE_OBJECT->Flags & 0x600100) != 0 )
PAGE:00000001404197CF F7 C1 01 00 04 00                                               test    ecx, 40001h
PAGE:00000001404197D5 74 64                                                           jz      short loc_14041983B
PAGE:00000001404197D7 F7 46 30 00 01 60 00                                            test    dword ptr [rsi+30h], 600100h
PAGE:00000001404197DE 75 5B                                                           jnz     short loc_14041983B
PAGE:00000001404197E0                                                 ; 832:       v114 = (struct _SECURITY_SUBJECT_CONTEXT *)a3;
PAGE:00000001404197E0 48 8B 7C 24 58                                                  mov     rdi, [rsp+208h+AccessState]
PAGE:00000001404197E5                                                 ; 833:       if ( (Characteristics & 0x100) == 0 )
PAGE:00000001404197E5 0F BA E1 08                                                     bt      ecx, 8
PAGE:00000001404197E9 72 55                                                           jb      short loc_140419840
PAGE:00000001404197EB                                                 ; 835:         v215[0] = 0;
PAGE:00000001404197EB C6 44 24 60 00                                                  mov     [rsp+208h+var_1A8], 0
PAGE:00000001404197F0                                                 ; 836:         SeIsAppContainerOrIdentifyLevelContext(a3 + 32, v215);
PAGE:00000001404197F0 48 8D 4F 20                                                     lea     rcx, [rdi+20h]
PAGE:00000001404197F4 48 8D 54 24 60                                                  lea     rdx, [rsp+208h+var_1A8]
PAGE:00000001404197F9 E8 62 C8 07 00                                                  call    SeIsAppContainerOrIdentifyLevelContext

When stepping through via a Kernel debugger, on calling nt!NtQueryFullAttributesFile with object attributes pointing to path "??\C:" the value being checked with test ecx instruction is set to 0x00060000. The value for test dword ptr [rsi+30h] (flags) differs depending on what drive I select. For ??\C:\ this is set to 0x1150 and for ??\E:\ it is set to 0x3050.

In wdm.h from Windows DDK can see the following definitions:

//
// Define the various device characteristics flags
//

#define FILE_REMOVABLE_MEDIA                        0x00000001
#define FILE_READ_ONLY_DEVICE                       0x00000002
#define FILE_FLOPPY_DISKETTE                        0x00000004
#define FILE_WRITE_ONCE_MEDIA                       0x00000008
#define FILE_REMOTE_DEVICE                          0x00000010
#define FILE_DEVICE_IS_MOUNTED                      0x00000020
#define FILE_VIRTUAL_VOLUME                         0x00000040
#define FILE_AUTOGENERATED_DEVICE_NAME              0x00000080
#define FILE_DEVICE_SECURE_OPEN                     0x00000100
#define FILE_CHARACTERISTIC_PNP_DEVICE              0x00000800
#define FILE_CHARACTERISTIC_TS_DEVICE               0x00001000
#define FILE_CHARACTERISTIC_WEBDAV_DEVICE           0x00002000
#define FILE_CHARACTERISTIC_CSV                     0x00010000
#define FILE_DEVICE_ALLOW_APPCONTAINER_TRAVERSAL    0x00020000
#define FILE_PORTABLE_DEVICE                        0x00040000
#define FILE_REMOTE_DEVICE_VSMB                     0x00080000
#define FILE_DEVICE_REQUIRE_SECURITY_CHECK          0x00100000

// Define Device Object (DO) flags
    //
    // DO_DAX_VOLUME - If set, this is a DAX volume i.e. the volume supports mapping a file directly
    // on the persistent memory device.  The cached and memory mapped IO to user files wouldn't
    // generate paging IO.
    //
    #define DO_VERIFY_VOLUME                    0x00000002      
    #define DO_BUFFERED_IO                      0x00000004      
    #define DO_EXCLUSIVE                        0x00000008      
    #define DO_DIRECT_IO                        0x00000010      
    #define DO_MAP_IO_BUFFER                    0x00000020      
    #define DO_DEVICE_INITIALIZING              0x00000080      
    #define DO_SHUTDOWN_REGISTERED              0x00000800      
    #define DO_BUS_ENUMERATED_DEVICE            0x00001000      
    #define DO_POWER_PAGABLE                    0x00002000      
    #define DO_POWER_INRUSH                     0x00004000      
    #define DO_DEVICE_TO_BE_RESET               0x04000000      
    #define DO_DAX_VOLUME                       0x10000000
Improve this question
2
  • Would be good if you could give either a hash (or the PDB identifier) or a full version number of the ntoskrnl.exe you're looking at, so others can follow along.
    – 0xC0000022L ♦
    Apr 27, 2022 at 8:19
  • In general, I think it's good advice to keep older DDKs and latest WDKs handy and have a good and fast text search tool to look for these items. Adding the ReactOS code into the mix is certainly a good idea, but results from it should be taken with a pinch of salt. What also often works are code searches for those symbolic names you know to find adjacent ones you don't know.
    – 0xC0000022L ♦
    Apr 27, 2022 at 8:45

1 Answer 1

Reset to default
1

Hmm, not sure which WDK you were using, but at least the Windows Kits\10\Include\10.0.22000.0\km\ntifs.h and Windows Kits\10\Include\10.0.22000.0\km\ntddk.h of the newest (non-preview/beta) WDK list:

#define DO_VERIFY_VOLUME                    0x00000002
#define DO_BUFFERED_IO                      0x00000004
#define DO_EXCLUSIVE                        0x00000008
#define DO_DIRECT_IO                        0x00000010
#define DO_MAP_IO_BUFFER                    0x00000020
#define DO_DEVICE_HAS_NAME                  0x00000040 // *
#define DO_DEVICE_INITIALIZING              0x00000080
#define DO_SYSTEM_BOOT_PARTITION            0x00000100 // *
#define DO_LONG_TERM_REQUESTS               0x00000200 // *
#define DO_NEVER_LAST_DEVICE                0x00000400 // *
#define DO_SHUTDOWN_REGISTERED              0x00000800
#define DO_BUS_ENUMERATED_DEVICE            0x00001000
#define DO_POWER_PAGABLE                    0x00002000
#define DO_POWER_INRUSH                     0x00004000
#define DO_LOW_PRIORITY_FILESYSTEM          0x00010000 // *
#define DO_SUPPORTS_PERSISTENT_ACLS         0x00020000 // * <- only in ntifs.h
#define DO_SUPPORTS_TRANSACTIONS            0x00040000 // *
#define DO_FORCE_NEITHER_IO                 0x00080000 // *
#define DO_VOLUME_DEVICE_OBJECT             0x00100000 // *
#define DO_SYSTEM_SYSTEM_PARTITION          0x00200000 // *
#define DO_SYSTEM_CRITICAL_PARTITION        0x00400000 // *
#define DO_DISALLOW_EXECUTE                 0x00800000 // *
#define DO_DEVICE_TO_BE_RESET               0x04000000
#define DO_DEVICE_IRP_REQUIRES_EXTENSION    0x08000000 // *
#define DO_DAX_VOLUME                       0x10000000
#define DO_BOOT_CRITICAL                    0x20000000

Those marked with * are not on the list you gave. But I think this list is comprehensive enough to decode almost (except for 0x01) all items you were looking for:

  • 0x40001 == DO_SUPPORTS_TRANSACTIONS | 0x01
  • 0x600100 == DO_SYSTEM_BOOT_PARTITION | DO_SYSTEM_SYSTEM_PARTITION | DO_SYSTEM_CRITICAL_PARTITION

I was, however, at first also unable to find what the 0x01 flag means. However, if ReactOS is to be trusted (and often it can be trusted in those matters, but not always) this could be:

#define DO_UNLOAD_PENDING               0x00000001
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.