THE CREATURES #08
Наверное, это единственный файл из всего номера, где говориться о каких-либо
технологиях довольно конкретно...
ФОРМАТ MBR И ТИПОВЫЕ МЕТОДЫ ПОСЕЛЕНИЯ
В отличие от хитрых файловых систем, сжатых и кешированных дисков, извратов с
мультисистемным переключением и тд и тп Master Boot Record всегда был и
останется примерно одинаков. Связано это с тем, что грузит его BIOS, который
далёк от вышеперечисленных фенечек (хотя может и будет потом какой-нибудь
"Designed for Windows 2000" ??? ... )
Общепринято, что MBR грузит и запускает BOOT, а вот уже BOOTы разных систем
могут сильно отличаться. Я самолично анализировал MBR Windows98SE. Он немного
отличается от MBR'а досового, кстати, в виндах он слегка оптимизирован.
Особенно меня прибило то, что в русской версии виндов MBR выдаёт сообщения
НА РУССКОМ!!! Причём в виндовой кодировке!!! Не верите? Посмотрите сами...
Итак, что же делает BIOS? Он просто считывает первый сектор винта в память
по адресу 7C00h и передаёт ему управление. Находящийся там код должен сам
настроить сегментные регистры и стек. Собственно вирь должен поместить себя
в память, а затем считать и запустить MBR самостоятельно. Сам же он может
поставить на себя int 13h. Чтобы не затёрли в памяти, можно обломить её всем,
просто уменьшив размер доступного RAMа путём изменения слова по адресу 00413h,
где хранится размер доступной памяти в килобайтах (как я понял).
НЕРЕЗИДЕНТНЫЕ ВИРУСЫ ПОД WIN95/98
Если писать всё подробно, с примерами и всем таким, то на это уйдёт слишком
много килобайт, ну а если честно, то мне просто влом описывать всё в деталях,
так как простейший виндовый нерезидент намного сложнее нерезидента досового.
Начнём с того, что заменитый де'Билл неплохо извратился, и творческой группе
VLAD :) пришлось изрядно помучиться, разгребая его дерьмо. Выпущеный Bizatch
оказался довольно глючен, к тому же он не работал под другие версии виндов,
подобных 95-м.
Причина такого облома кроется в дебильном способе предоставления системных
функций программе. Абсолютно все операции БГ предлагает совершать при помощи
процедур API, хранящихся в DLL файлах! Причём все API-функции необходимо
указывать заранее в PE-хэдере (а размера он немеряного), даже самые простые,
чтобы эта грёбаная система всё что надо подгрузила, настроила и выставила.
Но мы тоже не aidstest'ом биты - не слишком радуясь перспективе прямого
использования VxD, настроим адреса апишек сами! Собственно, при подготовке
виря вас ждут две жопы - поисх апишек и вычисление адресов в хэдере.
Ну а вообще же относительно простых способов заражения PE придумали два.
Поскольку код и данные в таких файлах представлены в виде неких "объектов",
то отсюда логически понятно, что либо вирус находится в собственном объекте,
либо приписывается к чьему-нибудь.
Что такое "объект" в PE-хэдере? Он не имеет ничего общего с объектно-
ориантированным программированием или чем-то подобным. По сути это просто
блок любых данных, которые грузятся в свой сегмент и имеют некие права
и свойства (флаги). То есть это может быть исполняемый код, действительно
данные и даже т.н. "ресурсы", подключаемые к PE-файлам.
На один из объектов в EXE'шке будет указывать entry point RVA (relative
virtual address). Таким образом наиболее простых методов оказывается два -
либо создание собственного (вирусного) объекта, либо приписывание к
последнему объекту. И в том, и в другом случае Entry Point придётся
переставлять.
На самом деле я придумал ещё три относительно простых способа. Пока на
практике реализован только стандартный - с добавлением объекта. Смотрите
анонс в файле номер 001 - в обещаемом издании будет побольше КОНКРЕТНОЙ
информации о винде.
ФАНТАСТИЧЕСКИЕ ИДЕИ
Последняя "техническая" статья в TheCreatures. Эти идеи навеяны размышлениями
над будущим киберпространства - каковы будут операционные системы и сети,
каковы системные сервисы в отношении пользователя и приложений.
Дело в том, что усложнение системы весьма выгодно в отношении вирмейкинга.
Возможно в дальнейшем удасться создавать вирусы таких типов, каким сейчас и
названия-то нет.
Возьмем несколько уроков у господа бога? Как известно, прототипом
многоклеточных животных были колониальные бактерии. Как можно реализовать
кибер-колонию? Я предлагаю два варианта: либо колония строится на одном
"материнском" коде, либо все члены колонии равны между собой. В чём
преимущество первого метода? Вообще в идеальном случае колония планируется
по типу муравейника - есть вирус-матка, крупный код, единственный на
компьютере и тщательно замаскированный. Он продуцирует небольшие стандартные
программки, цепляющиеся к тем или иным носителям. По задумке такие программки
должны выполнять роль спор. Но вот облом - откуда-же они будут брать код
для построения матки на новом компьютере? Тут есть несколько вариантов.
Например, матка может состоять из модулей заражения разных носителей.
Тогда каждая спора будет представлять один модуль. Но такой метод очень
неустойчив, слишком извращён и совсем уж неэффективен. Лучше конечно
брать процедуры из каких-нибудь библиотек (может, из dynamic link?)
Хотя, пожалуй, лучше просто учитывать, что на компьютере могут быть ещё
копии себя же (хотя учитывать это приходится всегда - вспомните тесты на
резидентную копию и на зараженность файла). Вообще есть мнение, что на одном
компьютере должна быть максимум одна копия вира. Но хорошо защищённая.
Были также идеи насчёт upgrade вируса. Пример - вирь имеет некое числовое
значение - версию. При попытке заражения данного компьютера, он проверяет,
а нет ли там своей копии (ну это везде так), а потом смотрит её версию (а вот
это уже новшество). Если версия совпадает, то делать ничего не надо. Если
версия меньше, то можно минимум записаться ВМЕСТО неё (а не вместе с ней),
а максимум - послать ей данные для upgrade до своей версии. Прикол ещё в том,
что, в случае обнаружения более поздней версии, можно получить upgrade от неё.
Пожалуй, подобная стратегия может быть применима для полноценных сетевых
вирусов. Опять таки повторяю - это чисто ТЕОРЕТИЧЕСКИЕ рассуждения, пока не
имеющие отношения к практике.
