Легенды о полезных вирусах
🕛 11.02.2009, 11:58
Идея о том, что "подобное излечивается подобным", распространенная среди средневековых знахарей, периодически реанимируется применительно к компьютерным вирусам. Она принимает несколько основных форм, которые мы разберем последовательно. Первой по распространенности является идея создания "вируса-защитника" - вирусоподобной программы защиты. Следует отметить, что эта идея носится в воздухе с момента появления первых вирусов, т.е. примерно с 1984 г. (см. гл.1). Исторически, первые фаги создавались именно как вирусы, охотящиеся на тот или иной вирус. Ничего хорошего из этого не получилось. Опыт показал, что распространение вируса-охотника существенно медленнее, чем вируса, за которым охотятся, и эффективность такой погони невелика.Эта идея весьма неудачна и в других своих модификациях. Например, часто предлагается вариант "вируса-контролера", который при заражении программы подсчитывает и запоминает ее контрольную сумму. Тогда при запуске зараженной программы вирус подсчитывал бы контрольную сумму файла, из которого она была считана, и при несовпадении сигнализировал бы о заражении. Вообще говоря, отсутствие подобной проверки - это серьезный дефект MS DOS, и исправлять его стоит именно на уровне операционной системы. Однако тотальное заражение программ вирусом неизбежно ведет к потере работоспособности части программ. Кроме того, заражение всех программ вирусом неизбежно приведет к заметному увеличению размеров программ, поскольку каждой исполняемой программе придется сделать прививку. Если на диске объемом 20M хранится, скажем, 1000 программ и размер прививки составляет 1024 байта, то получается, что в среднем теряется мегабайт дискового пространства. Реально, учитывая квантование дискового пространства по кластерам, эти потери могут оказаться и больше, в особенности, если на диске записано много программ, близких к размеру кластера. Кроме того, процесс поиска очередной "жертвы" не так прост, и будет занимать некоторое время, замедляя загрузку программы. Поэтому закрывать эту "дыру" предпочтительнее с помощью маленькой резидентной программы, перехватывающей прерывание 21h (функцию 4Bh). Возможно, перехват следует выполнить сплайсингом, т.е. врезкой команды JMP в оригинальный обработчик этой команды с тем, чтобы исключить возможность того, что вирус предварительно перехватит прерывание 21h. Кстати, перехватить прерывание 21h вирусу можно просто не дать, как бы он не старался (на этой идее основаны сторожа Check21 и SBM - см. прил.3). Получив управление, эта "заплатка" должна проверять контрольную сумму. Для COM-файлов достаточно проверить первый блок, а для EXE-файлов - заголовок и блок, куда передается управление. При этом для COM-файлов контрольную сумму можно хранить в неиспользуемых байтах оглавления, а для EXE - в соответствующем поле заголовка. Метод подсчета контрольной суммы должен быть параметризуемым. Кстати, аналогичным способом можно закрыть другую "дыру" в MS DOS, связанную с тем, что снятие атрибута READ ONLY не требует подтверждения оператора. При этом можно предусмотреть возможность отключения выдачи запроса с помощью специального, задаваемого пользователем, пароля.
Другой идеей, связанной с поисками "полезных" применений компьютерных вирусов, является автоматическое преобразование программы в какую-то более приемлемую форму. Наиболее часто при этом предлагается автоматическое сжатие программы. Действительно, имеется ряд программ, выполняющих сжатие EXE-файлов, наиболее удачной среди которых является Lzexe, которая обеспечивает экономию порядка 30% на каждом EXE-файле при очень высокой скорости распаковки (практически не увеличивая время загрузки). Идею применить для этой цели вирус высказывал еще Ф.Коэн для обоснования своих работ более 15 лет назад. Теоретически здесь вроде бы "все чисто". Вирус, заражая программы, свертывает их с помощью какого-то метода, а при запуске развертывает. Однако с практической точки зрения эта идея не выдерживает никакой критики. Дело в том, что включаемый в сжатые программы распаковщик должен иметь минимальную длину (330 байтов для Lzexe), что в случае вируса обеспечить невозможно. Более правильным подходом к реализации идеи сжатия информации на диске, если уж добиваться "тотального" ее осуществления, является написание специального дискового драйвера, который, во-первых, не включается в сжатую программу, а, во-вторых, может сжимать не только исполняемые файлы, а и все файлы, помеченные определенным атрибутом. Кстати, такие драйверы были реализованы и успешно применяются. Однако широкое их распространение сдерживает тот факт, что достигаемый эффект составляет порядка 20%, т.е. невелик и не компенсирует все возникающие при этом сложности и неудобства. Более того, для "вируса сжатия" общий эффект может оказаться отрицательным, поскольку на каждой программе вирус должен экономить не менее 12-16К (размер одного кластера, скажем, 4К + собственный размер вируса, который для этого довольно сложного вируса вряд ли составит меньше 8К), что для программ, меньших 64K, т.е. для всех COM-файлов, практически нереально.
Кроме того, если не прибегать к каким-то ухищрениям, то вирусу придется хранить в сжатой программе и достаточно объемную программу упаковки, которая еще больше уменьшает степень сжатия. Ну и, наконец, поскольку часть программ при сжатии теряет работоспособность, то необходим механизм иммунизации, предохраняющий такие программы от заражения.
Конечно, не исключены и какие-то другие возможные приложения "полезного" вируса, однако такая форма коммуникации программ должна учитываться уже при разработке операционной системы, а экспериментирование должно быть ограничено лабораторными экспериментами на новых операционных системах. Возможно, что "вирусоподобные" программы окажутся полезными в каких-то узких областях системного программирования. В то же время автор убежден, что безвредных вирусов для MS DOS, как и для любой операционной системы, ориентированной на широкий круг пользователей, принципиально не существует. По определению, процесс размножения вируса неконтролируем (иначе это, строго говоря, не вирус). При отсутствии противодействия вирус будет "мигрировать" с одного компьютера на другой, попадая туда, где его совсем не ждали. А возникающая в ряде организаций при обнаружении нового вируса паника зачастую наносит больший ущерб, чем сам вирус, парализуя работу на несколько дней. Как бы вирус не был тщательно написан, неизбежно окажется, что он вызывает побочные эффекты типа потери работоспособности части программ, какие-то тонкие взаимодействия с другими резидентными программами. В общем, пользователей ожидают приключения. А ведь лекарство не должно быть опаснее, чем болезнь.
Принципиальной проблемой любой реализации "полезного" вируса является его переносимость. В силу своей природы вирусы сильно зависят от версии операционной системы - значительно больше, чем обычные программы. Опыт показал, что, если зараженная вирусом программа работоспособна в MS DOS версии 3.3, то она может оказаться неработоспособной в версии 4.0 или даже в версии 3.3 с нестандартным командным процессором. При размножении в среде, отличной от "естественной", вирусы, как правило, вызывают потерю работоспособности некоторых резидентных программ, дополнительные побочные эффекты вплоть до зависания операционной системы. А ведь развитие операционной системы может продолжаться десятилетиями. Получается, что при получении новой версии операционной системы все программы нужно срочно лечить, а затем доставать новый штамм. В общем, и здесь вопросов явно больше, чем ответов.
И, наконец, последний аргумент в пользу ограничения экспериментов по созданию "полезных" вирусов специализированными операционными системами связан с тем, что по определению "полезный" вирус будет распространяться свободно. Тем самым, доступность механизма размножения (центральной части любого вируса) делает его общедоступной базой для совсем небезобидных экспериментов. В частности, он легко может быть превращен в троянскую программу, которая, скажем, защищая от некоторых вирусов, сама периодически стирает FAT.
Накопленный автором опыт изучения вирусов позволяет сделать вывод о том, что "безвредных" вирусов не существует, а эксперименты по их созданию для MS DOS связаны со значительным риском "выпустить джинна из бутылки".