n  физически сдвигаем все последующие секции в файле на эту же величину;

n  перемещаем выбранные части секции в оверлей, записывая их в произвольном формате, но так, чтобы сами потом смогли разобраться;

n  иначе:

n  дописываем выбранные части секции в конец файла, записывая их в произвольном формате, но так, чтобы сами потом смогли разобраться;

n  на освободившееся место записываем X-код.

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

Ничего другого не остается, как анализировать весь X-код целиком, и если манипуляции с восстановлением секции будут обнаружены – факт внедрения окажется разоблачен. X-код выдает себя вызовом функций Virtual Protect (присвоение атрибута записи) и GetCommandLine, GetModuleBaseName, GetModuleFullName или GetModuleFullNameEx (определение имени файла-носителя). Убедитесь также, что кодовая секция доступна только лишь на чтение, в противном случае шансы на присутствие X-кода существенно возрастут (и ему уже будет не нужно вызвать VirtualProtect).

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

Реже встречаются ошибки определения длины сбрасываемой секции: если CS.v_sz < CS.r_sz и CS.r_off + CS.raw_sz > NS.raw_off, то системный загрузчик загружает лишь CS.v_sz байт секции, а внедряемый код сбрасывает CS.r_sz байт секции, захватывая кусочек следующей секции, не учитывая, что она может проецироваться совершенно по другим адресам и при восстановлении оригинального содержимого сбрасываемой секции, кусочек секции так и не будет восстановлен. Хуже того, X-код окажется как бы разорван двумя секциями напополам, и эти половинки могут находиться как угодно далеко друг от друга! Естественно, работать после этого он не сможет.