информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100За кого нас держат?Атака на InternetСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
 Tailscale окончательно забанила... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / библиотека / internals
БИБЛИОТЕКА
вход в библиотеку
книги
безопасность
программирование
криптография
internals
www
телефония
underground
беллетристика
разное
обзор: избранное
конкурс
рейтинг статей
обсуждение




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




Бут-вирус под 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)

[37694; 11; 7.9]





мини-реклама
Ежедневно срочные события и новости технологий на удобном сайте atinform.com.

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





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