информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыSpanning Tree Protocol: недокументированное применениеСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / hacking
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Вообще привязываться к конкретным адресам, если можно сделать иначе - не есть хорошо 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-шная - по адресам импортов можно быстро найти адреса модулей.

В общем успехов. Можешь конечно и не делать такого, но зато этот шеллкод будет универсальным.
<hacking> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach