Чтение KeServiceDescriptorTable для взаимодействия между ядром и пользовательским режимом"

Спасибо большое, я разобрался, теперь всё работает правильно

 

Добавь больше логов в код, чтобы отслеживать значения переменных и состояние программы на разных этапах выполнения

 

Что-то на скрине OriginalEntry не похож на действительно настоящий адрес: он в нижней половине адресного пространства (считай, в юзермоде) и не выровнен - проще говоря, ты получил адрес не SSDT, а какой-то мусор, и по этому мусорному адресу что-то записал.

Не используй эвристику для поиска, возьми смещение из отладочных символов.
Например, через DbgHelp: или напиши сам, или возьми что-то готовое.

 

Ссылка на таблицу может не быть в коде, так например в этой версии используется смещение ссылки в обьекте, те KTHREAD.ServiceTable.

Другие разновидности(версии) ядра используют иную структуру сервисных таблиц, например IUM?

Вот даже формула имеется:

Код (Text):

1. RoutineAbsoluteAddress = KiServiceTableAddress + (routineOffset >>> 4)

- нужно учитывать дополнительно флаги в номерах/смещениях(тип хэндлера, наличие аргументов в памяти).

Линейный сигнатурный поиск в памяти конечно же чепуха, как минимум нужно покрыть всю процедуру(флоу), иначе это хардкод.

Можно ли такое решить универсально

Пусть имеется некоторый механизм вызова хэндлера. Как определить в динамике ссылку или ее компоненты(смещение) в памяти ?

Если это код не ядерный, то такое в принципе можно сделать(снять трассу и дфлоу). Но как быть с механизмом, который нельзя прерывать или формирующий фреймы прерываний как данный