Восстановить SDT

потому что мелкомягкие жлобы =\

пример - ZwLockVirtualMemory. В ntdll там шлюз в ядро, а в экспорте ядра её нету. Наверное МС полагали - как хотите, так и ищите, мы ничего не знаем :P

 

Тогда какой выход? Стоит ли вообще анализировать директорию экспорта? Доп. надежность для обнаружения перехвата это, очевидно, даст. Но только для тех функций, которые мелкомягкие описАли.

Ок. Тогда как иначе? KiST в файле неинициализирован. Что тогда делать?

Кстати, кому не жалко, поделитесь структурой KiST. Также буду оч благодарен за линки по теме (KiST).

Нахождение KiST по сигнатуре, что предложил 90210, неинтересно.

 

IceFire
по-видимому, альтернатив все же нет...

 

Уважаемые дзенствующие, вопрос остается открытым. Высскажите, если не трудно, свои мысли по теме (см. мой предпоследний пост).

 

как еще можно найти то, что не экспортируется?? только поиском...

 

А чем, собственно, плох сигнатурный поиск? Весьма надежный метод.

 

в следующей версии может будет чуток другое начало функции и твоей сигнатуре кранты, если она этого не учтет. А если она будет очень "расплывчатая", то можно найти совсем не то, что надо. Тут надо осторожно вообщем) В умелых руках это нормальный метод.

 

Вообще-то метод 90210 можно назвать "сигнатурным поиском" с натяжкой. Его метод использует информацию о релоках. Вот частичный перевод:

Так что, этот метод очень надёжный, и не сработать он может, только если код ядра очень сильно изменится или защита, скажем, изменяет таблицу экспорта.

P.S. Я думаю, руки кодера 90210 можно назвать умелыми

 

IceFire
<Тада вопрос. Как определить что есть ядро? Хоть базу, хоть имя - не важно.

Имеем следующее:

1. Номер следования может быть любым.
2. Имя образа может быть любым.
3. Функции могут быть перехвачены заменой адреса в SDT.

Как искать оригинальные адреса?>

Посмотри по базовому адресу модуля. В кернелмемори первый модуль как раз таки всегда ядро)). Всё просто. В списках можно гадить как угодно в принципе, учитывая то, что они используются диспетчером ввода-вывода для загрузки-выгрузки драйверов. Но есть один опасный момент. Эту информацию использует ф-я ZwQuerySystemInformation. Соответственно её вызывающий тоже может получить неверные данные. Хрен с ним если в списках вы поменяете путь до модуля, но если его базовый адрес, могут возникнуть проблемы. Поскольку при загрузке очередного драйвера загрузчик берёт из списка базу требуемого модуля и заполняет iat драйвера, или как там по науке. Так шо, основной метод - поиск по базовому адресу модулей.

 

пока это будет работать с достаточно высокой вероятностью, но в скором будущем, возможно, придется искать другие способы..
возможно, уже в висте.. у кого стоит, кстати? там базовые адреса еще не вычислются каждый раз случайным образом?

 

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

 

Не осилил прочитать все сообщения, но вот вопрос по первому сразу. Если требуется всего лишь узнать что функция перехвачена или нет, то не проще ли просто посмотреть адрес какого модуля там стоит, если не адрес ядра, то естественно заменили.

 

ну и? а тут че сложные вещи разве рассказывают?

 

А тут разговор уже ушол как их восстановить. Как считать реальные значения из файла.

 

Еще один вопрос...как считаете, KiST на диске во всех ядрах кончается элементом 0x90909090?

 

=\ это же компилятор для выравнивания NOP'ы пихает..

 

=( т.е. опираться на это значение нельзя при обработке KiST? смотрел в ИДЕ ядро, там есть константа с кол-вом сервисов ядра, но ее снова нужно искать на каждом ядре отдельно =(