Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Вообще привязываться к конкретным адресам, если можно сделать иначе - не есть хорошо 30.07.03 09:34 Число просмотров: 1812
Автор: amirul <Serge> Статус: The Elderman
|
Вводная:
1) Любой процесс под NT-ями так или иначе импортирует kernel32.dll
2) Образ любого модуля впечатывается по границе страницы, если даже придется просмотреть ВСЕ страницы (а такого делать не придется, но все же), то всего в пользовательском адресном пространстве (0x00000000 - 0x80000000) есть всего 500000 страниц. То есть нужно проверить всего 500 тысяч коротких слов (сигнатуру для сравнения можно хранить в регистре и сравнивать сразу с памятью, указатель на которую хранить в другом). Причем делать это в коротком цикле, который полностью поместится в кеш-строку - задача не из самых сложных.
3) Образ любого модуля начинается с сигнатуры MZ (и кроме того там еще есть смещение к сигнатуре PE)
4) Формат PE-файла хорошо задокументирован и хранит в себе название модуля.
5) Образ большинства dll-ок (по крайней мере всех системных, так как они сделаны в VC, а его линкер собирает все именно так) имеет не одну, а две таблицы импорта. Одна заменяется при динамическом связывании, а одна остается оригинальной.
Если еще не понятно к чему я веду, то вот примерный алгоритм:
1) Начинаем постранично просматривать память на предмет сигнатуры MZ (лучше с конца и назад - там всегда много системных dll-ок)
2) Если найдена, проверяем еще и синатуру PE
3) Если и она присутствует, проверяем имя модуля. Если это kernel32.dll - находим адреса GetModuleHandle (адрес на имя kernel32.dll у нас уже есть :-) ) и getprocaddress (в принципе этого делать не обязательно - просто для облегчения дальнейшей жизни). Для этого нужно идти не по основной (измененной таблице импортов), а по второй - неизменной.
4) Если не kernel32 - возможны варианты. Либо продолжать планомерную проверку страниц с того места, где мы нашли этот модуль, либо использовать вторую таблицу импортов (большинство dll-ок тоже импортирует kernel32), либо (если dll-ка собрана в билдере и второй IAT нет) проверять в тех адресах, которые импортируются и искать назад. Или использовать комбинацию: если это VC-шная dll-ка со второй IAT - искать сразу по адресам модулей, если BC-шная - по адресам импортов можно быстро найти адреса модулей.
В общем успехов. Можешь конечно и не делать такого, но зато этот шеллкод будет универсальным.
|
|
|