Карта сайта Хакер в RSS Энциклопедия Хакера PDA версия сайта Почтовые рассылки Хакера    Хакер в Twitter Хакер в ВКонтакте Приложение Хакер для Facebook Хакер на Formspring.me
Журнал Новости Форум Видео Life Xakep Live (блоги)
Bugtrack Статьи Блог Поиск English  
История лайфлоггинга История лайфлоггинга
«Кто мне это сказал?», «Это было в понедельник или во вторник?» Такие вопросы то и дело возникают у нас в головах, и, чтобы ответить на них, приходится напрягать память, пытаться восстановить хронологию событий. Не лучше ли просто отмотать память назад и пересмотреть нужный момент заново?...
Хакер ищет продавцов рекламы Хакер ищет продавцов рекламы
Xakep.ru приглашает стажеров на должность менеджера по работе с клиентами. Резюме присылать по адресу hr@glc.ru....

Хакер № 11/07 (107)

Ядерная физика для начинающих

Крис Касперски

Хакер, номер #107, стр. 107-102-1


Обзор никсовых отладчиков ядерного уровня

Отладчиков уровня ядра под никсы - море, но дельных среди них крайне мало, и нужно быть нереально крутым хакером, чтобы сразу выбрать такой дебаггер, с которым можно действительно отлаживать, а не мучиться. Перепробовав кучу отладчиков, мыщъх решил составить внятный обзор, рассказывающий, чем один отладчик отличается от другого и какой из них звездный, а какой должен отправиться в треш.

Для Linux существует великое множество интегрированных отладчиков, но ни один из них не включен в основную ветвь ядра, что выглядит странно, если не сказать подозрительно, особенно если учесть, что в хBSD-системы ядерный отладчик входит изначально (правда, по умолчанию он задизейблен, и его активация требует перекомпиляции ядра). Причина состоит в том, что Линус Торвальдс (до сих пор стоящий у руля и принимающий решение о включении тех или иных компонентов в ядро) не доверяет интерактивным отладчикам и считает, что у «правильных» программистов потребностей в них просто не возникает. Типа, есть же отладочная печати (смотри man printk), вот ей и пользуйтесь.

Однако с Торвальдсом согласны далеко не все разработчики, и в определенных ситуациях без дебаггера не обойтись, особенно если приходится отлаживать чужие модули, поставляемые без исходных текстов, или ломать защиты, противостоящие отладчикам прикладного уровня. Так что хочет того Торвальдс или нет, но «термоядерные» отладчики для Linux все-таки есть, причем практически все они распространяются в исходных текстах и не требуют денег. Казалось бы, какая проблема - скачал, поставил, запустил... Между тем проблемы есть. Это и плохая совместимость неофициальных отладчиков с различными версиями официальных ядер, и сложность выбора хорошего отладчика из кучи заброшенных проектов. Ситуация усугубляется тем, что различные отладчики предназначены для решения разных задач, и потому на вопрос «Какой ядерный отладчик самый лучший?» даются диаметрально противоположные ответы, зачастую без всяких пояснений! Ну и какая польза от таких советов?!

Типы отладчиков

Классические ядерные отладчики (как для *nix, так и для Windows) требуют наличия двух компьютеров. На одном из них устанавливается отлаживаемое ядро, а на другом - сам отладчик. Обмен данными обычно осуществляется по последовательному порту через нуль-модем, хотя можно встретить и другие варианты. Такие отладчики называются удаленными, и к ним, в частности, относится знаменитый gdb (клиентская часть). Другая часть отладчика находится непосредственно в ядре, и, если ее там нет (а в Linux'е ее нет), у нас ничего не получится. Очевидный недостаток удаленных отладчиков — необходимость приобретения второго компьютера, что далеко не всегда приемлемо (особенно для «домашних» хакеров). Хотя виртуальные машины в какой-то мере снижают остроту этой проблемы.

Локальные отладчики выгодно отличаются тем, что позволяют отлаживать ядро на одной машине с отладчиком. Чаще всего они работают только в текстовом режиме. Поддержка консоли в графическом режиме (не говоря уже об X'ах) требует специальных агентов, работающих далеко не везде и не всегда, а потому в ряде случаев приходится прибегать к удаленной отладке.

Конструктивно отладчики могут быть реализованы либо как неофициальный патч ядра (требующий перекомпиляции последнего), либо как драйвер, загружаемый в ядро «на лету». Примером отладчиков первого типа служит KDB, второго — LinIce.

Однако, независимо от особенностей своей реализации, все Linux-отладчики страдают хронической проблемой совместимости с ядрами, поскольку разработчики ядра не координируют свои действия с разработчиками отладчиков, и потому дебаггеры поддерживают только фиксированный набор версий ядер, причем поддержка новых версий, как правило, происходит с большим опозданием. Кстати, у xBSD таких проблем нет вообще, поскольку ядерный отладчик разрабатывается (и поставляется) вместе с самим ядром.

Использование отладочных возможностей VMware

Начиная с версии 6.0 RC2, в популярной виртуальной машине VMware появился механизм Record/Replay, позволяющий (помимо прочих возможностей) осуществлять удаленную ядерную отладку даже для тех операционных систем, которые поставляются без интегрированного отладчика: Linux, xBSD с выключенным отладчиком, NT и т.д.

Просто добавляем в vmx-файл (описывающий конфигурацию виртуальной машины) строку «debugStub.listen.guest32=1» (или «debugStub.listen.guest64=12» для 64-разрядных платформ). После этого в файле vmware.log появляется следующая запись: «VMware Workstation is listening for debug connection on port 8832», означающая, что виртуальная машина слушает порт 8832, с которым готова общаться по gdb-протоколу. Остается запустить сам gdb, приконнектиться к порту и приступить к отладке безо всяких танцев с бубном, без наложения заплаток, без перекомпиляции ядра и без загрузки специальных драйверов/модулей.

Отладчик gdb может быть запущен как на хосте (основной операционной системе), так и на соседней виртуальной машине. Для отладки нам потребуется два комплекта ядер. Одно - установленное на отлаживаемой системе, и другое - установленное на машине (реальной или виртуальной), где работает gdb. Отлаживаемое ядро может быть сжато и пострипано, а вот ядро для gdb в обязательном порядке должно быть без компрессии и желательно с отладочной информацией. Кроме того, необходимо, чтобы версии обоих ядер совпадали, а файл System.map был в наличии.

Пример работы с gdb представлен ниже:

Отладка ядра Linux под VMware

# Запускаем gdb

% gdb

# Указываем путь к несжатому 32-битному ядру

(gdb) file vmlinux-2.4.69-27.EL.debug

# Либо к несжатому 64-битному ядру

(gdb) file vmlinux-2.6.96-17.EL.debug

# При необходимости переводим gdb в 64-разрядный режим

(gdb) set architecture i386:x86-64

# Коннектимся к отлаживаемому ядру

(gdb) target remote localhost:8832

# Все! С этого момента можно начинать отладку ядра.

Естественно, ядро, запущенное на эмуляторе, видит только виртуальное железо. Исключение составляют USB-устройства, жесткие диски и сетевые карты, к которым VMware предоставляет прямой доступ, однако, например, отладить драйвер видеокарты таким образом уже не получится.

Использование отладочных возможностей QEMU

Эмулятор QEMU (fabrice.bellard.free.fr/qemu) также позволяет отлаживать ядра без интегрированных отладчиков, но, в отличие от VMware, он бесплатен и распространяется вместе с исходными текстами. Пример командной строки, реализующей форсированную отладку, приведен ниже:

Отладка ядра Linux без интегрированного отладчика под QEMU

# Запускаем QEMU с ядром, которое мы собираемся отлаживать

$ qemu -kernel /boot/bzImg -append "root=/dev/hda" -std-vga -m 256m -s -hda hdd.img &

# Запускаем gdb на основной машине и коннектимся на порт 1234

$ gdb

(gdb) target remote localhost:1234

# Подключаем образ ядра (должен совпадать с отлаживаемым ядром)

(gdb) file vmlinux

Novell Linux Kernel Debugger (NLKD)

На сегодняшний день NLKD является, пожалуй, самым продвинутым и мощным ядерным отладчиком для Linux, поддерживающим как локальную, так и удаленную отладку. К другим его достоинствам можно отнести бесплатность и наличие исходных текстов. Однако он работает только с SUSE Linux Enterprise Server v9 SP1/SP2 и требует перекомпиляции ядра, что является существенным недостатком, ограничивающим область его применения. Зато NLKD имеет документированный расширяемый интерфейс плагинов и свободно работает как в текстовом, так и в графическом режиме. Скачать последнюю версию отладчика (вместе с документацией) можно по ссылке: forge.novell.com/modules/xfmod/project/?nlkd.

Отладчик KDB

KDB – самый популярный ядерный отладчик для Linux-систем. Распространяется в исходных текстах на бесплатной основе. Доступен по адресу oss.sgi.com/projects/kdb. Реализован в виде патча для ядра версий 2.[234]. Его установка происходит следующим образом:

$ cd /usr/src/linux

$ patch -p1 < ~/kdb-xxx

$ make menuconfig

Активируем флаги CONFIG_KDB и CONFIG_FRAME_POINTER, перекомпилируем ядро и радуемся жизни.

KDB поддерживает локальный и удаленный режимы отладки и работает на процессорах семейства x86 и IA64, однако во время локальной отладки имеет большие проблемы с различными графическими режимами и некоторыми контроллерами клавиатур, что не есть хорошо. Поэтому в ряде случаев использование NLKD оказывается все же предпочтительнее.

Переход в текстовый режим осуществляется по комбинации <Alt-Ctrl-F1>, а возвращение - по <Alt-Ctrl-F7>. Клавиша <Pause> вызывает всплытие локальной консоли отладчика (аналог <Ctrl-D> в SoftICE), позволяя нам просматривать память, устанавливать точки останова, дизассемблировать машинный код и т.д. Одним словом, практически все как в SoftICE. Вот только KDB не предоставляет возможности отладки на уровне исходных текстов, что является существенным недостатком для обычных разработчиков, но нас, хакеров, совершенно не волнует, поскольку, если бы у нас были исходные тексты, разве бы мы стали часами торчать в отладчике?!

Отладчик KGDB

Читая обзоры, можно подумать, что KGDB (kgdb.linsyssoft.com) - это конкурент или альтернатива KDB. На самом деле это не так. KGDB представляет собой интегрированный отладчик удаленного (не локального!) типа, поддерживающий несколько версий ядер: от 2.4.6 до 2.6.0 и работающий на платформах i386, x86_64, PPC и S390. Устанавливается он путем наложения патча ядра с последующей перекомпиляцией. KGDB реализует только серверную часть, а в качестве клиента обычно используется gdb или другой отладчик, поддерживающий его нуль-модемный протокол.

Если на удаленной машине (там, где находится gdb) положить ядро, откомпилированное с отладочной информацией (ключ '-g'), мы получим отладку на уровне исходных текстов, обеспечиваемую средствами gdb, но отнюдь не KGDB, как утверждается в некоторых руководствах.

Отладчик LinIce

LinIce (www.linice.com) представляет собой своеобразную пародию на Soft-ice под Linux, конструктивно реализованную как загружаемый модуль ядра, не требующую ни наличия второй машины, ни перекомпиляции, что дает ему 100 очков вперед. К сожалению, у LinIce имеется множество проблем. Например, не поддерживаются ядра >=2.6.9 и видеорежимы Super-VGA, frame-buffer.

Тем не менее LinIce вполне пригоден для хакерства, особенно если необходимо что-то быстро сломать, а времени/желания/возможности перекомпиляции ядра у нас нет. Однако следует помнить, что по своим функциональным возможностям LinIce - самый бедный отладчик из всех рассмотренных выше, и потому для серьезного хакинга все-таки лучше поставить NLKD или KDB.

Ядерная отладка в xBSD-системах

Ядро xBSD-систем включает в себя интегрированный отладчик по имени DDB, поддерживающий как локальную, так и удаленную отладку. По умолчанию ядро собирается без отладчика, и, чтобы исправить эту вопиющую несправедливость, следует добавить строку «options DDB» в файл конфигурации ядра (который обычно находится в /usr/src/sys/i386/conf/GENERIC) и произвести перекомпиляцию.

Вызывать отладчик можно различными путями. Если в приглашении загрузчика указать boot -d, мы попадем в DDB на самой ранней стадии загрузки ядра, до начала распознавания и подключения устройств, что очень полезно для отладки драйверов. А вот если хочется взломать какую-нибудь программу, то для вхождения в DDB с консоли (как текстовой, так и графической) достаточно отдать команду sysctl debug.enter_debugger=ddb или (если в конфигурационном файле обозначена опция options BREAK_TO_DEBUGGER) нажать на <Ctrl-Alt-Esc>.

При наличии второй машины можно осуществить удаленную отладку, если возможностей локальной вдруг окажется недостаточно (мне трудно представить такую ситуацию, но чего в жизни не случается). Согласно официальной документации по FreeBSD, для этого нам понадобится две копии ядра: одна — установленная на отлаживаемой системе (пострипанная), другая — удаленная, которая должна быть откомпилирована с отладочной информацией и размещена в одном каталоге с gdb. Кроме того, версии ядер должны совпадать. Кстати, в качестве удаленной системы не обязательно использовать именно FreeBSD. Пригодна любая система, под которую имеется порт gdb (например, Linux или даже NT), главное — залить на нее копию ядра и загрузить ее в gdb через команду file.

Но, прежде чем запускать gdb, необходимо соединить обе машины COM-шнурком, причем в файле конфигурации ядра потребуется исправить строку, отвечающую за параметры этого порта (она находится в строке «device siox», где x – номер последовательного порта, если считать от нуля), уставив флаги в значение 0x80.

Включаем отлаживаемую машину. В командной строке загрузчика набираем boot -d, чтобы остановить загрузку системы и войти в отладчик. Включаем удаленную машину и пишем в командной строке gdb -k kernel (или же kgdb kernel при использовании KGDB), где kernel – имя файла ядра. Цепляемся отладчиком к последовательному порту, набрав следующую команду: target remote /dev/cuaa0, где cuaa0 - первый последовательный порт. После этого возвращаемся к отлаживаемой машине (которая находится в состоянии ожидания загрузки внутри DDB) и говорим gdb, сообщая системе, что мы передаем бразды правления удаленному отладчику gdb. Вернуть управление обратно можно при помощи той же самой команды gdb, фактически представляющей собой триггер между локальным и удаленным режимом отладки.

Заключение

Разумеется, мы описали далеко не все существующие ядерные отладчики и так и не выяснили, какой же из них все-таки самый лучший. Но ведь отладчик — это не религия. Использование нескольких отладчиков - вполне нормальное явление.

Лично мыщъх предпочитает такую стратегию: если ломаемая программа запускается под FreeBSD 4.5 (любимая версия мыщъх'а), то задействуется DDB, если же нет, то загружается виртуальная машина с SuSE Linux, где установлен NLDK. Под остальными системами приходится использовать KGDB, соединенный с соседней виртуальной машиной, на которой запущен gdb. А LinIce у меня используется в основном для несложных экспериментов, например для наблюдения за руткитами и прочей малварью.

Магические SysRq-клавиши

Ядро Linux, начиная с версии 2.2, поддерживает ряд магических комбинаций клавиш, вызываемых по <Alt-SysRq-Key>, где <Key> – магическая клавиша. Магические клавиши полезны для отладки и борьбы с малварью (например, клавиша <k> убивает все процессы в текущей консоли).

  • <r> – отключение сырого клавиатурного ввода;
  • <k> - процедура Secure Access Key (сокращенно SAK), убивающая все процессы в текущей виртуальной консоли;
  • <b> - немедленная перезагрузка без размонтирования дисков;
  • <c> - создание crashdump'а, пригодного для последующего анализа;
  • <o> - нормальный шатдаун системы;
  • <s> - сброс дисковых кэшей для всех смонтированных томов;
  • <u> - перемонтирование всех томов с правами только на чтение;
  • <p> - отображение содержимого регистров процессора;
  • <t> - отображение текущего списка процессов;
  • <m> - отображение использования памяти;
  • <0> - <9> — установка уровня отладочного вывода printk;
  • <e> - посылка сигнала SIGTERM всем процессам, кроме init;
  • <i> - посылка сигнала SIGKILL всем процессам, кроме init;
  • <l> - посылка сигнала SIGKILL всем процессам, включая init;
  • <h> - вывод списка магических SysRq-клавиш.

Полный перечень магических клавиш может быть получен по следующей ссылке: www.gelato.unsw.edu.au/lxr/source/Documentation/sysrq.txt.

Содержание


ВИДЕО К ЭТОМУ НОМЕРУ

Под колпаком у админа
Чем больше компьютеров находится на предприятии, тем больше времени затрачивается на их обслуживание и содержание. Создать в этом случае безопасную и управляемую среду очень даже непросто. Установка Active Directory - только первый шаг н...

Как снять Dump с UPX
Отвечаю на твой сложный и наболевший вопрос: как снять дамп с программы, запакованной простейшим пакером upx....

Строим телефонную сеть
Asterisk обладает всеми функциями классической АТС и даже больше. Вот только некоторые из них: центр обработки вызовов, голосовая почта, возможность проведения конференций, что в итоге делает его мощной и легкорасширяемой платформой для...

Детские ошибки Monalbum
Вот ведь какое дело. Получить шелл опытный хакер может всего за пару минут, достаточно лишь использовать найденную ошибку в популярном скрипте. Хакер начинает с поиска багов на своем локальном компьютере и после недолгих ковыряний обнар...

Грамотно поднимаем баунсер
В этом ролике ты увидишь, как хакер поднимает собственный сокс на ломанном сервере. Сначала взломщик коннектится к удаленному серверу посредством ssh, заливает на него Bouncer и запускает его на определенном порту в режиме демона. Процеду...

Разделка баз данных
В этом ролике ты увидишь, как хакер, получивший несанкционированный доступ к базе данных одного из забугорных ресурсов, сливает админские аккаунты. Проблема в том, что акки лежат среди прочего мусора и необходимо привести информацию в удо...





Предыдущие номера


Предупреждение: Вся информация представлена исключительно в образовательных целях.
Ни авторы, ни редакция не несут ответственности в случае ее использования в противозаконных целях.

    Rambler's Top100