Перед внедрением в файл нерентабельного X-кода необходимо предварительно убедиться, что в файл не был внедрен кто-то еще. К сожалению, универсальных путей решения не существует, и приходится прибегать к различным эвристическим приемам, распознающим присутствие инородного X-кода по косвенным признакам.

Родственные X-коды всегда могут «договориться» друг с другом, отмечая свое присутствие уникальной сигнатурой. Например, если файл содержит строку «x-code ZANZIBAR here», отказываемся от внедрения на том основании, что здесь уже есть «свои». К сожалению, этот трюк очень ненадежен, и при обработке файла любым упаковщиком/протектором сигнатура неизбежно теряется. Ну разве что внедрить сигнатуру в ту часть секции ресурсов, которую упаковщики/протекторы предпочитают не трогать (иконка, информация о файле и т. д.). Еще надежнее внедрять сигнатуру в дату/время последней модификации файла (например, в десятые доли секунды). Упаковщики/протекторы ее обычно восстанавливают, однако короткая длина сигнатуры вызывает большое количество ложных срабатываний, что тоже нехорошо.

Неродственным X-кодам приходится намного хуже. Чужих сигнатур они не знают и потому не могут наверняка утверждать – возможно ли осуществить корректное внедрение в файл или нет? Поэтому X-код, претендующий на корректность, обязательно должен быть рентабельным, в противном случае сохранение работоспособности файлам уже не гарантировано.

Упаковщики оказываются в довольно выигрышном положении: дважды один файл не сожмешь, и если коэффициент сжатия окажется исчезающе мал, упаковщик вправе отказаться обрабатывать такой файл. Протекторам – другое дело. Протектор, отказывающийся обрабатывать уже упакованные (зашифрованные) файлы, мало кому нужен. Если протектор монополизирует ресурсы, отказываясь их предоставлять кому-то еще, он должен обязательно контролировать целостность защищенного файла и, обнаружив внедрение посторонних, выводить соответствующее предупреждение на экран, возможно, прекращая при этом работу. В противном случае защищенный файл могут упаковать и попытаться защитить повторно. Последствия такой защиты не заставят себя ждать…

Классификация механизмов внедрения

Механизмы внедрения можно классифицировать по-разному: по месту (начало, конец, середина), по «геополитике» (затирание исходных данных, внедрение в свободное пространство, переселение исходных данных на новое место обитания), по надежности (предельно корректное, вполне корректное и крайне некорректное внедрение), по рентабельности (рентабельное или нерентабельное) и т. д. Мы же будем отталкиваться от характера воздействия на физический и виртуальный образ подопытной программы, разделив все существующие механизмы внедрения на четыре категории, обозначенные латинскими буквами A, B, C и Z.

n  К категории А относятся механизмы, не вызывающие изменения адресации ни физического, ни виртуального образов. После внедрения в файл ни его длина, ни количество выделенной при загрузке памяти не изменяется и все базовые структуры остаются на своих прежних адресах. Этому условию удовлетворяют внедрение в пустое место файла (PE-заголовок, хвосты секций, регулярные последовательности), внедрение путем сжатия части секции и создание нового NTFS-потока внутри файла[1].