Грех4 — дата создания файла
Штатным образом, Windows поддерживает три даты, связанные с каждым файлом — дата создания, дата модификации (доставшаяся ей в наследство от MS-DOS) и дата последнего доступа. При создании файла на диске ему автоматически присваивается текущая дата создания, что позволяет легко изобличить непрошеную заразу — просто загородим в каталог WINNT\System32 своим любимым FAR'ом, ждем <CTRL-F8> и файлы, созданные последними, оказываются наверху. Так же можно воспользоваться и стандартным поиском, интегрированным в "проводник".
Рисунок 8 червь msblast, забывающий скорректировать дату создания файла, чем и выдающий себя с головой
Умная малварь поступает так: она считывает время создания KERNEL32.DLL (или любого другого системного файла Windows) и вызывает _стандартную_ и притом _документированную_ API-функцию 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
);
Листинг 1 прототип функции SetFileTime, позволяющий легальным образом манипулировать с датой создания файла
Но тут есть один нюанс. Настолько тонкий, что почти незаметный. На NTFS-разделах, с каждым файлом ассоциирован ряд скрытых атрибутов, недоступных стандартным функциям API, и среди прочей полезной информации хранящих дату создания данной файловой записи, совпадающей по времени с датой создания самого файла (подробнее см. соседнюю статью "контрразведка с soft-ice в руках"). Расхождение в датах указывает на факт подделки, не свойственный честным программам, и разоблачающий "умную малварь". Если и быть умным — то до конца! Изменив перед созданием файла системное время, а затем возвратив его обратно, малварь обеспечит себе наивысшую скрытность, и прочно оккупирует компьютер, не опасаясь быть замеченной.
