[Windows 驱动] 深入解析进程名获取的多种内核方法

1. Windows驱动开发中的进程名获取基础在Windows内核驱动开发中获取进程名是最基础但至关重要的操作之一。想象一下你正在开发一个安全监控驱动需要实时检查哪些进程正在运行或者你在开发一个性能优化工具需要针对特定进程进行资源分配。这些场景都离不开进程名的获取。内核模式下获取进程名与用户模式有很大不同。用户模式下我们可以直接调用EnumProcesses或CreateToolhelp32Snapshot等API但在内核中我们需要更底层的方法。这里主要涉及三个关键数据结构EPROCESSWindows内核中表示进程的核心结构体包含了进程的所有关键信息PEBProcess Environment Block进程环境块包含用户模式相关的进程信息KPROCESS内核进程控制块属于EPROCESS结构的一部分最常用的基础方法是PsGetProcessImageFileName它的函数原型非常简单NTKERNELAPI UCHAR* PsGetProcessImageFileName(__in PEPROCESS Process);这个函数返回的是进程映像文件名如notepad.exe而不是完整路径。它的优点是效率高直接访问EPROCESS结构中的特定字段。我在实际项目中发现这个方法在需要快速识别进程的场景下非常实用。2. 深入解析PsGetProcessImageFileName实现原理PsGetProcessImageFileName看起来简单但它的内部实现却很有意思。通过逆向分析我们可以发现它实际上是访问EPROCESS结构中的一个特定偏移量// 伪代码表示 PCHAR PsGetProcessImageFileName(PEPROCESS Process) { return (PCHAR)((PUCHAR)Process ImageFileNameOffset); }这里的ImageFileNameOffset在不同Windows版本中会变化。例如Windows 7 x86: 0x16CWindows 10 1809 x64: 0x450这种偏移量的变化正是驱动开发中需要特别注意的。我在开发跨版本兼容的驱动时通常会使用运行时检测的方法来确定偏移量而不是硬编码。获取当前进程名的典型代码流程如下PEPROCESS CurrentProcess PsGetCurrentProcess(); CHAR* ProcessName PsGetProcessImageFileName(CurrentProcess); DbgPrint(当前进程名: %s, ProcessName);需要注意的是PsGetProcessImageFileName返回的名称最大长度为15个字符不包括扩展名这是Windows内核的一个限制。如果进程名更长会被截断。3. 获取进程完整路径的进阶方法当我们需要获取进程的完整路径而不仅仅是文件名时PsGetProcessImageFileName就不够用了。这时可以使用PsReferenceProcessFilePointer配合其他APINTSTATUS GetProcessFullPath(PEPROCESS Process, PWSTR* FullPath) { PFILE_OBJECT FileObject NULL; NTSTATUS status PsReferenceProcessFilePointer(Process, FileObject); if (!NT_SUCCESS(status)) { return status; } status SeLocateProcessImageName(FileObject, FullPath); ObDereferenceObject(FileObject); return status; }这个方法更强大但也更复杂涉及以下几个关键点PsReferenceProcessFilePointer获取与进程关联的文件对象SeLocateProcessImageName从文件对象解析完整路径内存管理需要调用者负责释放返回的路径缓冲区我在实际使用中发现这种方法在以下场景特别有用需要验证进程来源是否可信时需要区分相同名称但不同路径的进程时需要获取进程签名信息时4. EPROCESS结构遍历技巧与实战有时候我们需要遍历系统中的所有进程这时就需要深入理解EPROCESS结构的组织方式。Windows内核使用双向链表连接所有进程的EPROCESS结构typedef struct _EPROCESS { KPROCESS Pcb; EX_PUSH_LOCK ProcessLock; LIST_ENTRY ActiveProcessLinks; // 这是连接所有进程的链表 // ...其他成员 } EPROCESS;遍历所有进程的基本方法PLIST_ENTRY ProcessListHead PsGetProcessListHead(); PLIST_ENTRY CurrentEntry ProcessListHead-Flink; while (CurrentEntry ! ProcessListHead) { PEPROCESS Process CONTAINING_RECORD(CurrentEntry, EPROCESS, ActiveProcessLinks); CHAR* ProcessName PsGetProcessImageFileName(Process); DbgPrint(发现进程: %s, ProcessName); CurrentEntry CurrentEntry-Flink; }这种方法虽然强大但有几点需要注意同步问题遍历过程中可能有进程创建或退出性能考虑遍历所有进程是耗时操作权限检查某些系统进程可能无法访问我在一个安全产品中实现过优化的遍历方法通过缓存进程列表和增量更新的方式显著提高了性能。5. 性能对比与最佳实践选择不同的进程名获取方法在性能和适用场景上各有优劣方法性能获取内容稳定性适用场景PsGetProcessImageFileName最高仅文件名高快速识别、过滤进程EPROCESS遍历中仅文件名中需要全系统进程列表PsReferenceProcessFilePointer低完整路径高需要验证进程来源根据我的经验选择方法时应考虑性能需求高频操作选择轻量级方法信息需求是否需要完整路径兼容性目标系统的Windows版本安全需求是否需要验证签名或路径在大多数情况下我会采用分层策略先用PsGetProcessImageFileName快速过滤对匹配的进程再使用完整路径验证对关键系统进程使用缓存机制6. 实际案例进程监控驱动的实现让我们看一个实际的驱动代码片段实现进程创建监控NTSTATUS InitializeProcessMonitor() { NTSTATUS status PsSetCreateProcessNotifyRoutineEx(ProcessNotifyCallbackEx, FALSE); if (!NT_SUCCESS(status)) { KdPrint((注册进程回调失败: 0x%X, status)); } return status; } VOID ProcessNotifyCallbackEx( _Inout_ PEPROCESS Process, _In_ HANDLE ProcessId, _Inout_opt_ PPS_CREATE_NOTIFY_INFO CreateInfo) { if (CreateInfo ! NULL) { // 进程创建事件 CHAR ImageName[16] {0}; RtlCopyMemory(ImageName, PsGetProcessImageFileName(Process), 15); if (strstr(ImageName, malware.exe)) { CreateInfo-CreationStatus STATUS_ACCESS_DENIED; KdPrint((阻止恶意进程创建: %s, ImageName)); } } }这个例子展示了如何注册进程创建回调获取新进程的名称根据名称采取行动如阻止可疑进程在实际产品中我们还会加入进程树分析父进程检测图像签名验证路径白名单检查7. 常见问题与调试技巧在开发进程相关功能时我遇到过不少坑这里分享几个常见问题和解决方法问题1获取的进程名为空或乱码原因进程可能正在退出或EPROCESS结构无效解决增加有效性检查if (Process NULL || !MmIsAddressValid(Process)) { return STATUS_INVALID_PARAMETER; }问题2蓝屏在PsGetProcessImageFileName调用处原因可能传入了无效的EPROCESS指针解决确保正确获取EPROCESSPEPROCESS Process; NTSTATUS status PsLookupProcessByProcessId(ProcessId, Process); if (!NT_SUCCESS(status)) { return status; } // 使用Process... ObDereferenceObject(Process);调试技巧使用dt nt!_EPROCESSWinDbg命令查看具体偏移对于跨版本问题实现自动偏移检测在回调函数中加入详细日志记得在开发过程中启用验证器Driver Verifier它能帮助及早发现许多潜在问题。我在项目中最常用的验证器选项是Special poolPool trackingForce IRQL checkingDeadlock detection8. 高级话题跨版本兼容性实现要实现一个能在多个Windows版本上运行的驱动处理EPROCESS结构差异是关键。这里分享一个我在实际项目中使用的技术 - 模式搜索ULONG FindImageFileNameOffset() { PEPROCESS SystemProcess PsGetCurrentProcess(); PUCHAR ProcessBytes (PUCHAR)SystemProcess; // System是系统进程的名称 CONST CHAR* TargetName System; SIZE_T NameLength strlen(TargetName); // 在EPROCESS可能范围内搜索 for (ULONG Offset 0; Offset 0x1000; Offset) { if (strncmp((PCHAR)(ProcessBytes Offset), TargetName, NameLength) 0) { return Offset; } } return 0; }这个方法的好处是不依赖固定偏移适应不同Windows版本不需要维护版本检测表当然它也有局限性依赖System进程的存在搜索范围需要合理设置性能不如硬编码偏移在性能敏感的场合我会实现一个混合方案首次加载时检测偏移并缓存后续调用使用缓存值加入验证机制防止缓存失效9. 安全注意事项与最佳实践在内核中操作进程需要格外注意安全以下是我总结的几个关键点权限检查在执行敏感操作前验证调用者权限if (SeSinglePrivilegeCheck(SeDebugPrivilege, CurrentProcess-PreviousMode)) { // 有足够权限 }内存验证访问用户模式内存前必须验证__try { ProbeForRead(UserBuffer, Length, 1); // 安全访问用户内存 } __except(EXCEPTION_EXECUTE_HANDLER) { return GetExceptionCode(); }引用计数正确处理对象引用PEPROCESS Process; NTSTATUS status PsLookupProcessByProcessId(ProcessId, Process); if (NT_SUCCESS(status)) { // 使用Process... ObDereferenceObject(Process); // 重要 }IRQL安全注意不同API的IRQL要求PsGetProcessImageFileName可在DISPATCH_LEVEL运行PsReferenceProcessFilePointer必须在PASSIVE_LEVEL运行在最近的一个项目中我们发现了竞争对手驱动中的一个漏洞 - 他们在DISPATCH_LEVEL调用了PsReferenceProcessFilePointer导致在某些情况下系统不稳定。这再次证明了遵循微软文档中IRQL要求的重要性。