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

Это вернейший признак вирусного заражения! Вернее и быть не может!

Листинг 5. «Заглушка», представляющая собой переходник к импортируемой функции и оттягивающая все перекрестные ссылки на себя

BRAT0:00648310 CreateFileA     proc near           ; CODE XREF: sub_432A58+C0↑p

BRAT0:00648310                                     ; sub_432BC0+C0↑p ...

BRAT0:00648310 FF 25 48 44+    jmp    ds:__imp_CreateFileA

BRAT0:00648310 CreateFileA     endp

Листинг 6. Таблица импорта исследуемого приложения: наличие «паразитной» ссылки на CreateFileA указывает на факт вирусного заражения

.idata:006A4440 extrn __imp_CreateDirectoryA:dword ; DATA XREF: CreateDirectoryA↑r

.idata:006A4444 extrn __imp_CreateEventA:dword     ; DATA XREF: CreateEventA↑r

.idata:006A4448 extrn __imp_CreateFileA:dword      ; DATA XREF: CreateFileA↑r

.idata:006A4448                                    ; DATA XREF: sub_6A4140↑r