Дампинг W32pServiceTable - PullRequest
       17

Дампинг W32pServiceTable

0 голосов
/ 27 января 2020

Я хочу посмотреть, какая функция в драйвере win32k.sys обрабатывает указанный c номер системного вызова. Я присоединяю windbg к процессу GUI, поскольку win32k.sys - это драйвер сезонного пространства. Затем я сдвигаю первое значение DWORD вправо на 4 бита, добавляю базовый адрес W32pServiceTable и использую команду u, чтобы показать функцию в WinDbg, но адрес недействителен. Я проверил KiSystemCall64, и он, кажется, делает то же самое.

!process 0 0 winlogon.exe
.process /p (PROCESS addr)
.reload

dd win32k!W32pServiceTable - screenshot Ответ: значение DWORD из таблицы загружается с этой инструкцией

movsxd  r11,dword ptr [r10+rax*4]

W32pServiceTable Значения DWORD имеют бит в позиции 31 установлено значение 1, поэтому movsxd устанавливает старшие 32 бита регистра r11 в 1, затем добавление r11 и базового адреса таблицы приводит к правильной функции.

1 Ответ

0 голосов
/ 28 января 2020

Эти значения являются отрицательными, поэтому вам нужно сохранить их при сдвиге битов. Например:

0: kd> dd win32k!W32pServiceTable L1
fffff88b`d1568000  ff8c8340
0: kd> u win32k!W32pServiceTable + ffffffff`fff8c834 L1
win32k!NtUserGetThreadState:
fffff88b`d14f4834 4883ec28        sub     rsp,28h

Кроме того, WinDbg очень требователен / странен / сломан / непредсказуем, когда дело доходит до расширения знака, поэтому вам нужно быть осторожным в том, как вы это делаете. Например, это не работает:

0: kd> u win32k!W32pServiceTable + fff8c834 L1
fffff88c`d14f4834 ??              ???

Из-за нуля WinDbg, увеличивающего значение. Но это так:

0: kd> u win32k!W32pServiceTable + (fff8c834) L1
win32k!NtUserGetThreadState:
fffff88b`d14f4834 4883ec28        sub     rsp,28h

Поскольку () заставляет WinDbg расширять знак вместо расширения ноль.

Наконец, это происходит даже на обычной служебной таблице, это не просто Win32k .

...