Умри, но сейчас

КРИС КАСПЕРСКИ АКА МЫЩЪХ

Спецвыпуск: Хакер, номер #070, стр. 070-076-3

Другой тонкий момент — иконка. Голый исполняемый файл, изображающий из себя «стандартное приложение Windows», привлекает к себе намного больше внимания чем... морковка. Или редиска! Да что угодно, только лучше не из стандартного набора значков, входящих в состав Microsoft Visual Studio — опытным пользователем они хорошо известны. Надежнее взять что-то совершенно неожиданное, тут все от воображения и фантазии зависит.

[4 дата создания файла.]

Штатным образом Windows поддерживает три даты, связанные с каждым файлом — дата создания, дата модификации (доставшаяся ей в наследство от MS-DOS) и дата последнего доступа. При создании файла на диске ему автоматически присваивается текущая дата создания, что позволяет легко изобличить непрошеную заразу. Просто заходишь в каталог WINNT\System32 своим любимым FAR'ом, жмешь <CTRL-F8> и файлы, созданные последними, оказываются наверху...

Умная малварь поступает так. Она считывает время создания KERNEL32.DLL (или любого другого системного файла Windows) и вызывает стандартную и притом документированную API-функцию SetFileTime, чтобы хоть как-то замаскироваться.

ЛИСТИНГ

прототип функции SetFileTime, позволяющий легальным образом манипулировать с датой создания файла

BOOL SetFileTime

(

HANDLE hFile, // handle to the file

CONST FILETIME *lpCreationTime // time the file was created

CONST FILETIME *lpLastAccessTime, // time the file was last accessed

CONST FILETIME *lpLastWriteTime // time the file was last written

);

Но тут есть один нюанс. Настолько тонкий, что почти незаметный. На NTFS-разделах с каждым файлом ассоциирован ряд скрытых атрибутов, недоступных стандартным функциям API и среди прочей полезной информации хранящих дату создания данной файловой записи, совпадающей по времени с датой создания самого файла. Расхождение в датах указывает на факт подделки, не свойственный честным программам и разоблачающий «умную малварь».

Если и быть умным, то до конца! Изменив перед созданием файла системное время, а затем возвратив его обратно, малварь обеспечит себе наивысшую скрытность и прочно оккупирует компьютер, не опасаясь быть замеченной.

[5 недокументированные возможности.]

Использование недокументированных возможностей оправдано тогда и только тогда, когда без них обойтись невозможно или же создатель малвари на 100% уверен, что на всех целевых операционных системах эти возможности реализованы одинаково, что вовсе не факт. Даже установка очередного пакета обновления приводит к значительным изменениям в поведении ОСи.

Вот только один пример. При запуске exe-файла доступ к нему блокируется и, если он вдруг захочет себя удалить, без посторонней помощи ему это ни за что не сделать, поскольку удаление становится возможным только после снятия блокировки, то есть после завершения процесса. Конечно, можно создать bat-файл, но только это некрасиво (хоть и надежно). А можно воспользоваться недокументированной особенностью Windows 9x/NT, позволяющей освобождать страничный образ файла, тем самым снимая с него блокировку. В 9x это делается функцией FreeLibrary, в NT и W2k – UnmapViewOfFile. Правда, выполнение кода в освобожденной секции становится невозможным, и любая попытка обращения к принадлежащей ей памяти возбуждает исключение. А нам еще DeleteFile и ExitProcess выполнить надо. Как быть? Приходится, разрывая себе задницу пополам, «заряжать» стек.