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

Внедрение во все служебные секции (например, секцию ресурсов или fixup) распознается по наличию в них чужеродных элементов, которые не принадлежат никакой подструктуре данных (см. рис. 6).

Рисунок 6. Осмысленный машинный код в хвосте секции данных – признак внедрения

Восстановление пораженных объектов. Чаще всего приходится сталкиваться с тем, что программист не предусмотрел специальной обработки для виртуального размера, равного нулю, и вместо того чтобы внедриться в хвост секции, необратимо затер ее начало. Такие файлы восстановлению не подлежат и должны быть уничтожены. Реже встречается внедрение в секцию с «неудачными» атрибутами: секцию, недоступную для чтения, или DISCARDABLE-секцию. Для реанимации файла либо заберите у X-кода управление, либо отремонтируйте атрибуты секции.

Могут также попасться файлы с неправильно «подтянутым» виртуальным размером. Обычно вирусописатели устанавливают виртуальный размер внедряемой секции равным физическому, забывая о том, что если r_sz < v_sz, то виртуальный размер следует вычислять исходя из разницы адресов виртуальных адресов текущей и последующей секции. К счастью, ошибки внедрения этого типа не деструктивны и исправить виртуальный размер можно в любой момент.

Внедрение в регулярную последовательность байт

Цепочки нулей необязательно искать в хвостах секций. Дался нам этот хвост, когда остальные части файла ничуть не хуже, а зачастую даже лучше конца! Скажем больше, необязательно искать именно нули – для внедрения подходит любая регулярная последовательность (например, цепочка FF FF FF… или даже FF 00 FF 00…), которую мы сможем восстановить в исходный вид перед передачей управления. Если внедряемых цепочек больше одной, X-коду придется как бы «размазаться» по телу файла (а скорее всего так и будет). Соответственно стартовые адреса и длины этих цепочек придется где-то хранить, иначе как потом прикажете их вос-станавливать?

Регулярные последовательности чаще всего обнаруживаются в ресурсах, а точнее – в bitmap и иконках. Технически внедриться сюда ничего не стоит, но пользователь тут же заметит искажение иконки, чего допускать ни в коем случае нельзя (даже если это и не главная иконка приложения, «Проводник» показывает остальные по нажатию кнопки «сменить значок» в меню свойств ярлыка). Существует и другая проблема: если регулярная последовательность относится к служебным структурам данных, анализируемых загрузчиком, то файл «упадает» еще до того, как X-код успеет восстановить эту регулярную последовательность в исходный вид. Соответственно если регулярная последовательность содержит какое-то количество перемещаемых элементов или элементов таблицы импорта, то в исходный вид ее восстанавливать ни в коем случае нельзя, т.к. это нарушит работу загрузчика. Поэтому поиск подходящей последовательности существенно усложняется, но отнюдь не становится принципиально невозможным!