Шесть грехов malware-писателей


Грех5 — недокументированные возможности - часть 2


Очевидно, что ret передает управление по адресу, который был занесен в стек перед ним, то есть вызывает функцию fnFreeOrUnmap, которой в зависимости от версии Windows оказывается либо FreeLibrary, либо UnmapViewOfFile. Получив управление, функция смотрит на стек и думает: ага, "DeleteFile" это адрес возврата, а вот "module" — это мой аргумент. Освободив страничный образ, она передает управление по адресу возврата (на месте которого лежит адрес DeleteFile) и увеличивает значение указателя стека на 4 (размер переданных ей аргументов).

Получив управление, DeleteFile

смотри на стек и думает: ага, ExitProcess – это адрес возврата, а вот "push eax" — мой аргумент с именем файла, которая я должна удалить! (и ведь удаляет, поскольку модуль к этому времени уже освобожден).

Следующей (и последней) управление получает функция ExitProcess, завершающая выполнение программы, которой уже нет.

 

Рисунок 9 файл, удаляющий себя сам

Элегантно, не правда ли?! Никаких тебе временных bat-файлов и прочей дисковой активности (которую, кстати, могут заметить всякие недружелюбно настроенные мониторы). Но! Разве кто-нибудь гарантировал нам (документация или лично Билл Гейтс), что UnmapViewOfFile

позволяет освобождать образ exe-файла? На NT и W2K это работало лишь потому, что ядро хранило ссылку на обработчик объекта-секции (не путать с секциями PE-файла) и UnmapViewOfFile послушно его освобождало. Начиная с XP ядро обращается к обработчику секции через указатель, обламывая вызов UnmapViewOfFile, а вместе с ним весь наш кайф.

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




- Начало -  - Назад -  - Вперед -



Книжный магазин