Ядерные шалости

Крис Касперски ака мыщъх

Хакер, номер #091, стр. 091-082-6

КОД

Листинг 5: модифицированный boot.ini, предоставляющий возможность выбора ядер

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINNT

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINNT="W2K Pro" /fastdetect

multi(0)disk(0)rdisk(0)partition(1)\WINNT="W2K hacked" /fastdetect /kernel=ntoskrh.exe

При загрузке системы возникнет меню, предлагающее нам одно из двух ядер на выбор (см. рис .4)

Убедившись, что оба ядра исправно работают, удовлетворенные, мы начинаем хакерстовать. Открываем ntoskrnh.exe (альтернативное ядро) в hiew'е и вносим в него какие-нибудь несущественные изменения, например, находим последовательность 90h 90h (NOP/NOP) и меняем ее на 87h C9h (XCHG ECX,ECX), сохраняем изменения по <F9> и перезагружаемся…

Упс! Альтернативное ядро больше не грузится! Что ж, загружаемся с основного, ругая себя всякими интересными словами за то, что забыли пересчитать контрольную сумму. Даем команду «editbin /RELEASE ntoskrnh.exe» и перезагружаемся еще раз. Теперь альтернативное ядро работает как ни в чем не бывало, и первую строчку (с оригинальным ядром) из boot.ini можно смело убирать, чтобы загрузочное меню не появлялось при каждом запуске системы. Правда, при этом станет невозможна загрузка в безопасном режиме, поскольку Windows не вполне корректно поддерживает недокументированный ключ /kernel и путается в ядрах во всех нештатных ситуациях. В данном случае система упорно утверждает, что файл ntoskrnl.exe не найден, хотя он исправно присутствует на диске.

Ладно, проигрались и хватит! Попробуем ответить вот на какой вопрос: откуда драйвера узнают о факте переименования ядра? Ведь в их таблице импорта явно прописан ntoskrnl.exe, который (в случае альтернативного ядра) может вообще отсутствовать на диске, но тем не менее функции экспортируются/импортируются, и все работает, как кремлевские часы после путча. Волшебство, да и только!

soft-ice по команде «map32» показывает «ntoskrnl» (без расширения), а не «ntoskrnH», как этого следовало бы ожидать с точки зрения здравого смысла, тем более что в этом ntoskrnl присутствуют хакнутые нами байты 87h C9h. А вот PE-TOOLS с плагином Extreme Dumper «честно» сообщает полное имя файла ядра вместе с путем (см. рис. 8).

Кому из них верить? Вопрос далеко не риторический! Если мы хотим сравнить образ ядра с его файлом на диске (для обнаружения on-line patch'а, например), нам необходимо точно знать, к чему обращаться, иначе можно совсем не в тот лес забрести.

Ответ дает команда «mod» того же soft-ice, показывающая имя модуля ядра — ntoskenl.exe и соответствующий ему файл — ntoskrnH.exe (см. рис. 9). Весь фокус в том, что имена модулей не обязаны соответствовать именам файлов. И это относится не только к ядру, но и ко всем динамическим библиотекам вообще! При первой загрузке статической компоновкой или API-функцией LoadLibrary система находит файл на диске по его имени, а при загрузке уже загруженных модулей поиск идет в памяти, где в таблице экспорта непосредственно прописано, кто есть кто!