Hi guys I am wondering how useful this program would be to you guys. People are using debuggers to find out where a sysenter with a certain eax value is going to end up going. But after spending a little time in NTOSKRNL.exe I discovered how easy it was to use global memory pointers (FFDFF000) to get the tables. The 2 tables are actually stored in NTOSKRNL.EXE and WIN32K.SYS. If you guys want the program I will post it. I am hoping to find a way to get the named entries for the entire table as in what API call(user32, kernel32, gdi32, etc) invokes it. Discovering the names of the target calls is unfortunately not possible as the symbolic information I have was not thorough enough and only had some names. Or IDA is being flakey. We will see though. So if you guys want it I will post it its quite small. Its developed completely on XP and I am pretty sure it should work on 2k as well but I would need testing.

Snatch

Maybe check this out: http://www.cmkrnl.com/arc-newint2e.html from 1998.

Thanks a million. Now I scrap that project. That was precisely what I wish I had previously. Thanks again.

Snatch

I hope snatch isn't trying to take credit for stuff I wrote (and on 2k, not XP). In case anybody is interested, here is a KMD for reading arbitrary MSRs, and a loder that uses it to read MSR 0x176, aka the SYSENTER_EIP_MSR. About a days work, since it's my first KMD. Shouldn't crash, but as always, sync.exe.

Have fun.

Be careful as trying to access invalid MSRs will raise a GPF - I could not find where you were handling that case. For a proper implementation you can take a look at Winice and IceDump's /RDMSR and /WRMSR commands.

Ah yes, seems like I deleted the exception handler - I had it in some test code, forgot to add it to the final.

Nah f0dd I am taking a completely different approach. I never need to call rdmsr. You can use pointers in global memory to track down the tables the two of them actually. Then I found out its really simple you disassemble win32k.sys and ntoskrnl.exe and theres a table of functions in both and those are the msr values for given eax values. Very simple. No need to bother with using global memory tricks to get the pointers to the tables. 0xFFDFF000 contains useful stuff though. Check the DDK for more .

Snatch

f0dd your program is useful to get the actual MSR value though . However if you just want to find out where a certain eax value lands no real need to use a debugger. Just disassemble the aforementioned files. And find the tables they arent hard to find either. I believe 0 is the start of ntoskrnl.exe and 0x1000 is the start of win32k.sys table. Anyway actually debugging the resultant call is messy. I just figured out what I was doing wrong .

Snatch