СКАЗКА про ENUNS и про братца его RUSNS * Zemsky Fershal //NF (C) 1998-2004

СКАЗКА про ENUNS и про братца его RUSNS
by
Sassa и CrkV

(Материалы к статье см. в каталоге \ENUNS)

Greets:

Jean-Pierre Godet за предоставленный MORE.FRA.
Группе немецких товарищей за предоставленный MORE.DEU.
Благодарим Borland за TASM, а Sun за Java J
Отдельная безграничная благодарность SEN за Hiew6.01

Откуда это взялось

В последнее время мы наткнулись сразу на несколько источников,
повествующих о том, что в COM-файлах операционной системы Windows95/98
появились странные сожители. Название им дано из четко прослеживающейся
строки в конце файла: ENUNS; были замечены также файлы с подписью
RUSNS, действия которых сходны.
Непосредственно за ними присутствуют еще два байта, которые
являются не то контрольной суммой, не то указателем на некие данные. Во
всех известных нам источниках эти байты упоминаются под именем
ENUNS-подписи и считаются дополнительным кодом, якобы проверяющим
сохранность СОМ-файла (и который "вешает" программу, если подпись
испорчена).
К этой мысли сходятся и неформальные источники, и вирусная
энциклопедия Касперского. В последней даже упомянуты два специальных
вируса: Foo.956 и TD.1536. Они поражают файлы с учетом этой
особенности. Естественно, что и лечение от вирусов в этом случае должно
отличаться. С целью разработки методов лечения и началось исследование,
результатом которого и есть эта статья.

Что лежит дальше

Сама статья - критический анализ сказки, основанный на двух
независимых исследованиях. Вскрытию подлежали незараженные CHOICE.COM и
MORE.COM из русского и английского дистрибутивов Windows98
соответственно. Для уточнения некоторых деталей были использованы и
другие COM- и EXE-файлы из разных дистрибутивов (поскольку в EXE-файлах
тоже "мелькает что-то похожее на ENUNS" [1]).
В Приложении А приводится описание утилит, разработанных на Пасеке
специально к этой статье, и работающих с ENUNS-файлами.
Для любопытных наиболее распространенные варианты сказки напечатаны
в Приложении Б. Там просто перепечатки. По этическим соображениям
исходники вирусов, присутствующие в некоторых оригиналах, не
печатаются, а стиль изложения материала упрощен, что делает его не
настолько агрессивно-экспрессивным.
Можно заметить некоторые вариации в описании монстров в разных
изложениях, но все сходятся к одной мысли: непонятное чудище.
Мы не несем ответственности за технические и грамматические ошибки
в перепечатках.

На первый взгляд

Неформальные источники, как всегда, полны технических и фактических
ошибок, что не позволяет согласиться с ними сразу и во всем. Формальные
источники по своей природе коммерческие, и потому свободно
предоставляется слишком мало информации, из которой можно сделать
ложные выводы. Поэтому мы решили заняться собственным исследованием.
Действительно, в COM-файлах, поставляемых совместно с Windows95/98,
заметна подпись ENUNS или RUSNS. В теле файла также несколько раз
встречается строка 'ENU' или 'RUS' соответственно. В EXE-файлах (в
утилитах, работающих в режиме MS-DOS) в заголовках тоже встречаются
'ENU' и 'RUS'.
Двухбайтное поле в ENUNS-подписи СОМ-файлов указывает на данные,
выполненные в стиле прицепного кода и которые содержат, кроме прочего,
сообщения, выводимые программой. Естественно, у файлов из русских
дистрибутивов сообщения были русские. (Вывод о возможности замещения
данных был сделан немного позже, после углубления в их структуру.)
И мы предположили, что программы никак не должны проверять
целостность файла, поскольку кажется неразумным "повисать", _намекая_
на неполадки!!!
Если бы самопроверка дейтсвительно была особенностью программы, то
она должна бы _сообщить_ о неурядице (и исследовение подтвердило, что
программы повисают именно оттого, что они _не_ проверяют целостности
кода). Если быть точным, то реакция программ в разных случаях была
разной. Некоторые завершались внешне обычным образом, а отдельные даже
работали, хотя и с нарушением речевой функции J.

А если покопаться?..

Как выяснилось, ENUNS-данные являются всего лишь словарем сообщений
программы. (А NS в 'ENUNS' предположительно означает 'Native Speech').
Помимо фраз в словаре содержится индексная информация.
Трехбуквенный префикс нашумевшей подписи предполагает язык, на который
ориентировано приложение (уточнение ниже). Таким образом, ENU означает
американский английский, RUS означает русский, и мы ожидали, что FRA
означает французский, а DEU означает немецкий: программы ищут
переменную окружения LANG, код языка из которой выбирается для вывода
сообщений, и догадки подтвердились после того, как нам удалось
раздобыть СОМ-программы на других языках. (Для особо подозрительных
прилагается MORE.COM из французской и немецкой версий ОС Windows.)
На случай, если переменная LANG в окружении не определена,
программа использует "зашитый" при компиляции код языка, который по
логике работы программы может отличаться от указанного в семибайтной
сигнатуре в конце файла. В случае, если в словаре не найден нужный язык
(зашитый или заданный в переменных окружения), используется первый
попавшийся.
Собственно, повисание происходит при попытке выводить несколько
последовательных сообщений, вроде экрана помощи (других случаев не
обнаружено). Код содержит ошибки, перечислять которые не имеет смысла.
Способ размещения словаря в программах позволяет проводить
изменения и дополнение словаря новыми переводами без перекомпилирования
программ. Достаточно лишь, чтобы COM-файлы не превышали стандартную
длину 64К, а каждый словарь был не длиннее 1024 байт вместе с индексной
информацией [см. примечания в конце статьи].
Именно для этой цели и присутствует концевая подпись в СОМ -файлах.
Хотя сама программа ведь знает еще при компиляции, где начинается
список словарей. Поэтому чтение концевой подписи _из_файла_
(собственно, как и самого словаря) кажется излишним, и именно этот
ключевой момент и может приводить к зависанию программ, зараженых без
учета их особенности. Концевая запись должна лишь позволять _внешним_
программам найти начало словаря, чтобы скорректировать его. Сама
программа должна пользоваться априорными данными (хотя и не делает
этого). В этом случае после заражения программы не могли бы получить
обновление словаря, но программа оставалась бы полностью
работоспособной.
У EXE-файлов словарь помещен в MZ-заголовок, поэтому чтение из
файла - единственный выход в этом случае.

Примечания.

Ограничение на длину страницы касается только некоторых СОМ-файлов,
точный перечень имен которых не известен; например, к ним относится
MORE.COM.

Структура словаря

Структура словаря - знания, необходимые для правильного исцеления.
Здесь мы приведем ее описание. Числа приведены в шестнадцатиричном
виде, а названия полей введены самими исследователями.

Dictionary:
Page:
+0 10 Header - заголовок страницы
Header:
+0 2 P_Next - указатель на следующую страницу.
к адресу начала страницы нужно прибавить
это число, чтобы получить смещение следующей
страницы.
+2 2 P_Length - "длина" страницы.
(всегда?) равно P_Next, проверяется как
длина страницы, но как длина используется
P_Next. странно...
+4 3 P_Lang - язык страницы.
трехбуквенный код языка, на котором
записаны сообщения на этой странице.
по этому полю программа и находит нужную
страницу.
+7 4 P_R1 - неизвестное поле.
не найдено кода, обращающегося к нему.
во всех найденных программах было:
01 B5 00 01 - для ENU
03 52 00 01 - для DEU и FRA.
возможно, версия или дата.
+B 2 P_Sig - подпись "NS".
по ней определяется, является ли это частью
словаря.
+D 3 P_R2 - неизвестное поле.
не найдено кода, обращающегося к нему.
во всех найденных программах первые два
байта соответствуют первым двум буквам имени
программы, а третий байт - 00.
10 - длина заголовка.
+10 1 Counter - количество абзацев.
+11 ... P_Para - двухбайтные указатели на абзацы.
к смещению указателя нужно добавить хранящееся в нем
значение, чтобы получить адрес абзаца.
повторяются указанное в Counter число раз
+* потенциально свободное место.
+? ... Para - абзац.
Para:
+0 1 T_Para - тип сообщений в абзаце.
1 - критические ошибки.
2 - ошибки.
3 - другие сообщения.
+1 1 C_Para - количество строк в абзаце.
+2 4 Line - ссылка на сообщение
Line:
+0 2 Id - идентификатор
сообщения.
уникальный в пределах
абзаца.
+2 2 P_Msg - указатель
на сообщение.
к смещению Line нужно добавить
это число, чтобы получить адрес
строки сообщения.
+6 Line... - повторение соответственно
счетчику C_Para.
+* потенциально свободное место.
+? Para... - многократное повторение,
соответственно P_Para.
+* потенциально свободное место.
+? сообщения в виде паскаль-строк:
+0 1 Len - длина сообщения
+1 ... Msg - ASCII-строка сообщения.

Между сообщениями также возможно существование свободного места.
+* потенциально свободное место.
Page... - повторение Page, неограничено по числу; начало страницы
выровнено по параграфам от начала файла.
Ссылка из предыдущей страницы не обязательно указывает точно на
начало страницы. Смещение будет выровнено до параграфа.

В COM-файлах вслед за словарем Dictionary присутствует хвостовая
подпись:

+? Dictionary
+EOF-7 3 имя языка, хотя, это поле и не используется.
+EOF-4 2 'NS' - подпись СОМ-файла со словарем.
+EOF-2 2 P_Dictionary - обратная ссылка на словарь.
положительное число, указывающее число байт от конца файла,
где начинается словарь.

Последняя страница словаря ссылается на эту подпись.

В EXE-файлах словарь Dictionary содержится полностью в MZзаголовке.
Если Relocations в файле нет, то словарь начинается по смещению 40;
если Relocations есть, то словарь начинается сразу за последним
Relocation по смещению, выровненному по границе параграфа.
Каждая страница словаря содержит по-крайней мере 2 абзаца: тип 1 -
критические ошибки - и тип 2 - другие ошибки (причем, в этой
последовательности). Но логика работы загрузчика словаря подразумевает,
что должен быть еще один абзац, предположительно "прочие сообщения".
Остальные абзацы загружаются в цикле, и, судя по расположению, видимо
подразумеваются "прочие сообщения". Абзацев с сообщениями с типом
больше 3 не наблюдалось. Логика работы словаря подразумевает, что
сообщения даже одного типа могут храниться в разных абзацах: поиск идет
во всех. Ограничение на количество абзацев, очевидно, существует, но
выделить точное число не удалось.
Также отметим, что не наблюдалось более одной критической ошибки и
"другой" ошибки, и все записи в этих абзацах содержали Id равный FFFF.
Были замечены только "Extended error" в виде критической ошибки и
"Parse error" в абзаце о "других" ошибках.
Последняя строка "просто сообщений" содержит сообщение с Id=26AC, и
само сообщение содержит непечатаемые символы. Его назначение раскрыть
не удалось, поскольку у всех обнаруженных файлов строка одна и та же, а
ссылки на нее или ее идентификатор отсутствуют.
Итак, словарь способен содержать страницы с сообщениями на разных
языках, хотя мы и не видели программ с несколькими страницами. В
зависимости от выбора пользователя (переменная LANG) программа может
выдавать сообщения на любом из этих языков. На случай, если заданный
язык не обнаружен, используется первая страница.

Направления усовершенствования антивирусных средств

Механизм работы словаря позволяет вставлять вирусный код
стандартными способами в начало СОМ-файла, либо в любое другое место до
словаря, не изменяя его структуры, и не корректируя индексные ссылки.
В ЕХЕ-файлах словарь содержится в неформатированной области
заголовка, поэтому присутствие вирусов, корректно обратывающих такие
заголовки, никак не будет отражаться на работоспособности программы. В
этом случае достаточно обработать файл антивирусными средствами.
Естественно, вирусы типа Marina, превращающие EXE в COM, исказят
словарь, или уничтожат его совсем, и в этом случае восстановление вряд
ли возможно.
Поскольку вирусы, поражающие начало СОМ-файла, оверайтеры, а также
ЕХЕ-вирусы не привносят ничего нового в процесс исцеления, не станем
останавливаться на них более подробно. При исцелении же от
Ninnish-based вирусов необходимо корректировать концевую подпись файла.
Некоторые источники ошибочно полагают, что порча 7-байтной подписи
в конце файла наносит непоправимый ущерб. Да, действительно, некоторые
антивирусы могут не учитывать существование структуры NS и исцелять
файлы, искажая структуру их словаря, но это поправимо. Естественно,
уничтожив саму подпись, трудно автоматически определить, есть ли в
данной программе словарь. (Хотя с другой стороны, процедура загрузки
словаря кажется стандартной и можно искать ее). Возможно также искать
обрывки списка переводов сообщений с последним указателем P_Next
указывающим за конец файла, но формат структуры списка
недокументирован, и содержит некоторые недостоверно константные поля (P
_R1, P_R2). Тем не менее, анализ вложенных структур позволяет заявлять
довольно уверенно о присутствии словаря NS в СОМ-файлах.
К статье прилагается утилита для выполнения восстановительных
работ.

Отметим, что присутствие словаря делает возможным исполнение
принципиально отличающихся штаммов, которые способны различать
специальные виды СОМ-файлов, и заражать их особым способом. Например,
вставляя себя как дополнение к словарю. Таким образом, возможно
создание вирусов, паразитирующих в существующих страницах словаря, а
также вирусов, создающих собственные страницы. Идея изложена в
прилагающемся коде. Собственно, MonGoose реализовал первый вид
словарного паразита, хотя и не в полной мере; то есть, не зная
структуры словаря, и даже не подозревая, что это именно словарь, он
просто паразитирует на последней его странице. При этом размеры
страницы не скорректированы, что может приводить к некорректной работе
программы в некоторых случаях.
Понятно, что MonGoose лишь усмехнется злорадно, а вот мы любим
доводить дело до ума. Поэтому прилагается код, который способен создать
репликацию в заданном файле, учитывая правила хорошего тона (если так
можно выражаться о подобных действиях). Естественно, этот пример не
является вирусом, но, думается, достаточно полно иллюстрирует картину
для вирусологов.

Заключение

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

=======================================================================

Приложение А. Утилиты.

1. Утилита ASMNS.COM вставляет кусочек исполняемого кода перед
первой страницей существующего словаря и корректирует порядок
исполнения программы таким образом, чтобы первым был выполнен именно
он. Если в строке параметров задать ключ "-" перед именем файла, то
программа попытается удалить созданную там страницу словаря с
исполняемым кодом. В случае ошибок выдаются соответствующие сообщения.
Вставляемый код просто выводит строку "East or West ASM is Best" и
передает управление старому коду COM-файла. Вклеивание страницы
происходит именно перед первой, чтобы показать, что структура новой
страницы правильная. На самом деле такой подход приводит к
специфической работе СОМ-файла:
- если в переменной окружения LANG задан несуществующий в словаре
язык, то программа попытается загружать первую страницу, которая теперь
не является страницей сообщений;
- если применить утилиту к одному и тому же файлу более одного
раза, то можно наблюдать бесконечный цикл сообщений. это происходит
оттого, что после завершения работы новорожденного кода,
восстановленные байты начала файла будут представлять собой переход в
ту же точку, где находится этот код (раньше на том месте был другой, но
идентичный, код);
- если словарь начинается с адреса, невыровненного по параграфу
(такого, правда, не встречалось), то вставка первой страницы приведет к
тому, что продолжение словаря не будет распознано.
В этом смысле более "корректным" кажется вставлять в словарь
последнюю страницу, хотя и это может приводить к разрушительным
действиям, которые уже нельзя никак предотвратить: при удалении
страницы из словаря ссылка на исполняемый код становится неверной.
Однако, нам не известны стандартные утилиты, занимающиеся
редактированием словаря.
Отметим также, что утилита примитивная, и не проверяет атрибутов
файла (RO), а также не проверяет его размеров перед модификацией.
Утилита содержит NS-подпись достаточно корректную для того, чтобы
вставить страницу словаря в исполняемый модуль самой утилиты.

2. Позже была разработана еще более "умная" утилита: DICNS. Она
написана на Java, поскольку Sassa в экзиле слишком поздно раздобыл
Pascal, чтобы переписывать полуготовую программу наново, а работа над
синтаксисом входных файлов _показалась_ слишком утомительной для
реализации на ассемблере. Надеемся, исходный текст достаточно понятен
даже тем, кто не владеет ни языком Java, ни C++, ни хотя бы C.
Это, собственно, и есть редактор словаря.
Запускать нужно так: в прилагаемом DICNS.BAT исправить путь к JAVA
(в Windows есть), или самому писать ту строку, которая там записана.
(Тем, кто не пользовался java: "-cp dicnsv2.jar dicns" означает, что из
файла dicnsv2.jar нужно запустить "приложение" из dicns.class). Итак,
строка запуска такая:

dicns.bat <ключи> <файл1> [<файл2>]

или

java -cp dicnsv2.jar dicns <ключи> <файл1> [<файл2>]

Запуск без параметров выдает экран помощи.

Ключи бывают:
-c - восстановление NS-подписи в <файл1>
-s - запись словаря в текстовый <файл2>
-l - загрузка словаря из текстового <файл2>

Ключ "-c" - умолчательный.

Итак, программа умеет восстанавливать подпись у неверно исцеленных
СОМ-файлов (некоторые антивирусы могут приводить к таким действиям при
попытках лечить Ninnish-based), считывать и записывать в исполняемые
файлы словарь сообщений. После считывания словаря он представляется в
виде специального ASCII -файла, который можно редактировать обычными
редакторами, а затем использовать для загрузки словаря обратно в
исполняемые файлы. Таким образом, можно добавлять, удалять,
перемешивать страницы и просто изменять сообщения. Прилагается пример -
MORE.ZF4 - в котором сообщения скорректированы соответствующим образом,
а также словарь загруженных сообщений MORE.DIC.
В словаре показано максимально возможное разнообразие допустимого
синтаксиса. Описывать его подробно я не стану, а лишь скажу, что
разумно создавать новые страницы путем копирования - так вы избавитесь
от ошибок в нумерации собственных сообщений. Для создания новой
страницы нужно вписать перед нужной страницей структуру page[]{}, задав
все необходимые параметры в квадратных скобках, и создав все разделы
внутри фигурных скобок. В квадратных скобках записан заголовок
страницы, как описано в структурах выше, но без указателя P_Next и
P_Length.
Внутри фигурных скобок монут содержаться абзацы para[]{}. В
квадратных скобках записывается идентификатор темы сообщений этого
параграфа. В фигурных скобках записывается последовательность строк,
именно в том виде, как это было в файле. Каждая строка line[] в
квадратных скобках содержит идентификатор сообщения. Вы можете его
редактировать, если хотите. Но это бессмысленно, поскольку программа
будет искать только те сообщения, которые знает. Разве только вам
хочется разместить непечатный текст. Сами строки (как и другие значения
в этом файле) - это последовательность ASCII-текста и шестнадцатиричных
значений, записанных через запятую. Символы строки записаны в
естественной последовательности, шестнадцатиричные значения содержат
запись чисел msb->lsb, то есть, старший бит слева, младший бит правее.
После повторного применения утилиты к одной и той же программе
можно заметить, что даже не измененный словарь, будучи загружен в
программу, дает совсем другой код - который, тем не менее, полностью
работоспособен.
Словарь MORE_.DIC отражает допустимые синтаксически, но
недопустимые логически конструкции. И все же, разработчик посчитал
необходимым позволить пользователю создавать и такие конструкции.
Например, если этот словарь добавить в конец словаря MORE.DIC, то это
результате даст работоспособную программу, поскольку языка ZF4 не
существует, и эта страница не первая.
Все числа считаются 16-ричными. Код апострофа - 27 (естественно,
шестнадцатиричное).
Заметим еще такие особенности работы программы:
- после обработки COM-файлов с помощью ASMNS.COM эта программа все
же считается корректным NS-файлом, поскольку хотя внутренняя структура
словаря искажена (верен только заголовок у страницы на языке 'ASM'), но
NS-подпись будет исправлена на следующую за ней страницу. Утилита
просто посчитает, что словарь начинается на несколько байт позже, чем
это стоит в подписи;
- если страница сообщений длиннее 1024 байт (ограничение для
MORE.COM), будет выдано предупреждение и напечатан заголовок
подозрительной страницы;
Пользователь полностью отвечает за размеры страницы: DEBUG.EXE
принимает и более длинные страницы, а MORE.COM - нет; при этом по
структуре словаря невозможно определить максимально допустимые размеры
страницы.
Программа работает как с COM, так и с EXE-файлами и ошибок в работе
не обнаружено. Однако, если читатели найдут любого рода недоразумения -
просьба написать в редакцию.

==============================================================

Приложение Б. Сказки в разных вариантах.

Сказка, рассказанная в Мунгусе [1].

Дос вымирает. Билли уже во всю потеет над виндами 2000, которые уже
будут работать без DOS'а! Ну а 95тые окна принесли новые заморочки
начинающим вирмейкерам. Как известно в 95ом есть "собственный дос".
Если посмотреть на СОМ файлы в %windir %\COMMAND то мы увидим в конце
файла байты ENUNS, а за ними контрольную сумму файла (?). В заголовках
ЕХЕ-файлов тоже мелькает что-то похожее на ENUNS, но эти файлы
заражаются стандартными способами. А вообще и ENUNS-файлы заражать
довольно легко, ненадо вообще подсчитывать crc. Для начала надо считать
последние 7 байт в буфер, они должны представлять из себя что-то типа:
ENUNS??, где последние два байта crc файла. Если мы хотим чтоб файл
после заражения работал эти байты должны остаться в конце файла, т.е.
буффер должен находиться в конце вируса (можно конечно поизвращаться с
переносами и т.д.), теперь надо добавить к контрольной сумме [размер
тела вируса], которое мы приписываем к файлу и все готово.

--------------------------------------------------------------

Пьеса в двух частях с эпилогом от TechnoPhunk [2].

ЗАРАЖЕНИЕ COM.ENUNS-файлов

Действительно, com-файлы 95х виндов имеют все вышеперечисленное и
нижеупомянутое, но к делу это не относится, суть в том, что они и в
самом деле не работают, будучи заражены стандартно. Однако дело обстоит
не так страшно, я бы даже сказал, весьма [плохо], потому как "[зачем]
они это сделали" действительно не понятно. Что же из себя представляет
ENUNS? Важно лишь то, что у него последние семь байтов - ENUNSxy, где
xy - длина (word) файла [это неверно, см статью - прим ред.]. Поэтому
чтобы [заразить] такое убожество, достаточно считать эти байты (можно
все семь):

sub cx,cx
mov dx,-7
dec cx ; (cx:dx = -7 в
mov ax,4202h ; дополнительном коде)
int 21h ; переместим pointer

mov cx,7
mov ah,3Fh
lea dx,[ENUNS+bp] ; или что там у вас...
int 21h ; прочитаем 7 байт

add word ptr [ENUNS+bp+6], end-start

И все! Теперь ваш файл готов к записи. В конечном итоге файл будет
выглядеть так: [неинтересно, но цензура может воспротивиться] Надеюсь,
идея ясна, хотя что тут может быть неясного... Но спешу предупредить
(т.е. обломить): В 98-х виндузах появилась !НОВАЯ ХРЕНЬ! Называется
RUSNS. (это типа адаптации enuns'а для русских J [по иронии судьбы он
оказался прав - прим. ред] Что это за чудо-юдо, пока не знаю. Но думаю,
не особо мощное. Так что - вперед! Проведите небольшое исследование,
это поможет вам в дальнейшей работе. Если кто владеет подробной
информацией насчет RUSNS, просьба написать на [е-mail]. Хотелось бы
узнать не "как его [заражать]", а что это такое вообще (насчет
[заражения] - так вроде-бы все так же).

Информация позаимствована из TechnoPhunk/TI

have fun!
--------------------------------------------------------------

Почти быль, со страницы FRiZER-а [3].

В Win95/98 СОМ-файлы в %windir%\command имеют способность проверять
себя на цельность и активно этим пользуются. Вирус, которому этот факт
не известен, на них обломается, т.к. работать такие файлы не будут, что
вызовет у юзера обоснованные подозрения. Итак, посмотрим, что же делает
такой ENUNS'овый COM. Он открывает себя, читает последние 7 байт. Если
с файлом все Ok, то там должна находиться строка 'ENUNS', а после нее
некое слово (dw). Это dw - смещение 16-байтной сигнатуры от конца
файла. Что это за сигнатура нам абсолютно фиолетово. Важно то, что при
дозаписи вируса в конец файла строка 'ENUNS' уже не будет находиться на
своем месте, т.е. такой файл не будет работать. Что же делать? Все
очень просто. Необходимо, чтобы в конце файла оставалась строка
'ENUNS', а слово (dw) после нее все также указывало на смещение с конца
файла 16-байтной сигнатуры. Для этого слово (dw) нужно увеличить на
величину приращения файла. Все! Жертва опять будет думать, что с ней
все Ok. Также во многих EXE-файлах видна эта 16-байтная сигнатура. Но
они и так уже не [девственные] J (упакованы), поэтому их можно смело
заражать обычным образом. Да и строка 'ENUNSxy' в хвосте у них
отсутствует.
Приведу последовательность действий с примерами кода:

Устанавливаем указатель на 7-й байт с конца файла.

mov ax,4202h
mov dx,-7
mov cx,-1
int 21h

читаем 7 байт

mov ah,3fh
mov cx,7
lea dx,[bp+enuns-start]
int 21h

сравниваем 4-й и 5-й байт с 'NS' - так делают сами жертвы [кстати,
MonGoose этого не знал, что вызывает подозрения в неосознанном
копировании чужих текстов]

cmp word [bp+enuns-start+3],'NS'

* если там не строки 'ENUNSxy' то заражаем как обычно

увеличиваем слово XY на длину вируса

add word ptr [bp+enuns-start+5],end-start

* XY увеличивается вообще-то на длину приращения файла, т. е. если
первоначальная строка 'ENUNSxy' затирается началом вируса, то к слову
XY прибавляется число уже на 7 меньше, чем размер вируса.
Дальше идет обычно заражение СОМ-ка, но не забывайте, что строка
'ENUNSxy' должна быть последней, а иначе зачем мы все это делали ;)

Rest in Peace. FRiZER

--------------------------------------------------------------

Дезинформация в вирусной энциклопедии Касперского [4]

Foo.956

Неопасный нерезидентный зашифрованный вирус. Ищет COM-файлы в
текущем, родительских каталогах и в C:\WINDOWS и заражает не более трех
обнаруженных файлов. Записывается в конец файлов. Корректирует поле
самопроверки COM-файлов Windows32 (имеющих строку "ENUNS" в конце
файла). Использует антиотладочные приемы. По 29 числам выводит текст и
завешивает компьтер:

--FOO VIRUS--
WE'RE ALL STARS NOW, IN THE DOPESHOW
MADE IN THE UK, WE EXIST..

TD.1536

Неопасный резидентный файлово-загрузочный вирус. Записывается в
конец COM- и EXE-файлов при их запуске, заражает MBR винчестера при
старте зараженного файла и загрузочные сектора дискет при обращениях к
ним. Вирус никак не проявляется; зараженные файлы/диски определяет по
наличию идентификатора "TD". При запуске из зараженного файла вирус
перехватывает INT 21h, при загрузке с зараженного диска он также
перехватывает INT 13h, 1Ch. При заражении файлов вирус обрабатывает и
подправляет идентификатор ENUNS самопроверки COM-файлов от Windows32.
При инсталляции в память вирус также заражает файл C:\WINDOWS\WIN.COM и
удаляет файл C:\WINDOWS\SYSTEM\IOSUBSYS\HSFLOP.PDR

=======================================================================

Использованные источники

1. MonGoose.
2. TechnoPhunk/TI.
3. FRiZER's home page.
4. Вирусная Энциклопедия Касперского. http://www.kaspersky.com

По известным причинам полные координаты неформальных источников не
указываются.

----------------------------------------------------------------------
(с) CrkV & Sassa, 2000.