информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100Сетевые кракеры и правда о деле ЛевинаАтака на InternetПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Модель надежности отказоустойчивой... 
 Google по-тихому включила изоляцию... 
 25 лет FreeBSD 
 Microsoft покупает GitHub 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / библиотека / internals
БИБЛИОТЕКА
вход в библиотеку
книги
безопасность
программирование
криптография
internals
www
телефония
underground
беллетристика
разное
обзор: избранное
конкурс
рейтинг статей
обсуждение




Подписка:
BuqTraq: Обзор
RSN
БСК
Закон есть закон



The Bat!

Бут-вирус под Windows'98: старые звери в новом лесу
Chingachguk, http://hi-tech.nsys.by/
Опубликовано: dl, 01.06.02 18:55
"Радиомир. Ваш компьютер", #3, 2002

Предыстория

  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;
  • всех участников форума bugtraq за их разъяснения :)
  (C) Chingachguk
  предоставлено автором :)


обсудить  |  все отзывы (0)  

[30172; 11; 7.9]




Rambler's Top100
Рейтинг@Mail.ru





  Copyright © 2001-2018 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach