|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
楼上得到函数地址的方法也可以
|
|
|
完全不懂
 NtReadFile是导出函数 直接就可以用的说。 再加上找到Base Address 自己实现一个KGetProcAddress貌似也不是难事~ 驱动中调用NtXX函数 貌似永远都是KernelMode。怎么也变不成UserMode~ UserMode 只有用过SysEnter 上下文切换才有这么回事奥。 反正2k3 sp1的代码大概是这个意思。 我没有看懂楼主想说什么的哦~~理解能力有限 读了三遍都没有看懂。。。
|
|
|
可能是我表达的不够清楚 不过楼上的认识也是有错误的 The NtXxxx version of the native system service is the name of the function itself. Thus, when a Kernel Mode component calls the NtXxxx version of the system service, whatever is presently set into previous mode is unchanged. Thus, it is quite possible that the Kernel component could be running on an arbitrary User stack, with the requestor mode set to User. The system service will not know any better, attempt to validate the request parameters, possibly using the credentials of the arbitrary User Mode thread, and thus possibly fail the request. Another problem here is that one step in the validation process for a User Mode request is that all passed in buffers have either ProbeForRead or ProbeForWrite executed on them, depending on the buffer’s usage. These routines raise exceptions if executed on Kernel Mode addresses. Therefore, if you pass in Kernel Mode buffers with your request mode set to User, your calls into the native API return STATUS_ACCESS_VIOLATION. 内核组件是可能运行在任意线程的上下文中的 在Nt*函数中会检查PreviousMode 而 这个PreViousMode从哪里来? 看Nt*函数的代码 PAGE:004990D8 ; NTSTATUS __stdcall NtReadFile(HANDLE FileHandle,HANDLE Event,PIO_APC_ROUTINE ApcRoutine,PVOID ApcContext,PIO_STATUS_BLOCK IoStatusBlock,PVOID Buffer,ULONG Length,PLARGE_INTEGER ByteOffset,PULONG Key) PAGE:004990D8 push 68h PAGE:004990DA push offset stru_418748 PAGE:004990DF call __SEH_prolog PAGE:004990E4 xor esi, esi PAGE:004990E6 mov [ebp+var_20], esi PAGE:004990E9 mov [ebp+var_34], esi PAGE:004990EC mov [ebp+var_70], esi PAGE:004990EF mov [ebp+var_6C], esi PAGE:004990F2 mov eax, large fs:124h ;内核态fs指向KPCR /* ;fs:120为KPRCB lkd> dt _kprcb nt!_KPRCB +0x000 MinorVersion : Uint2B +0x002 MajorVersion : Uint2B +0x004 CurrentThread : Ptr32 _KTHREAD ;fs:124 +0x008 NextThread */ PAGE:004990F8 mov [ebp+var_58], eax PAGE:004990FB mov al, [eax+140h] /* lkd> dt _kthread nt!_KTHREAD +0x000 Header : _DISPATCHER_HEADER +0x010 MutantListHead : _LIST_ENTRY +0x018 InitialStack : Ptr32 Void +0x01c StackLimit : Ptr32 Void ........ +0x140 PreviousMode : Char ;al =PreviousMode 我已经注释的很清楚了 Nt*会根据这个PreviousMode来判断调是否需要参数检查 而现在的问题就是如果我们调用的是Zw*函数的话 Zw*函数会把PreviousMode设置为KernelMode 然后再调用Nt*函数 因此在Nt*函数中就不会进行参数检查 而如果我们直接调用Nt*函数的话(it is quite possible that the Kernel component could be running on an arbitrary User stack, with the requestor mode set to User) ,我们必须自己将PreviousMode设置为KernelMode,否则PreviousMode很可能仍然是User , 这样的话 Nt*函数就会认为对它的调用来自用户态,从而做一些检查,这时就会产生问题了(不明白的话,再看一篇那段英文)......因此我们要自己调用Nt*的话必须先将PreviousMode设为KernelMode. 谢谢楼上的回复 对我的表达能力深表抱歉!!!! 楼上如果还有疑问 ,欢迎与我继续讨论....................:p |
|
|
|
|
|
|
|
|
要是这样子,需要分析下,如果是inline hook的话,那还是被监控了.所以,你可以先恢复inline hook, 本文说的是SSDT hook,如果有inline hook的话 的确需要先恢复inline hook. 但是不管有没有什么hook ,如果想直接调用Nt*的话 还是要先设置PreviousMode为Kernel的 而对于要定位函数的地址的话,也很简单,在内存里能够执行的是PE文件,你按照PE文件的格式去定 举一个例子 NtSetValueKey |
|
|
|
|
|
ntoskrnl.exe中导出了 ZwSetValueKey 而没有导出NtSetValueKey ...... 而我们现在想直接调用NtSetValueKey , 那么怎么才能得到NtSetValueKey的地址 ? 从现有的SST中得到的肯定是错误的(因为被ssdt hook了啊,正因为这样 所以我们才要直接调用Nt*函数的啊) 又因为NtSetValueKey没有导出 所以用MmGetSystemRoutineAddress的方法也是得不到NtSetValueKey的地址的 因此应该用以下方法 ntoskrnl导出了符号KeServiceDescriptorTable，通过该符号获取SST表的实际地址，将该地址的偏移转换为文件偏移，然后去打开硬盘上的 ntoskrnl.exe文件，通过刚才计算的文件偏移来读取原始SST表，再加上实际装载地址与预装地址的偏差即可 以上纯属个人理解,如有不对,请指教... 请问有在驱动中直接调用过Nt*函数吗 ? 成功率是多少 ? 至于为什么不成功 我在上面都说过了 ... 光靠个人理解是不行的 为什么不动手试一下呢 ? |
|
|
 楼上是我 登错帐号了 |
|
|
|
|
|
太深奥了
。。。。
|
|
|
|
|
|
|
|
|
通过Nt*构造自己的Zw* ?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
