驱动中获取进程完整路径名

不念不忘少年蓝@ 2022-07-16 12:14 449阅读 0赞

Submitted by **[boxcounter][]**on 2009, July 23, 6:55 PM. [windows编程(R0)][windows_R0]

在OSR上无意中看到一篇文章，关于获取进程完整路径的。贴过来，最后有一点小调整。

原文地址：[http://www.osronline.com/article.cfm?id=472][http_www.osronline.com_article.cfm_id_472]

--------------------

Over the years developers have needed or wanted to know the name of the image executing in a given process. Traditionally, this was often done using **PsGetProcessImageFile Name** , which returns the contents of a field in the **EPROCESS** structure used by the Windows OS to maintain per-process state information.

As we can see from the information in the local debugger session (See *Figure 1* ) the process image file is little more than a field within the EPROCESS structure. Notice that the EPROCESS address is in EBP+8, making it the first - and only - parameter to this function.

<table style="width:710px; height:408px"> 
 <tbody> 
 <tr> 
 <td> Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE Symbol search path is: srv*c:/symbols/websymbols*http://msdl.microsoft.com/download/symbols Executable search path is: ******************************************************************************* WARNING: Local kernel debugging requires booting with /debug to work optimally. ******************************************************************************* Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible Product: winNt, suite: Terminalserver SingleUserTS Built by: 2600.xpsp_sp2_gdr.050301-1519 Kernel base = 0x804d7000 PsLoadedModuleList = 0x805624a0 Debug session time: Mon Aug&nbsp; 7 13:29:53.486 2006 (GMT-4) System Uptime: 2 days 11:08:38.140 lkd&gt; .reload Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE Loading Kernel Symbols .............................................................................. Loading User Symbols .............................................................................. Loading unloaded module list .......................*** ERROR: Symbol file could not be found.&nbsp; Defaulted to export symbols for C lkd&gt; u nt!PsGetProcessImageFileName Nt!PsGetProcessImageFileName: 8050a14a&nbsp; 8bff mov edi,edi 8050a14c&nbsp; 55 push ebp 8050a14d&nbsp; 8bec mov ebp,esp 8050a14f&nbsp; 8b4508 mov eax,dword ptr [ebp+8] 8050a152&nbsp; 0574010000 add eax,174h 8050a157&nbsp; 5d pop ebp 8050a158&nbsp; c20400 ret 4 8050a15b&nbsp; 8bce mov ecx,esi Figure 1 - Local Debug Session of PsGetProcessImageFileName </td> 
 </tr> 
 </tbody> 
</table>

Unfortunately, there are some issues with this approach:

*  Though well-known, this function is undocumented.
 *  More seriously, the information contained in this field is severely limited. It contains only the first 16 (ASCII) characters of the image file name.

It is actually the second issue that often creates problems for programmers because the name of the image file means essentially nothing. For example, we've seen kernel-mode drivers in the past that validate the name of their service by checking this field. The most egregious case we've seen is when the service was called svchost.exe, which is a common name that is often spoofed.

**The Proposal**  
We suggest a different model for acquiring this information, as shown in *Figure 2* .

<table style="width:543px; height:1462px"> 
 <tbody> 
 <tr> 
 <td> typedef NTSTATUS (*QUERY_INFO_PROCESS) ( &nbsp;&nbsp;&nbsp; __in HANDLE ProcessHandle, &nbsp;&nbsp;&nbsp; __in PROCESSINFOCLASS ProcessInformationClass, &nbsp;&nbsp;&nbsp; __out_bcount(ProcessInformationLength) PVOID ProcessInformation, &nbsp;&nbsp;&nbsp; __in ULONG ProcessInformationLength, &nbsp;&nbsp;&nbsp; __out_opt PULONG ReturnLength &nbsp;&nbsp;&nbsp; ); QUERY_INFO_PROCESS ZwQueryInformationProcess; NTSTATUS GetProcessImageName(PUNICODE_STRING ProcessImageName) { &nbsp;&nbsp;&nbsp; NTSTATUS status; &nbsp;&nbsp;&nbsp; ULONG returnedLength; &nbsp;&nbsp;&nbsp; ULONG bufferLength; &nbsp;&nbsp;&nbsp; PVOID buffer; &nbsp;&nbsp;&nbsp; PUNICODE_STRING imageName; &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; PAGED_CODE(); // this eliminates the possibility of the IDLE Thread/Process &nbsp;&nbsp;&nbsp; if (NULL == ZwQueryInformationProcess) { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UNICODE_STRING routineName; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RtlInitUnicodeString(&amp;routineName, L"ZwQueryInformationProcess"); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ZwQueryInformationProcess =&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (QUERY_INFO_PROCESS) MmGetSystemRoutineAddress(&amp;routineName); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (NULL == ZwQueryInformationProcess) { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DbgPrint("Cannot resolve ZwQueryInformationProcess/n"); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; // &nbsp;&nbsp;&nbsp; // Step one - get the size we need &nbsp;&nbsp;&nbsp; // &nbsp;&nbsp;&nbsp; status = ZwQueryInformationProcess( NtCurrentProcess(),&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ProcessImageFileName, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NULL, // buffer &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0, // buffer size &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;returnedLength); &nbsp;&nbsp;&nbsp; if (STATUS_INFO_LENGTH_MISMATCH != status) { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return status; &nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; // &nbsp;&nbsp;&nbsp; // Is the passed-in buffer going to be big enough for us?&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; // This function returns a single contguous buffer model... &nbsp;&nbsp;&nbsp; // &nbsp;&nbsp;&nbsp; bufferLength = returnedLength - sizeof(UNICODE_STRING); &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if (ProcessImageName-&gt;MaximumLength &lt; bufferLength) { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ProcessImageName-&gt;Length = (USHORT) bufferLength; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return STATUS_BUFFER_OVERFLOW; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; // &nbsp;&nbsp;&nbsp; // If we get here, the buffer IS going to be big enough for us, so&nbsp; &nbsp;&nbsp;&nbsp; // let's allocate some storage. &nbsp;&nbsp;&nbsp; // &nbsp;&nbsp;&nbsp; buffer = ExAllocatePoolWithTag(PagedPool, returnedLength, 'ipgD'); &nbsp;&nbsp;&nbsp; if (NULL == buffer) { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return STATUS_INSUFFICIENT_RESOURCES; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; // &nbsp;&nbsp;&nbsp; // Now lets go get the data &nbsp;&nbsp;&nbsp; // &nbsp;&nbsp;&nbsp; status = ZwQueryInformationProcess( NtCurrentProcess(),&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ProcessImageFileName, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; buffer, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; returnedLength, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;returnedLength); &nbsp;&nbsp;&nbsp; if (NT_SUCCESS(status)) { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // Ah, we got what we needed &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; imageName = (PUNICODE_STRING) buffer; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RtlCopyUnicodeString(ProcessImageName, imageName); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; // &nbsp;&nbsp;&nbsp; // free our buffer &nbsp;&nbsp;&nbsp; // &nbsp;&nbsp;&nbsp; ExFreePool(buffer); &nbsp;&nbsp;&nbsp; // &nbsp;&nbsp;&nbsp; // And tell the caller what happened. &nbsp;&nbsp;&nbsp; //&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; return status; &nbsp;&nbsp;&nbsp;&nbsp; } Figure 2 - A New Proposal </td> 
 </tr> 
 </tbody> 
</table>

The function itself is fairly straight-forward. It does rely on use of a single undocumented function (**ZwQueryInformationProcess** ), but note that its counterpart (**NtQueryInformationProcess** ) is documented. We need to use the Zw variant in order to use a kernel memory buffer.

The key element is that Windows has always stored the full path name to the executable image in order to provide this information in the*auditing* subsystem. This API exploits that existing stored path name.

***Other* Process Names**  
This function has been implemented to extract the process name for the *current* process. However, you can use one of the two methods listed below to obtain the process name for a different process:

> 1. If you have a handle for the process, you can use that value instead of the **NtCurrentProcess()** macro. (Note that in our experience, we usually have a process *object* and not a process *handle* \- the two are *not* interchangeable).
> 
> 2. If you have an EPROCESS address, you can use **KeStackAttachProcess/KeUnstackDetachProcess** to attach to the process. This technique is rather heavy-weight, so it may be a good idea to cache the information if you need to perform this operation regularly.

When using the second technique, it is important to note that the name that is returned is a cached name. This cache is *not* updated if the name of the original file changes after the name is first cached. In other words, if the executable image is renamed, which is typically allowed for a running executable, the name returned will be the name of the original file.

This issue is not unique. We have also observed that some file systems return the original name even after a rename (e.g., the CIFS client implementation does this on Windows XP). Thus, it may require additional processing such as through a file system filter driver to protect against similar events. For example, you may encounter a security product that relies on knowing the specific name of the image.**Alternatives?**  
There are other options that a driver could also pursue such as registering for process creation/teardown events (**PsSetCreateProcessNotifyRoutine** ) or image loading (**PsSetLoadImageNotifyRoutine** ).

**PsSetCreateProcessNotifyRoutine** has limitations on the number of drivers that can register using this API. Since there is a fixed size table in the Windows OS, it is possible for this call to fail. When this occurs, a driver needs to ensure it can handle such a failure. PsSetLoadImageNotifyRoutine has the same limitation (fixed size table), but is called for all image loads, not just the original process image. Therefore, it includes drivers, DLLs, executables, etc.

**Summary**  
The bottom line is that all of these approaches provide a useful name because they include the full path name. This is vastly superior to using the short ASCII eye-catching name that is stored in the **EPROCESS** structure. A word of caution - if you decide to use the debug level name, use it for nothing more than debugging since it is not reliable and cannot be relied on for any sort of security check.

We chose to use the proposed technique because it works in all circumstances and does not rely upon a registration that might potentially fail. In your own driver you might implement both this mechanism and a cache-based mechanism tied to the process creation logic.

--------------------

文章里对于如何获取其他进程，提供了两种方法，但是都不太方便，在我的驱动里，我是在PsSetCreateProcessNotifyRoutine的回调函数里获取进程路径，能得到的进程信息是PID，于是动手改了下上面的代码，如下：

C++代码

1. NTSTATUS
2. GetProcessImagePath(
3. IN **DWORD** dwProcessId,
4. OUT PUNICODE\_STRING ProcessImagePath
5. )
6. \{
7. NTSTATUS Status;
8. **HANDLE** hProcess;
9. PEPROCESS pEprocess;
10. **ULONG** returnedLength;
11. **ULONG** bufferLength;
12. **PVOID** buffer;
13. PUNICODE\_STRING imageName;
14. 
15. PAGED\_CODE(); // this eliminates the possibility of the IDLE Thread/Process 
16. 
17. if (NULL == ZwQueryInformationProcess) \{
18. 
19. UNICODE\_STRING routineName;
20. 
21. RtlInitUnicodeString(&routineName, L "ZwQueryInformationProcess" );
22. 
23. ZwQueryInformationProcess =
24. (QUERY\_INFO\_PROCESS) MmGetSystemRoutineAddress(&routineName);
25. 
26. if (NULL == ZwQueryInformationProcess) \{
27. DbgPrint( "Cannot resolve ZwQueryInformationProcess/n" );
28. \}
29. \}
30. 
31. Status = PsLookupProcessByProcessId(( **HANDLE** )dwProcessId, &pEprocess);
32. if (!NT\_SUCCESS(Status)) 
 return Status;
33. 
34. Status = ObOpenObjectByPointer(pEprocess, // Object 
35. OBJ\_KERNEL\_HANDLE, // HandleAttributes 
36. NULL, // PassedAccessState OPTIONAL 
37. GENERIC\_READ, // DesiredAccess 
38. \*PsProcessType, // ObjectType 
39. KernelMode, // AccessMode 
40. &hProcess);
41. if (!NT\_SUCCESS(Status)) 
 return Status;
42. 
43. 
44. // 
45. // Step one - get the size we need 
46. // 
47. Status = ZwQueryInformationProcess( hProcess,
48. ProcessImageFileName,
49. NULL, // buffer 
50. 0, // buffer size 
51. &returnedLength);
52. 
53. 
54. if (STATUS\_INFO\_LENGTH\_MISMATCH != Status) \{
55. 
56. return Status;
57. 
58. \}
59. 
60. // 
61. // Is the passed-in buffer going to be big enough for us? 
62. // This function returns a single contguous buffer model... 
63. // 
64. bufferLength = returnedLength - sizeof (UNICODE\_STRING);
65. 
66. if (ProcessImagePath->MaximumLength < bufferLength) \{
67. 
68. ProcessImagePath->Length = ( **USHORT** ) bufferLength;
69. 
70. return STATUS\_BUFFER\_OVERFLOW;
71. 
72. \}
73. 
74. // 
75. // If we get here, the buffer IS going to be big enough for us, so 
76. // let's allocate some storage. 
77. // 
78. buffer = ExAllocatePoolWithTag(PagedPool, returnedLength, 'ipgD');
79. 
80. if (NULL == buffer) \{
81. 
82. return STATUS\_INSUFFICIENT\_RESOURCES;
83. 
84. \}
85. 
86. // 
87. // Now lets go get the data 
88. // 
89. Status = ZwQueryInformationProcess( hProcess,
90. ProcessImageFileName,
91. buffer,
92. returnedLength,
93. &returnedLength);
94. 
95. if (NT\_SUCCESS(Status)) \{
96. // 
97. // Ah, we got what we needed 
98. // 
99. imageName = (PUNICODE\_STRING) buffer;
100. 
101. RtlCopyUnicodeString(ProcessImagePath, imageName);
102. 
103. \}
104. 
105. ZwClose(hProcess);
106. 
107. // 
108. // free our buffer 
109. // 
110. ExFreePool(buffer);
111. 
112. // 
113. // And tell the caller what happened. 
114. // 
115. return Status;
116. 
117. \}

[boxcounter]: http://www.boxcounter.org/?action=finduser&userid=1
[windows_R0]: http://www.boxcounter.org/?action=index&cid=5
[http_www.osronline.com_article.cfm_id_472]: http://www.osronline.com/article.cfm?id=472