SYSENTER hook
 

in 2k, i have a table of interupt handler pointers which can easily be modified, but what about xp and SYSENTER?

should i setup a new handlerproc through WRMSR and SYSENTER_CS, SYSENTER_ESP, ..?

does anybody have a codesnipped for this?

thxalot

hi, niom,

Yes! on a theorethical point of view you are right. In the same way one replaces INT 3 handler with a preamble (e.g. for tracing purposes) and then jumps to the old handler, the same guy on Windows XP must replace MSR register 176 (EIP) - which points currently at KiFastCallEntry - with some preamble and then jump to KiFastCallEntry.
You only need to write a kernel driver very similar to that which replace the INT 2E handler. Look for example at the code by sinister (http://www.xfocus.net/articles/200303/499.html).
Obviously you can always hook single system services.

But if you look more deeply at Windows XP architecture, you will find that:

(a) the fuc.ed SYSENTER is in userland (even if in read-only memory, and you cannot use WriteProtect on it to make it writeable because the address (0x7FFE0300) is outside the VadRoot of all the processes)

(b) on AMD processor there is no SYSENTER but INT 2E

So, we can replace SYSENTER with INT 2E and use the same tools we have for Windows 2K, don't we?

In fact after many reboots I finally manage to change on the fly the two ways to enter system services, from SYSENTER to INT 2E and vice versa, and all this without any driver involved!

It is as simple as replacing
with
with some little trick to avoid system crash

Maybe a tutorial... but bilbo has a lot of things to write and maybe nobody is interested... who knows...

Best regards, bilbo

k
thx


but i have a new question:

do you think, it is possible to "instrument" all ntoskrnl exports like detours does? (detours inserts a jump at the function entry, that points to a custom trampoline, which calls the old code: http://research.microsoft.com/~galenh/Publications/HuntUsenixNt99.pdf)

or do you know an easier way to intercept ring0->ring0 calls?

just done driver to revert back to INT2E from SYSENTER..

i'm interesting about SP2 NTOSKRNL.EXE..
also code on 7FFE0300h on AMD machines..

at Woodmann.com posted..

to bilbo:

AMD very well has own "SYSENTER-SYSEXIT":
SYSCALL 0F05h
SYSRET 0F07h

exactly about this i'm interesting:
do someone see usage of these on AMD at 7FFE0300h?

Well done, evaluator!
The trick I told before is just avoiding to copy the INT 2E snippet on top of SYSENTER snippet: in this way you would fuck all the pending system calls!
You are copying it at a displacement of 16 bytes: good.
You have also done a lot of checks... even address FFDF0300 (which is the same physical memory as 7FFE0300), SYSEXIT(at KiSystemService), the code inside KiSystemService (which force you to detect eventually softice) and two times the SYSENTER snippet... but better sure than unsure...

I found also it is not necessary to patch KiSystemCallExitBranch from 7506 (jnz KiSystemCallExit2) to 7505 (jnz KiSystemCallExit).

No, my experiments were done on a rather old AMD K6 and there INT 2E was used.

niom: it looks like you are interested to ring0 detouring. This is for you: http://www.rootkit.com/newsread.php?newsid=152
It comes with nice code too

Regards, bilbo


Edited for evaluator...
Regarding ring0 detouring suggestion, it was for niom, as I wrote, not for you...
Regarding 9th post: look where I posted the answer, and look to my previous posts, please...
Regarding SYSEXIT patching... I have posted on WOODMANN a snippet which does not patch anything more than necessary...
Please don't be so aggressive... We are here to learn, not to flame each other
Best regards!

P.S. only 3 addresses for phys 41000? or 4? Do PHYS 41000 and you will know!!!

>>it looks like you are interested to ring0 detouring
nope.

>>I found also it is not necessary to patch KiSystemCallExitBranch
>>from 7506 (jnz KiSystemCallExit2) to 7505 (jnz KiSystemCallExit).

verry nessesary:) remember, why we are replaicing pair SYSENTER-SYSEXIT
by INT-IRET!?

(that will your 9th power post~:)

another Q: there is III virtual address for 41000, wich is!? :)

Hey guys, I've found some info about SYSENTER and int 2e at ElicZs website... here is the txt :)

http://www.anticracking.sk/elicz/infos/FastNTCALL.txt

Hopefully you guys can use this to gain some knowledge :p

Wow, and it was only written four years ago. Where has it been hiding? :rolleyes: Oh yah. In plain sight.

Regards,

common, bilbo, vhere you sow aggrressionn!?
we'r juZt fun creckerz~~:)

JMI, & in that time reversers was trying change to SYSENTER,
while we are triing BACK TO Fu..

AMD also uses SYSENTER
 

evaluator,

On an AMD this is what I get (XP SP1):

This is the rest of the code, but it isn't called:
And here's a sample call

Seems that the same instruction is used as in Intel, not the 0F05 variant...

Here's the cpu info before you say it's a pentium :)

Strace
 

www.bindview.com/Support/RAZOR/ Utilities/Windows/strace_readme.cfm

"Official" FastCall disabling
 

While looking at "ntoskrnl.exe", I just found another way to disable the SYSCALL/SYSENTER stuff and revert to the old INT 2E.

Go to HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel and create an entry named "FastSystemCallDisable" with a DWORD value of 1.

This isn't an "on-the-fly" solution, you must reboot to make it active, so I guess the posted driver will be more handy if it works for you. Unless you don't mind having your machine permanently configured for INT 2E, that is.
Still this seems to be an officially supported flag, it shouldn't stop working when you apply an SP or hotfix.

To find the code in ntoskrnl, search for the unicode text "FastSystemCallDisable". It's referenced in a table of key names and memory locations. The loc associated with that variable is then referenced in the routine that checks the processor capabilities and sets up the ring3/ring0 transition. It will end up writing the chosen stub to the 0xFFDF0300 offset which seems to be the KM equivalent to 0x7FFE0300 in user mode.

Hi, instead of looking for ways to hook int 2E or sysenter/exit, you should consider hooking the function ptr table after this system service stub. Check the kernel api spy example published by Shreiber in his "Undocumented windows 2000" book.

The idea is to find out the KiServiceTable (exported by w2k and xp) and one of its member points to this function ptr table. You probably need a good kernel device driver to accomplish this task though.

Have fun :)