ПРЕДИСТОРИЯ
B книге Игоря Коваля "Как написать компьтерный
вирус" (2000 год, издательство
"Символ-Плюс") рассматривается возможность
реализации загрузочного вируса, способного
функционировать под Windows. Под возможностью
функционирования понимается способность
программы поражать стандартные мишени -
бут-сектора дискет.
Для начала приведем стандартный алгоритм
простого нефайлового вируса ("form",
"stone" , проч.). Перехватив тем или иным
способом процесс загрузки с винчестера,
вирус, если он собирается быть активным
(резидентным) в течении всего сеанса работы
компьютера, использует перехват прерывания(ий) с
целью следить за обращениями
пользовательских программ к дисководу(ам) и,
выбрав момент, перенести свое тело на
дискету в ее BOOT- сектор.
Самое простое, что можно сделать (и было сделано
много раз) в этом направлении – это
перехватить сервис BIOS прерывание int 13h,
предназначенное для работы с жесткими
дисками и дискетами. Такой выбор объясняется
следующими причинами:
* Вирус получает управление перед/после
выполнения программ MBR или BOOT активного
раздела жесткого диска, когда доступными для
перехвата являются только сервисы
BIOS – операционная система еще не
активизировала свои прерывания;
* Большинство пользовательских программ при
работе с дискетами косвенно через
сервисы OS вызывают int 13h и несложные проверки
на номер драйва, сектора и
дорожки позволяют легко идентифицировать момент
заражения дискеты.
Таким образом, все, что необходимо для
функционирования такого класса программ – это
OS, использующая для работы с накопителями
ТОЛЬКО сервисы, предоставляемые BIOS.
ПРОБЛЕМА
Однако что же будет в "плохом" для нас случае,
когда противная операционная система
по тем или иным причинам не желает использовать
стандартные средства для доступа к
драйвам, а норовит использовать свои драйвера?
Игорь Коваль в своей книге исследовал работу
классического резидентного (на int 13h)
вируса под Windows, и обнаружил, что после
загрузки системы вирус перестает быть
активным. Точнее говоря, он становится
псевдоактивным – с винчестером OS продолжает
работать через него, но вот вызовы программ
(автор уделил особое внимание дос-окошкам
– Norton Commander) для работы с дисководами до
него не доходят. Следовательно, вирус
не может активизироваться для заражения дискеты,
поскольку он отлавливает момент
обращения именно к дисководам (скажем, сравнение
номера драйва в регистре dl <=1).
Оказалось, что Windows, по словам автора,
использует свой драйвер для работы с
дискетами, а вот для жесткого диска
"предпочитает" работу стандартными средствами …
(Далее будет показано, что это не совсем так - -
поведение OS более нешаблонно при
выборе стратегии работы с накопителями).
РЕШЕНИЕ И. КОВАЛЯ
* Скачать сырец
Столкнувшись с вышеприведенной проблемой, И.
Коваль пошел по пути использования
перехвата сервиса DOS для работы с дисками, а
именно – int 21h, функции 0eh (смена
текущего диска). Алгоритм триггера активизации
вируса в этом случае даже проще, чем в
случае int 13h – достаточно следить за попытками
выбрать через эту функцию дисковод.
Осталось решить, как перейти от момента загрузки
компьютера к перехваченному
прерыванию int 21h.
Общий принцип перехода заключался в активном
ожидании загрузки DOS и перехвате int
21h после его появления.
Автор показал, что ожидающая программа не может
использовать очевидные на первый
взгляд прерывания int 1ch, int 08h и int09h.
Дело в том, что Windows перестает
использовать стандартные биос-обработчики этих
прерываний в своей работе и восстанавливает
вектор int 21h . Решением оказалось
использование вектора int 16h. Обработчик этого
вектора "остается в живых" после
загрузки, и, более того, вызывется во всех без
исключения программах Windows – даже
таких, как Word.
Схематично работу такого вируса можно
представить следующим образом:
1. При первом получении управления в процессе
загрузки mbr вирус перехватывает int
16h;
2. Обработчик прерывания int 16h следит за
вектором int 21h, вызывая его
недокументированной функцией AX=0babch –
контроль на перехват;
3. Если вектор int 21h не отвечает стандартным
образом, то считается, что необходимо
выполнить перехват int 21h;
4. Обработчик int 21h следит за сменой диска,
контролируя функцию 0eh.
Автор утверждает, что такой вирус нормально
работает в DOS окошках и осталяет "на
будущее" реализацию работоспособной программы во
всех приложениях Windows.
ДАЛЬНЕЙШИЕ ИЗЫСКАНИЯ
* Скачать сырец
Пройдя некоторое время по этому пути, я проверил
утверждения насчет "живучести"
перехватчиков векторов int 16h и int 13h под
Windows. Оказалось – все так и есть,
правда, остается непонятным детальный механизм
перехвата int 21h с вектора int 16h.
Вектор int 16h вызывается не при нажатии любой
клавиши, а только специальных (типа
shift). Видимо, это делается для того, чтобы
биос мог отследить состояние своих
флажков…
Однако далее я задался целью написать
работоспособный под Windows вирус, который:
1. Перехватывает прерывание int 13h при загрузке
и использует только его;
2. Работает во всех задачах (таких, как Word);
3. Не использует особенностей OS (в данном
случае – перехват чисто dos-ого прерывания
int 21h, а является потенциально опасным для
любых OS, работающих по тем или иным
причинам с винчестером через BIOS).
Проблема с активностью вполне решается таким
перехватом. Как уже было сказано,
перехватчик int 13h вызывается при ВСЕХ
операциях с винчестером. Остается поймать
момент обращения к дисководу. На бессмысленность
переодических запросов (а не засунули
в дисковод ли чего- нибудь ?) указал сам И.
Коваль.
Рассмотри процесс форматирования дискеты
(неважно, из виндового приложения или из
NC). OS должна, нет, она просто обязана записать
на него свой новенький бут-сектор. А
где она его может взять ? Конечно, с винта ! А
кто винт контролирует ?! Мы ! Так чего
же мы ждем:
(Скажем, только что с винта был прочитан сектор,
и он сейчас в es:[bx])
push es ; Check for BOOT Signature...
cmp word ptr es:[bx+01feh],0aa55h
jnz @@NoBootRec
cmp byte ptr es:[bx],0ebh
jnz @@NoBootRec ; Real BOOT Record ?!
mov ah,02h ; Try to Infect !!!
mov ds:[si+8],ah ; It works under Windows too
)))
Причем, проверка на наличие команды jmp short (cmp
byte ptr es:[bx],0ebh) вроде и
необязательна... Это я проверил, когда поставил
типа beep внутрь этих проверок, и
следил когда он раздается при загрузке винды,
чтении дискеты ...
Некоторой неожиданностью для меня оказалось то,
что такой алгоритм работает не
только в случае форматирования ! А также и в
случае невинного обращения к дисководу…
Зачем Windows(или еще кто) читает в этот момент
с винчестера загрузочный бут-сектор –
для меня пока загадка. Может, параметры какие
выверяет ?…
ПОЧЕМУ ЭТО ВООБЩЕ РАБОТАЕТ?
Почему Windows вызывает прехватчик int 13h,
инсталлировавшийся при загрузке (из MBR)
во всех своих задачах ?
Как оказалось, вопрос, представлявшийся мне
тривиальным на этапе разработки виря и
прочтении книги И. Коваля, имеет довольно
сложный ответ. Оказывается, что
(нижеизложенное выяснилось при стихийно
возникшей дисскуссии на bugtraq- forum,
участвовали люди с никами :-) и z0, было это
примерно в середине октября 2001 года):
* При загрузке винда определяет, где находится
обработчик int 13h. Если он не в
биос-е, то она считает, что устройство -
нестандартное, и работает с винчестером
через него. Причем неважно, является ли вирус
стеллсом или нет (будет ли разница в
чтении загрузочного сектора через родной драйвер
виндов и int 13h).
* Так работает только 98-ые винды, винды же 95
не вызывают такой перехватчик (!)
* Если же перехватчик указать в autoexec.bat, то
обе винды (и 95 и 98) однозначно
работают через него с диском.
БЛАГОДАРНОСТИ
* Игоря Коваля за замечательную книгу,
позволившую мне глубоко понять механизм
работы Windows;
* всех участников форума bugtruq за их
разъяснения :)
|