трабл с обработкой sysenter

всем привет.
я перехватываю обработчик sysenter'a вот так :

Код (Text):

1. VOID
2. installhook(){
3.     __asm mov ecx, 0x176
4.     __asm rdmsr
5.     __asm mov d_origKiFastCallEntry, eax
6.     __asm mov eax, MyKiFastCallEntry
7.     __asm wrmsr
8. }

и обрабатываю :

Код (Text):

1. static
2. _declspec(naked)
3. ProcessSyscall(ULONG num){
4.     DbgPrint("sysenter called\n");
5. }
6.  
7. static
8. _declspec(naked) MyKiFastCallEntry(){
9.     __asm pushad
10.     __asm pushfd
11.     __asm push fs
12.     __asm push ds
13.     __asm push es
14.     __asm push 30h
15.     __asm pop fs
16.     __asm call ProcessSyscall
17.     __asm pop es
18.     __asm pop ds
19.     __asm pop fs
20.     __asm popfd
21.     __asm popad
22.     __asm jmp d_origKiFastCallEntry
23. }

но не могу понять, почему этот код бсодит. если вместо дбгпринта ставить просто ret то все отлично. но стоит сделать колл на любую АПИ, как система слетает. что я не учел ?
бсод обычно либо такой :

BugCheck F7, {49, bb40, ffff44bf, 0}
либо тестовая система (win 2003 sp1) виснет так что даже не брякается по команде из windbg

 

в ProcessSyscall было бы неплохо поставить return; в конце

 

patolog
пачемушта. Маны внимательно читать надо.
xor edx,edx кто делать будет ?

 

k3internal
при чем тут. ты про rdmsr / wrmsr ? так они ж подряд идут

 

подредактировал маленько ога.
в аттаче проэкт полный.

Код (Text):

1. static
2. _declspec(naked)
3. ProcessSyscall(ULONG num){
4.     DbgPrint("sysenter called\n");
5.     __asm ret;
6. }
7.  
8. static
9. _declspec(naked) MyKiFastCallEntry(){
10.     __asm pushad
11.     __asm pushfd
12.     __asm push fs
13.     __asm push ds
14.     __asm push es
15.     __asm mov dx, 0x30
16.     __asm mov fs, dx
17.     __asm call ProcessSyscall
18.     __asm pop es
19.     __asm pop ds
20.     __asm pop fs
21.     __asm popfd
22.     __asm popad
23.     __asm jmp d_origKiFastCallEntry
24. }

чета не цепляет аттач...
http://slil.ru/25301342

 

Чооорт, заюзай уже

Код (Text):

1. __asm {
2. code
3. code
4. code
5. }

 

зачем. в этом трабл ?

 

неужели вопрос настолько тупой что даже отвечать не хочется ? (с)

 

patolog
+1 тоже очень интересен этот вопрос

 

Для разнообразия попробуй фильтровать отдельную ф-ию..

 

пробовал. пробовал смареть что в ЕАХ, е если там был номер ф-ции ZwClose то дбгпринтил... но всеравно БСОД.
причем сначала в дебагере появлялся принт, а потом бсод.

 

patolog
проблема cкорее всего в стеке
sysenter изменяет ESP, но это значение не определяет стек ядра текущего процесса
его еще надо получить
вызов сторонней функции может требовать стек ядра процесса, но т. к ESP невалиден, получаем BSOD
этим можно объяснить нормальное выполнение кода в случае, если сторонняя функция ядра не вызывается
http://www.wasm.ru/forum/viewtopic.php?pid=187193#p187193

 

Странно.Попробуй так.Это работает на XP SP2 и скорее всего будет работать и у тебя.

Код (Text):

1. new_SysCall:
2.                 pusha
3.                 pushf
4.                 push    fs
5.                 push    ds
6.                 push    es
7.                 mov     ax, 30h
8.                 mov     dx, 23h
9.                 mov     fs, ax
10.                 mov     ds, dx
11.                 mov     es, dx
12.                 mov     edx, large fs:124h
13.                 mov     edx, [edx+44h]
14.                 push    edx
15.                 push    offset Format            ; "eprocess %X",0
16.                 call     DbgPrint
17.                 add     esp, 8
18.                 pop     es
19.                 pop     ds
20.                 pop     fs
21.                 popf
22.                 popa
23.                 jmp     old_SysCall

А вот если захочешь добраться до стека,придется сделать как советует rei3er :

Код (Text):

1. ;
2. ; When we trap into the kernel via fast system call we start on the DPC stack. We need
3. ; shift to the threads stack before enabling interrupts.
4. ;
5.         mov     ecx, PCR[PcTss]        ;
6.         mov     esp, [ecx]+TssEsp0

З.Ы. А кто знает,как можно заставить KiFastCallEntry вернуть управление в драйвер [чтобы узнать результат ф-ии] а не выйти в r3 по sysexit?

 

TheDeath
У меня такой код на SP2 блюскринит. Если сделать DbgPrint один единственный раз, то система просто перегружается.

Другой вопрос - допустим хочу сделать другой обработчик для некой функции API. Как можно поставить jmp NewApiFunc? Пробовал всякие варианты - результат один - Blue Screen. Судя по всему обработчик sysenter делает еще что то (?)

 

смотреть, каким образом и где KiFastCallEntry
сохраняет адрес возврата
кроме того, для успешного перехвата sysexit целевой код должен быть отображен на адресное пространство ядра через PTE c установленным битом U
либо можно модифицировать дескриптор PF в IDT

 

у меня на сп2 код бсоданул тоже.
интересен еще вот какой факт.
узнаем адрес оригинального диспатчера. палим дизасм по адресу, видим
mov ecx, 0x00000020 //5 байт
и в своем диспатчере делаем :

Код (Text):

1. new_SysCall:
2.  mov     ecx, 0x00000020
3.  jmp      old_SysCall+5

и получам бсод(

 

patolog
дизасм точно правильный?

 

да, я смарел в виндбг, а сверял с оригинальным сорсом

Код (Text):

1.         PUBLIC _KiFastCallEntry2
2. _KiFastCallEntry2:
3.  
4. ;
5. ; Sanitize the segment registers
6. ;
7.         mov     ecx, KGDT_R0_PCR
8.         mov     fs, ecx
9.         mov     ecx, KGDT_R3_DATA OR RPL_MASK
10.         mov     ds, ecx
11.         mov     es, ecx

 

katrus
Странно.Тогда почему у меня работает? В аттаче дров на скорую руку.Запускай dbgview в vmware и смотри.При остановке с вероятностью 1/3 bsod.Понятно,почему

rei3er
Это понятно,но какой извращенный способ.
В зависимости от MmUserProbeAddress адрес возврата через sysexit в ntdll или опять в ядро.

Пока решил эту проблему сплайсингом в сам KiFastCallEntry

Код (Text):

1.     mov     esi, edx
2.     mov     ebx, [edi]+SdNumber
3.     xor     ecx, ecx
4.     mov     cl, byte ptr [ebx+eax]
5.     mov     edi, [edi]+SdBase
6.     mov     ebx, [edi+eax*4]
7.     sub     esp, ecx
8.     shr     ecx, 2                                ; jmp в мой драйвер, и оттуда уже в kss60
9.     mov     edi, esp
10.     cmp     esi, _MmUserProbeAddress
11.     jae     kss80
12. KiSystemServiceCopyArguments:
13.     rep     movsd
14. ;
15. ; Make actual call to system service
16. ;
17. kssdoit:
18.     call    ebx                     ; call system service
19. kss60:

 

хм..) у меня лично на ХР сп2 и вин 2к3 бсоднуло)

Код (Text):

1. DRIVER_OVERRAN_STACK_BUFFER (f7)
2. A driver has overrun a stack-based buffer.  This overrun could potentially
3. allow a malicious user to gain control of this machine.
4. DESCRIPTION
5. A driver overran a stack-based buffer (or local variable) in a way that would
6. have overwritten the function's return address and jumped back to an arbitrary
7. address when the function returned.  This is the classic "buffer overrun"
8. hacking attack and the system has been brought down to prevent a malicious user
9. from gaining complete control of it.
10. Do a kb to get a stack backtrace -- the last routine on the stack before the
11. buffer overrun handlers and bugcheck call is the one that overran its local
12. variable(s).
13. Arguments:
14. Arg1: d7171430, Actual security check cookie from the stack
15. Arg2: 0000bb40, Expected security check cookie
16. Arg3: ffff44bf, Complement of the expected security check cookie
17. Arg4: 00000000, zero