driver handling \Device\

In windows there are device like \Device\ that could be found using Winobj from Sysinternals.
How can we find out which kernel side driver is handling operations for that device?

Im sorry for not being able to ask my question in more clear way.

I googled but wasn't able to get far.

First you can get a list of devices by interrogating the \device directory of the object manager:

0: kd> !object \Device
Object: ffffe48ed7a9ab90  Type: (ffff9b89548e1380) Directory
    ObjectHeader: ffffe48ed7a9ab60 (new version)
    HandleCount: 2 PointerCount: 66188
    Directory Object: ffffe48ed7a56e00  Name: Device

    Hash Address          Type                      Name
    ---- -------          ----                      ----
     00  ffff9b896bf89e00 Device                    000000ed
         ffff9b8965a4ae00 Device                    000000c7
         ffff9b8967b7cd40 Device                    000000b3
         ffff9b8965c9ca70 Device                    UMDFCtrlDev-624c4811-0bbc-11ee-a47f-107b441961bb
         ffff9b895e77c630 Device                    0000007e
         ...
         ffff9b8954edadf0 Device                    CNG

I'm going to go with CNG, since you should have this one too (it's the Windows "Crypto Next Generation" driver).

0: kd> !devobj ffff9b8954edadf0
Device object (ffff9b8954edadf0) is for:
 CNG \Driver\CNG DriverObject ffff9b8954ee0e30
 ...

The driver is \Driver\CNG and its object (_DRIVER_OBJECT) is at ffff9b8954ee0e30:

0: kd> dt _driver_object ffff9b8954ee0e30
nt!_DRIVER_OBJECT
   +0x000 Type             : 0n4
   +0x002 Size             : 0n336
   +0x008 DeviceObject     : 0xffff9b89`54edadf0 _DEVICE_OBJECT
   +0x010 Flags            : 0x12
   +0x018 DriverStart      : 0xfffff804`2e710000 Void
   +0x020 DriverSize       : 0xbb000
   +0x028 DriverSection    : 0xffff9b89`54843c50 Void
   +0x030 DriverExtension  : 0xffff9b89`54ee0f80 _DRIVER_EXTENSION
   +0x038 DriverName       : _UNICODE_STRING "\Driver\CNG"
   +0x048 HardwareDatabase : 0xfffff804`2bb2e990 _UNICODE_STRING "\REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM"
   +0x050 FastIoDispatch   : (null)
   +0x058 DriverInit       : 0xfffff804`2e7c3010     long  cng!GsDriverEntry+0
   +0x060 DriverStartIo    : (null)
   +0x068 DriverUnload     : (null)
   +0x070 MajorFunction    : [28] 0xfffff804`2e717900     long  cng!CngDispatch+0

Since you have the base address of the module (it's the DriverStart field) you can just lm it to get the module path:

0: kd> lmDkif a 0xfffff804`2e710000
Browse full module list
start             end                 module name
fffff804`2e710000 fffff804`2e7cb000   cng      \SystemRoot\System32\drivers\cng.sys

The interesting option here is f:

> Displays the full image path. (This path always matches the path that is displayed in the initial load notification, unless you issued a .reload -s command.) When you use f, symbol type information is not displayed.

So, \Device\CNG is handled by %SYSTEMROOT%\System32\drivers\cng.sys.

Another (undocumented) trick is to cast the DriverSection field (which is just a void* in the symbols) to a _LDR_DATA_TABLE_ENTRY. This field is actually not really a loader data table entry (which works for user modules, but not exactly for kernel ones; the real structure is not in the symbols). The first few fields in the output are correct though:

0: kd> dt _ldr_data_table_entry 0xffff9b89`54843c50
nt!_LDR_DATA_TABLE_ENTRY
   +0x000 InLoadOrderLinks : _LIST_ENTRY [ 0xffff9b89`54843e10 - 0xffff9b89`54881dc0 ]
   +0x010 InMemoryOrderLinks : _LIST_ENTRY [ 0xfffff804`2e7bb000 - 0x00000000`00004b0c ]
   +0x020 InInitializationOrderLinks : _LIST_ENTRY [ 0x00000000`00000000 - 0x00000000`00000000 ]
   +0x030 DllBase          : 0xfffff804`2e710000 Void
   +0x038 EntryPoint       : 0xfffff804`2e7c3010 Void
   +0x040 SizeOfImage      : 0xbb000
   +0x048 FullDllName      : _UNICODE_STRING "\SystemRoot\System32\drivers\cng.sys"
   +0x058 BaseDllName      : _UNICODE_STRING "cng.sys"
   ...
   ... !!! remainder of the fields are wrong !!!
   ...

Edit

Same with \device\tcp:

2: kd> !object \device\tcp
Object: ffffa88cb3c98c00  Type: (ffffa88cb32b4d20) Device
    ObjectHeader: ffffa88cb3c98bd0 (new version)
    HandleCount: 0  PointerCount: 4
    Directory Object: ffff9581e383ad80  Name: Tcp

2: kd> !devobj ffffa88cb3c98c00
Device object (ffffa88cb3c98c00) is for:
 Tcp \Driver\tdx DriverObject ffffa88cb3f61e00
Current Irp 00000000 RefCount 85 Type 00000012 Flags 00000050
SecurityDescriptor ffff9581e3c17e60 DevExt ffffa88cb3c98d50 DevObjExt ffffa88cb3c98d58 
ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000100)  FILE_DEVICE_SECURE_OPEN
Device queue is not busy.

Asking for more information by using the 7 (1 | 2 | 4) flag concerning the driver object:

2: kd> !drvobj \Driver\tdx 7
Driver object (ffffa88cb3f61e00) is for:
 \Driver\tdx

Driver Extension List: (id , addr)

Device Object list:
ffffa88cb3c5cc00  ffffa88cb3c64c00  ffffa88cb3c69c00  ffffa88cb3c73c00
ffffa88cb3c76c00  ffffa88cb3c98c00  ffffa88cb3c9bc00  

DriverEntry:   fffff8052c5ce010	
DriverStartIo: 00000000	
DriverUnload:  fffff8052c5c3870	
AddDevice:     00000000	

Dispatch routines:
[00] IRP_MJ_CREATE                      fffff8052c5c2f30	+0xfffff8052c5c2f30
[01] IRP_MJ_CREATE_NAMED_PIPE           fffff80526744b60	nt!IopInvalidDeviceRequest
[02] IRP_MJ_CLOSE                       fffff8052c5c2e90	+0xfffff8052c5c2e90
[03] IRP_MJ_READ                        fffff80526744b60	nt!IopInvalidDeviceRequest
[04] IRP_MJ_WRITE                       fffff80526744b60	nt!IopInvalidDeviceRequest
[05] IRP_MJ_QUERY_INFORMATION           fffff80526744b60	nt!IopInvalidDeviceRequest
[06] IRP_MJ_SET_INFORMATION             fffff80526744b60	nt!IopInvalidDeviceRequest
[07] IRP_MJ_QUERY_EA                    fffff80526744b60	nt!IopInvalidDeviceRequest
[08] IRP_MJ_SET_EA                      fffff80526744b60	nt!IopInvalidDeviceRequest
[09] IRP_MJ_FLUSH_BUFFERS               fffff80526744b60	nt!IopInvalidDeviceRequest
[0a] IRP_MJ_QUERY_VOLUME_INFORMATION    fffff80526744b60	nt!IopInvalidDeviceRequest
[0b] IRP_MJ_SET_VOLUME_INFORMATION      fffff80526744b60	nt!IopInvalidDeviceRequest
[0c] IRP_MJ_DIRECTORY_CONTROL           fffff80526744b60	nt!IopInvalidDeviceRequest
[0d] IRP_MJ_FILE_SYSTEM_CONTROL         fffff80526744b60	nt!IopInvalidDeviceRequest
[0e] IRP_MJ_DEVICE_CONTROL              fffff8052c5c3220	+0xfffff8052c5c3220
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL     fffff8052c5b1010	+0xfffff8052c5b1010
[10] IRP_MJ_SHUTDOWN                    fffff80526744b60	nt!IopInvalidDeviceRequest
[11] IRP_MJ_LOCK_CONTROL                fffff80526744b60	nt!IopInvalidDeviceRequest
[12] IRP_MJ_CLEANUP                     fffff8052c5c2e00	+0xfffff8052c5c2e00
[13] IRP_MJ_CREATE_MAILSLOT             fffff80526744b60	nt!IopInvalidDeviceRequest
[14] IRP_MJ_QUERY_SECURITY              fffff80526744b60	nt!IopInvalidDeviceRequest
[15] IRP_MJ_SET_SECURITY                fffff80526744b60	nt!IopInvalidDeviceRequest
[16] IRP_MJ_POWER                       fffff80526744b60	nt!IopInvalidDeviceRequest
[17] IRP_MJ_SYSTEM_CONTROL              fffff8052c5c3640	+0xfffff8052c5c3640
[18] IRP_MJ_DEVICE_CHANGE               fffff80526744b60	nt!IopInvalidDeviceRequest
[19] IRP_MJ_QUERY_QUOTA                 fffff80526744b60	nt!IopInvalidDeviceRequest
[1a] IRP_MJ_SET_QUOTA                   fffff80526744b60	nt!IopInvalidDeviceRequest
[1b] IRP_MJ_PNP                         fffff80526744b60	nt!IopInvalidDeviceRequest

Technically, you can just ask any address in the module using lm, so rather than the DriverStart I'll be using one of the adresses in the module (its DriverEntry; but one of the IRP handler would do it too, at least if it's in the module, not in nt or elsewhere).

2: kd> lm a fffff8052c5ce010	
Browse full module list
start             end                 module name
fffff805`2c5b0000 fffff805`2c5d2000   tdx        (pdb symbols)          g:\symbols\tdx.pdbE0FDAAC67460365A3A443A924463EE1\tdx.pdb

You'll need symbolic information for that though, see .reload /f /n (doc).