hgy413的专栏

以下是自己分析dump的一些经验，个人之见系统蓝屏后，会先出来一个提示：也可以通过dump来看到:打开MSDN对蓝屏的说明：http://msdn.microsoft.com/en-us/library/windows/hardware/hh994433(v=vs.85).aspx找到0x19的说明：0×00000019 BAD_POOL_HEADER再找到参数1为

1.取得NTOS原始的地址：这个可以通过遍历系统模块，找到第一个被加载的模块（NTOS），获得NTOS的路径，基地址，大小：基本思路为：1.1 ZwQuerySystemInformation查询到所有模块1.2 获得NTOS的路径，基地址，大小代码如下：NTSTATUS GetNtosModuleInfo(WCHAR *pNtosPath,ULONG nSize,

以下仅针对32位系统，在XP下测试：以下是XP在ring3的调用方式:// xpntdll!NtReadFile:7c92d9b0 b8b7000000 mov eax,0B7h7c92d9b5 ba0003fe7f mov edx,offset SharedUserData!SystemCallStub (7ffe0300)7c92d9ba ff12 call

两者差别1.__STDCALL inline HOOK是针对整个函数的hook，好处是变量清楚,坏处时肯定只能在函数头hookNTSTATUS __stdcallNewNtQueryDirectoryFile( IN HANDLE FileHandle, IN HANDLE Event OPTIONAL, ....... )

原NTOS的IAT只能通过IMAGE_DIRECTORY_ENTRY_IAT（12）来获得，因为NTOS加载完后，INIT方式加载，所以IMAGE_DIRECTORY_ENTRY_IMPORT对应的区域被释放了！坑爹啊，可以用windbg很直观的看到：X86：x64:其他的IAT遍历代码如下：NTSTATUS EnumIATTable(ULO

SSDT 的全称是 System Services Descriptor Table，系统服务描述符表这个表就是一个把 Ring3 的 Win32 API 和 Ring0 的内核 API 联系起来。Ring3下调用的所有函数最终都会先进入到ntdll里面的typedef struct _KSERVICE_TABLE_DESCRIPTOR{ PULONG_PTR ServiceTab

正方案：把 EPROCESS->DebugPort = NULL清零，这样调试器就无法接受到消息了，也就无法调试了反方案：以下的操作都可以写成一个script来操作.debugport和哪些函数相关1.首先打开一个calc.exe：kd> !process 0 0 calc.exePROCESS 861a9020 SessionId: 0 Cid: 068c