Запись в ядро

Добрый день! Подскажите что не так.
Я пытаюсь изменить код ф-ции NtQuerySystemInformation путем модификации кода в ядре. Т.е. если под IDA код ф-ции NtQuerySystemInformation выглядит так:

push 210h
push offset unk_4132F0
call sub_40BA92
xor eax, eax
mov [ebp-1Ch], eax
mov [ebp-24h], eax
mov [ebp-4], eax
mov eax, large fs:124h

то после так:

push 210h
push offset unk_4132F0
call sub_40BA92
mov eax, <адрес>
jmp eax
xor eax,eax
nop
nop
mov eax, large fs:124h

jmp <адрес> совершает прыжок на код моей ф-ции, кот находится в моем драйвере:

__asm {

int 03h

xor eax,eax
mov [ebp-1Ch], eax
mov [ebp-24h], eax
mov [ebp-04h], eax

mov eax,<адрес>
jmp eax

}


Проблема в том что после загрузки в память драйвера и после пропачивания им ядра, система при вызове NtQuerySystemInformation - выдает BSOD ... В чем трабла ? Под SoftIce когда я смотрел код, jmp нормально переходит на мою ф-цию, и из нее без проблем возвращается обратно.

 

!analyze -v

 

Сделал, вот что он мне выдал:

Код (Text):

1. KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
2. This is a very common bugcheck.  Usually the exception address pinpoints
3. the driver/function that caused the problem.  Always note this address
4. as well as the link date of the driver/image that contains this address.
5. Some common problems are exception code 0x80000003.  This means a hard
6. coded breakpoint or assertion was hit, but this system was booted
7. /NODEBUG.  This is not supposed to happen as developers should never have
8. hardcoded breakpoints in retail code, but ...
9. If this happens, make sure a debugger gets connected, and the
10. system is booted /DEBUG.  This will let us see why this breakpoint is
11. happening.
12. Arguments:
13. Arg1: 80000002, The exception code that was not handled
14. Arg2: 806467bf, The address that the exception occurred at
15. Arg3: f7bb574c, Trap Frame
16. Arg4: 00000000
17.  
18. Debugging Details:
19. ------------------
20.  
21.  
22. EXCEPTION_CODE: (HRESULT) 0x80000002 (2147483650) - <Unable to get error code text>
23.  
24. FAULTING_IP:
25. nt!ExRaiseDatatypeMisalignment+a
26. 806467bf c3              ret
27.  
28. TRAP_FRAME:  f7bb574c -- (.trap 0xfffffffff7bb574c)
29. ESP EDITED! New esp=f7bb5afc
30. ErrCode = 00000000
31. eax=80564737 ebx=8057cc27 ecx=00000003 edx=00a4fbe4 esi=8057cc27 edi=80564737
32. eip=806467bf esp=f7bb57c0 ebp=f7bb5b08 iopl=0         nv up ei pl nz na pe nc
33. cs=0000  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00000206
34. nt!ExRaiseDatatypeMisalignment+0xa:
35. 806467bf c3              ret
36. Resetting default scope
37.  
38. CUSTOMER_CRASH_COUNT:  4
39.  
40. DEFAULT_BUCKET_ID:  CODE_CORRUPTION
41.  
42. BUGCHECK_STR:  0x8E
43.  
44. PROCESS_NAME:  svchost.exe
45.  
46. LAST_CONTROL_TRANSFER:  from 80565fda to 806467bf
47.  
48. STACK_TEXT:  
49. f7bb5afc 80565fda 00a4fbf4 f7bb5b1c 8057cc7c nt!ExRaiseDatatypeMisalignment+0xa
50. f7bb5b08 8057cc7c 8057cc27 80564737 00000004 nt!ProbeForWrite+0x54
51. f7bb5b1c f7bb5d64 00a4fbf4 8057cc27 80564737 nt!NtQuerySystemInformation+0x51
52. WARNING: Frame IP not in any known module. Following frames may be wrong.
53. f7bb5d4c 804df06b 00000002 00a4fc00 00000138 0xf7bb5d64
54. f7bb5d4c 7c90eb94 00000002 00a4fc00 00000138 nt!KiFastCallEntry+0xf8
55. 00a4fbd8 7c90e1b6 7c81f1dc 00000002 00a4fc00 0x7c90eb94
56. 00a4fd8c 75267d7c 00a4fda0 00a4fe94 00000001 0x7c90e1b6
57. 00a4fdc0 762cbe65 00000000 76290000 00000000 0x75267d7c
58. 00a4fe44 762cc12f 01944eb8 5a8f1b08 00000000 0x762cbe65
59. 00a4fe68 5a8f754d 01944eb8 5a8f1b08 00000000 0x762cc12f
60. 00a4feb0 5a8f6882 00000001 00a4ff2c 00000000 0x5a8f754d
61. 00a4fef4 5a8f6f6e 00000004 00a4ff2c 5a8f732c 0x5a8f6882
62. 00a4ff14 5a8f6c59 5a8f182c 00000001 000c8128 0x5a8f6f6e
63. 00a4ff6c 010011cc 00000001 000c8128 00000000 0x5a8f6c59
64. 00a4ffa0 77ddb48b 00000001 000c8128 0007e898 0x10011cc
65. 00a4ffb4 7c80b50b 000c8120 00000000 0007e898 0x77ddb48b
66. 00a4ffec 00000000 77ddb479 000c8120 00000000 0x7c80b50b
67.  
68.  
69. STACK_COMMAND:  kb
70.  
71. CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
72.     8057cc36-8057cc40  11 bytes - nt!NtQuerySystemInformation+f
73.     [ 33 c0 89 45 e4 89 45 dc:b8 80 92 b4 f8 ff e0 33 ]
74. 11 errors : !nt (8057cc36-8057cc40)
75.  
76. MODULE_NAME: hideprocess
77.  
78. IMAGE_NAME:  hideprocess.sys
79.  
80. DEBUG_FLR_IMAGE_TIMESTAMP:  485bb051
81.  
82. FOLLOWUP_NAME:  MachineOwner
83.  
84. MEMORY_CORRUPTOR:  PATCH_hideprocess
85.  
86. FAILURE_BUCKET_ID:  MEMORY_CORRUPTION_PATCH_hideprocess
87.  
88. BUCKET_ID:  MEMORY_CORRUPTION_PATCH_hideprocess

 

что лежит по "<адрес>" ?

 

он эе написал в первом посте. из функции вырезается кусок независимый и выносится отдельно вместе с int3.
остальное связывается джампами.

 

Chameleon
Может быть, ebp меняется? Судя по "__asm", это ассемблерная вставка в Сишную процедуру, так вот: не вставил ли компилятор перед твоим кодом отсебятину типа "push ebp/mov ebp,esp"?

 

я имел ввиду второй <адрес>.
как правильно заметил diamond компилятор может вставлять пролог и эпилог, да и как возвращается управление непонятно.

 

я так понял, что продолжение функции отсюда

 

Chameleon

При хуках в ядре это нельзя делать(черезжопный способ).

 

Сорри, что немного не в тему.

А как лучше, если не секрет, если на стадии компиляции <адрес> еще не известен, и сам этот код должен быть базонезависим ( я что-то ничего не могу придумать другого)?

 

call sub_40BA92
Из этого надо исходить - атомарная модификиция смещения на хандлер.

 

Сенкс, кажется понял.

 

diamond, спасибо! Действительно, компилятор вставил пролог ... и jmp из кода ядра осуществлялся прямо на него ... Проверил это с помощью SoftIce поставив int3 перед jmp на свой код из ядра ...