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.pdb\89E0FDAAC67460365A3A443A924463EE1\tdx.pdb
You'll need symbolic information for that though, see .reload /f /n (doc).