KiSystemService中应该可以吧～

KiSystemService函数退出前的sysenter是海平线。上面是天堂，下面是地狱。感觉处理起来非常烦琐。即使能够得到ring3的调用堆栈，把地址翻译成模块加偏移量或者模块函数加偏移量也是一个并不轻松的任务。像我等喜欢吃现成饭的懒人，不做也罢。不过感觉还是直接执行RDMSR指令去esp更容易些。
  如果inline hook KiSystemService下面指令
popfd
pop ecx
sti
sysexit
iretd
在sti之前插入备份相关指令并拦截代码，此时ecx 存放的即为ring3 的esp,但是此时的syscall的索引号，却不知去向。

慢慢搞～我的xxx采用了一个很poc的方法貌似可以获取到～嘿嘿～

KiSystemService进入时好像可以取得啊～～

KiSystemService传入的call的参数可是xx的地址～xx的地址啊～～

提示：KiSystemService中的edx有点用啊～

syscall:
lea ecx,xxxxxx
mov edx,esp
sysenter
进入ring0

然后
mov ebx,[eax*4+edi]
....
call ebx

是有一个基地址和索引，但是执行到
sti
sysexit
iretd
返回ring3
寄存器的值已经发生变化，物是人非。如果在前面拦截的时候，保存edi、eax和ebx，但是频繁调用的syscall会不会乱序。
跟踪调用堆栈很有用，比如我想在拦截KeQuerySystemInforation class=5(查询进程信息)，根据调用堆栈来判断究竟是那个模块或者驱动在调用。如果是微软提供的dll或者sys，可以放行，其他的，对不起。这样至少可以排除一些程序通过loadlibrary ntdll，直接调用本机API。

有edx就可以研究谁拉～

edx 十有八九指向ntdll.dll地址空间。

引用第28楼guaiguaiguan于2007-11-22 15:14发表的  :
edx 十有八九指向ntdll.dll地址空间。

mov edx,esp
edx指向是参数栈，在参数栈上每0x4长达1K页上做dll query至少可以命中一个非系统的xxx