Драйвер ядра Windows (64) и постраничные функции

я написал инструмент C, чтобы немного возиться с ядром Windows. Теперь, как мы видим, в разделе «PAGE» есть несколько функций, что означает, что эти функции ядра могут быть выгружены. Я знаю их адрес, потому что могу прочитать в памяти PE-заголовок ядра Windows. (нестраничный, а также основной раздел .text).

Итак, вот мой вопрос: что мне нужно сделать, чтобы вызвать выгружаемую функцию ядра Windows (из моего драйвера). Точнее, что мне нужно сделать, чтобы убедиться, что функция в настоящее время загружена и находится в качестве исполняемой памяти? Я иногда получаю BSOD, когда эти функции выгружаются. Есть ли удобный способ сделать это? (вместо «MmProbeAndLockPages» для текстовой секции ядра под названием «PAGE»).

Подсказка: я не использую инструменты Windows. мне нужно сделать это на простом старом C (инструментарий MinGW)

С уважением, Майкл

./bin/asmdiff.exe info -s /cygdrive/c/Windows/winsxs/amd64_microsoft-windows-os-kernel_31bf3856ad364e35_6.1.7601.17514_none_ca56670fcac29ca9/ntoskrnl.exe 

Trying to get Information for file: /cygdrive/c/Windows/winsxs/amd64_microsoft-windows-    os-kernel_31bf3856ad364e35_6.1.7601.17514_none_ca56670fcac29ca9/ntoskrnl.exe...

BinaryFormat: PE_64

######### Dumping PE64-File sections: #########

Section 0: <.text> base:0x0000000140001000 len:1712881
Section 1: <INITKDBG▒9> base:0x00000001401A4000 len:14768
Section 2: <POOLMI> base:0x00000001401A8000 len:7197
Section 3: <POOLCODE base:0x00000001401AA000 len:11803
Section 4: <RWEXEC> base:0x00000001401AD000 len:4096
Section 5: <.rdata> base:0x00000001401AE000 len:252272
Section 6: <.data> base:0x00000001401EC000 len:603464
Section 7: <.pdata> base:0x0000000140280000 len:196824
Section 8: <ALMOSTRO▒> base:0x00000001402B1000 len:7664
Section 9: <SPINLOCK@> base:0x00000001402B3000 len:6464
Section 10: <PAGELK> base:0x00000001402B5000 len:85739
Section 11: <PAGE> base:0x00000001402CA000 len:2317806
Section 12: <PAGEKD> base:0x0000000140500000 len:19442
Section 13: <PAGEVRFY▒> base:0x0000000140505000 len:136619
Section 14: <PAGEHDLS▒'> base:0x0000000140527000 len:10199
Section 15: <PAGEBGFXLf> base:0x000000014052A000 len:26188
Section 16: <PAGEVRFB> base:0x0000000140531000 len:13312
Section 17: <.edata> base:0x0000000140535000 len:67960
Section 18: <PAGEDATA> base:0x0000000140546000 len:56576
Section 19: <PAGEVRFC)> base:0x0000000140554000 len:10526
Section 20: <PAGEVRFDP> base:0x0000000140557000 len:4688
Section 21: <INIT> base:0x0000000140559000 len:357788
Section 22: <.rsrc> base:0x00000001405B1000 len:221024
Section 23: <.reloc> base:0x00000001405E7000 len:8304

c windows kernel driver wdk
person mschmoock    schedule 26.01.2012    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Как правило, вам не нужно ничего делать, чтобы получить код страницы — менеджер памяти позаботится об этом за вас.

Однако, если код помечен как выгружаемый, это означает, что функция может быть вызвана только тогда, когда IRQL системы меньше DISPATCH_LEVEL. Таким образом, любой код, который вы хотите запускать с более высоким IRQL, не должен быть помечен как выгружаемый.

Вы можете динамически блокировать выгружаемый код с помощью MmLockPagableCodeSection() (см. http://msdn.microsoft.com/en-us/library/windows/hardware/ff554307.aspx), но я думаю, что такой уровень контроля, вероятно, нужен лишь в редких случаях.

Вы можете использовать Driver Verifier с «Принудительной проверкой IRQL», чтобы помочь более детерминированно определить, когда у вас есть код с возможностью подкачки, который вызывается с высоким IRQL.

person Michael Burr    schedule 26.01.2012
comment
Теперь у меня сработал MmProbeAndLock для раздела ядра. Я предполагаю, что MmLockPagableCodeSection также является способом. Я использую самый низкий IRQL. Но все же мне нужно ProbeAndLock, чтобы получить страницу. Если я этого не сделаю, система иногда возвращает мне читаемое мертвое пространство. Я также заметил изменение в поведении при подкачке ядра внутри виртуальной машины или хост-процессора. - person mschmoock; 30.01.2012