закрывать эту "дыру" предпочтительнее с помощью маленькой резиден-
тной программы, перехватывающей прерывание 21-4B. Возможно, пере-
хват следует выполнить сплайсингом, т.е. врезкой команды JMP в
оригинальный обработчик этой команды с тем, чтобы исключить воз-
можность того, что вирус предварительно перехватит 21 прерывание.
Кстати, перехватить 21 прерывание вирусу можно просто не дать, как
бы он не старался (на этой идее основаны сторожа CHECK21 и SBM є
см. прил.5). Получив управление, эта "заплатка" должна проверять
контрольную сумму. Для COM-файлов достаточно проверить первый
блок, а для EXE-файлов є заголовок и блок, куда передается управ-
ление. При этом для COM-файлов контрольную сумму можно хранить в
неиспользуемых байтах оглавления, а для EXE є в соответствующем
поле заголовка. Метод подсчета контрольной суммы должен быть пара-
метризуемым. Кстати, аналогичным способом можно закрыть другую
"дыру" в MS DOS, связанную с тем, что снятие атрибута READ ONLY не
требует подтверждения оператора. При этом можно предусмотреть воз-
можность отключения выдачи запроса с помощью специального, задава-
емого пользователем, пароля.
Другой идеей, связанной с поисками "полезных" применений компью-
терных вирусов, является автоматическое преобразование программы в
какую-то более приемлемую форму. Наиболее часто при этом предлага-
ется автоматическое сжатие программы. Действительно, имеется ряд
программ, выполняющих сжатие EXE-файлов, наиболее удачной среди
которых является LZEXE, которая обеспечивает экономию порядка 30%
на каждом EXE-файле при очень высокой скорости распаковки (практи-
чески не увеличивая время загрузки). Идее применить для этой цели
вирус уже более 15 лет и она высказывалась еще Ф.Коэном для обос-
нования своих работ. Теоретически здесь вроде бы "все чисто". Ви-
рус, заражая программы, свертывает их с помощью какого-то метода,
а при запуске развертывает. Однако с практической точки зрения эта
идея не выдерживает никакой критики. Дело в том, что включаемый в
сжатые программы распаковщик должен иметь минимальную длину (600
байтов для LZEXE), что в случае вируса обеспечить невозможно. Бо-
лее правильным подходом к реализации идеи сжатия информации на
диске, если уж добиваться "тотального" ее осуществления, является
написание специального дискового драйвера, который во-первых, не
включается в сжатую программу, а во-вторых, может сжимать не толь-
ко исполняемые файлы, а и все файлы, помеченные определенным атри-
бутом. Кстати, такие драйверы были реализованы и успешно применя-
ются. Однако широкое их распространение сдерживает тот факт, что
достигаемый эффект составляет порядка 20%, т.е. невелик и не ком-
пенсирует все возникающие при этом сложности и неудобства. Есть
все основания предполагать, что для "вируса сжатия" общий эффект
будет отрицательным, поскольку на каждой программе вирус должен
экономить не менее 12-16К (размер одного кластера, скажем, 4К +
собственный размер вируса, который для этого довольно сложного ви-
руса вряд ли составит меньше 8К), что для программ, меньших 64K,
т.е. для всех COM-файлов, практически нереально. Кроме того, если
не прибегать к каким-то ухищрениям, то вирусу придется хранить в
сжатой программе и достаточно объемную программу упаковки, которая
там совершенно не нужна, но которую нельзя выкинуть, т.к. иначе
вирус теряет способность к размножению. Ну и наконец, поскольку
часть программ при сжатии теряет работоспособность, то неясно как
предохранить такие программы от заражения.
Конечно, не исключены и какие-то другие возможные приложения
"полезного" вируса, однако такая форма коммуникации программ дол-
жна учитываться уже при разработке операционной системы, а экспе-
риментирование должно быть ограничено лабораторными экспериментами
на новых операционных системах. Возможно, что "вирусоподобные"
программы окажутся полезными в каких-то узких областях системного
программирования. Нельзя бросаться в "запретительство" только по-
тому, что в MS DOS вирусы создают серьезные проблемы. В то же
время автор убежден, что безвредных вирусов для MS DOS, как и для
любой операционной системы, ориентированной на широкий круг поль-
зователей, принципиально не существует. По определению, процесс
размножения вируса неконтролируем (иначе это, строго говоря, не
вирус). Если операционная система широко используется, то она не-
избежно будет "мигрировать" с одного компьютера на другой, попадая
туда, где ее совсем не ждали. А возникающая в ряде организаций при
обнаружении нового вируса паника зачастую наносит больший ущерб,
чем сам вирус, парализуя работу на несколько дней. Как бы ни была
прививка тщательно написанной, неизбежно окажется, что она вызыва-
ет потерю работоспособности части программ, какие-то тонкие взаи-
модействия с другими резидентными программами. В общем, пользова-
телей ожидают приключения. А ведь лекарство не должно быть опас-
нее, чем болезнь.
Принципиальной проблемой любой реализации "полезного" вируса яв-
ляется его переносимость. В силу своей природы вирусы сильно зави-
сят от версии операционной системы є значительно больше, чем обыч-
ные программы. Опыт показал, если зараженная вирусом программа ра-
ботоспособна в версии 3.3, то это совсем не означает, что она ока-
жется работоспособной в версии 4.0 или даже в версии 3.3 с
нестандартным командным процессором. В особенности плохо дело об-
стоит с резидентными программами, которые часто после заражения
теряют работоспособность. А ведь развитие операционной системы мо-
жет продолжаться десятилетиями. Получается, что при получении но-
вой версии операционной системы все программы нужно срочно лечить,
затем доставать новый штамм и заражать повторно. В общем, вопросов
здесь явно больше, чем ответов.
И, наконец, последний аргумент в пользу ограничения эксперимен-
тов по созданию "полезных" вирусов специализированными операцион-
ными системами связан с тем, что по определению "полезный" вирус
будет распространяться свободно. Тем самым, доступность механизма
размножения (центральной части любого вируса), делает его обще-
доступной базой для совсем небезобидных экспериментов. В частнос-
ти, он легко может быть модифицирован злоумышленником в троянскую
программу, которая, скажем, защищая от некоторых вирусов, сама пе-
риодически стирает FAT.
Накопленный автором опыт изучения вирусов позволяет сделать вы-
вод о том, что в существующих вариантах любой вирус является опас-
ной программой, неизбежно вызывающей побочные эффекты. Последние
связаны либо с повреждением заражаемых программ, либо с нарушением
функционирования операционной системы. Если сравнивать переноси-
мость вирусов с переносимостью резидентных программ, то обычно ви-
русы в большей степени зависят от версии операционной системы. При
размножении в среде отличной от "естественной" (например, более
поздняя версия операционной системы или нестандартный командный
процессор) вирусы, как правило, вызывают дополнительные побочные
эффекты вплоть до зависания операционной системы. Учитывая выска-
занные доводы трудно не прийти к мнению о том, что "безвредных"
вирусов не существует, а эксперименты по их созданию для MS DOS
связаны со значительным риском "выпустить джинна из бутылки".
3. КЛАССИФИКАЦИЯ КОМПЬЮТЕРНЫХ ВИРУСОВ
"Я никаким насекомым не радуюсь,
потому что я их боюсь,є призналась Алиса. є
Є Но я могу вам сказать, как их зовут."
"А они, конечно, идут, когда их зовут?"
є небрежно заметил Комар.
"Нет, кажется, не идут."
"Тогда зачем же их звать, если они не идут?"
"Им это ни к чему, а нам все-таки нужно.
Иначе зачем вообще знать, как что называется"
Льюис Керрол
Cерьезность и долговременный характер проблемы защиты от компью-
терных вирусов уже практически ни у кого не вызывают сомнений. По-
этому необходимо организовать оперативный обмен информацией по
данной проблеме и наладить взаимодействие работающих в этой обла-
сти специалистов. Это, в свою очередь, требует решения ряда подза-
дач, одной из которых является выработка стандартной классификации
компьютерных вирусов.
Стандартная классификация существенно облегчает накопление и
распространение знаний в любой области, и компьютерные вирусы не
являются исключением. Применительно к компьютерной вирусологии она
помогает решению такой важной задачи, как однозначное определение
типа обнаруженного вируса. При этом должен использоваться ограни-
ченный набор сравнительно простых и непротиворечивых признаков, не
требующих проведения глубокого анализа зараженных программ и эле-
ментов операционной системы. Существующие в настоящее время клас-
сификации, как правило, основаны на "кличках" є распространенных
среди программистов названиях, отражающих то или иное свойство ви-
руса. Анализируя имеющиеся неформальные названия, можно выявить
четыре основные тенденции их образования. Первая основана на ука-
зании места обнаружения или разработки вируса (Lehigh, Jerusalem,
Vienna, Alameda), вторая є на содержащихся в теле вируса текстовых
строках (Vacsina, Eddie, Dark Avenger, Disk Killer, sUMsDos),
третья є на вызываемом вирусом эффекте (Time Bomb, DOS-62,
Cascade, Black Fridaу) и наконец, четвертая є на длине тела вируса
или на приращении длины файла при заражении (524, 648, 1800, 2000
и т.д.). При этом один и тот же вирус может иметь множество
названий, и новое название, использованное разработчиком той или
иной антивирусной программы, далеко не всегда соответствует новому
вирусу.
Для широко известных вирусов перечень названий напоминает список
имен арабского шейха. Например, автор встречал более десяти назва-
ний вируса, обнаруженного в декабре 1987 года в Иерусалимском уни-
верситете (RСE-1813 по предлагаемой ниже классификации), среди ко-
торых три: Israeli virus (Израильский), Jerusalem (Иерусалим) и
PLO (ООП) є относятся к первому типу, два названия (sUMsDos и
sU) є ко второму типу, и, наконец, еще четыре: Black Hole (Черная
дыра), Black Friday (Черная пятница), Friday 13 (Тринадцатая пят-
ница) и Вирус замедления є к третьему типу (данный вирус "выреза-
ет" в левом углу экрана черную дыру, удаляет все запускаемые файлы
по пятницам, пришедшимся на 13 число и, кроме того, примерно через
20 мин. после запуска зараженной программы искусственно замедляет
работу компьютера в несколько сотен раз).
Конечно же, такое многообразие названий создает определенные за-
труднения, особенно если учитывать, что данный вирус имеет не-
сколько отличающихся по деталям функционирования штаммов. Поэтому
необходим какой-то выход из создавшейся ситуации. На определенном
этапе среди разработчиков антивирусных средств наблюдалась стихий-
ная тенденция к использованию в качестве основных названий, приме-
няемых известным зарубежным полидетектором SCAN (фирма McAfee
Associates, США); однако он, естественно, запаздывает с классифи-
кацией болгарских вирусов, не говоря уже о вирусах отечественного
изготовления. Поэтому набор обнаруживаемых им вирусов не соответ-
ствует советским условиям, а используемые строки для контекстного
поиска (сигнатуры) часто неудачны (например, дают много ложных
срабатываний). При этом для ранних версий SCAN неоднократно наблю-
дались случаи, когда наиболее актуальные для нас вирусы могут
классифицироваться неверно (как это было с подгруппой Vacsine
