Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
mr.save

Фундаментальные основы хакерства. Знакомство с отладчиком

Recommended Posts

Помимо дизассемблирования, существует и другой способ исследования программ — отладка. Изначально под отладкой понималось пошаговое исполнение кода, также называемое трассировкой. Сегодня же программы распухли настолько, что трассировать их бессмысленно — мы моментально утонем в омуте вложенных процедур, так и не поняв, что они, собственно, делают. Отладчик не лучшее средство изучения алгоритма программы — с этим эффективнее справляется интерактивный дизассемблер (например, IDA).

Способности отладчиков

Первым делом надо разобраться в перечне основных функциональных возможностей типовых отладчиков (без этого невозможно их осмысленное применение):

  • отслеживание обращений на запись/чтение/исполнение к заданной ячейке (региону) памяти, далее по тексту именуемое бряком (брейком);
  • отслеживание обращений на запись/чтение к портам ввода-вывода (уже неактуально для современных операционных систем, запрещающих пользовательским приложениям проделывать такие трюки, — это теперь прерогатива драйверов, а на уровне драйверов реализованы очень немногие защиты);
  • отслеживание загрузки DLL и вызова из них таких-то функций, включая системные компоненты (как мы увидим далее, это основное оружие современного взломщика);
  • отслеживание вызова программных/аппаратных прерываний (большей частью уже неактуально — не так много защит балуется с прерываниями);
  • отслеживание сообщений, посылаемых приложением окну;
  • и, разумеется, контекстный поиск в памяти.

Как именно это делает отладчик, пока понимать необязательно, достаточно знать, что он это умеет, и все. Куда актуальнее вопрос, какой отладчик умеет это делать.

Герои прошлого

В оригинальной книге Крис в качестве отладчика использовал широко известный среди хакеров старой школы SoftICE. Это действительно мощный, до сих пор не превзойденный инструмент — его неоспоримым преимуществом была возможность отладки ядра Windows с помощью одного компьютера. Между тем не без давления Microsoft в 2006 году его разработку прекратили. А поскольку SoftICE очень сильно зависит от операционной системы Windows, в ее более поздних версиях он просто не запустится. Последней версией Windows, в которой работал SoftICE, была Windows XP SP2, в SP3 уже нет.

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

Хакеры, конечно, приуныли, но не стали посыпать голову пеплом, а начали изобретать альтернативные отладчики — мы увидели старт сразу нескольких интересных проектов, но какую картину мы в итоге получили? Очень печальную — сегодня нет ни одного нового хорошего отладчика! Например, в те времена передовым был коммерческий Syser от китайских разработчиков. Ему пророчили светлое будущее, думали, что он заменит в наших сердцах SoftICE, однако где он сейчас? Его нет! То есть его, конечно, можно найти на файловых свалках, но он давно не развивается.

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

На текущий момент по большому счету у хакера есть выбор только из двух по-настоящему годных отладчиков: WinDbg и OllyDbg. Последний предназначен только для исследования приложений пользовательского режима, тогда как с помощью первого можно также заниматься ядерной отладкой Windows. В этом случае придется использовать два компьютера, объединенных COM-шнурком, локальной сетью или USB-проводом.

 

Современный инструмент кодокопателя

Когда-то хакеры пренебрегали WinDbg, но со временем он вырос и стал действительно мощным и полезным инструментом кодокопателя. Не стоит забывать, что именно он используется командой разработки Windows. Для него можно изготавливать расширения путем подключаемых DLL. Начиная с Windows XP, движок отладки включен непосредственно в операционную систему. Он состоит из двух DLL: dbgeng.dll и dbghelp.dll. Кроме непосредственно средств отладки, среди которых и WinDbg, движок отладки используется в том числе «Доктором Ватсоном» (drwtsn32.exe).

Средство отладки для Windows состоит из четырех приложений, использующих dbgeng.dll:

  • cdb и ntsd — отладчики пользовательского режима с консольным интерфейсом. Они различаются только одним: при запуске из существующего консольного окна ntsd открывает новое консольное окно, a cdb этого не делает;
  • kd — отладчик режима ядра с консольным интерфейсом;
  • WinDbg может использоваться как отладчик либо пользовательского режима, либо режима ядра, но не одновременно. Утилита предоставляет графический интерфейс.

Следовательно, непосредственно WinDbg — это только оболочка для отладки с помощью движка.

Второй — вспомогательный файл dbghelp.dll, который используется внешними тулзами для исследования внутренностей Windows. Под внешними тулзами мы понимаем, например, OllyDbg, Process Explorer от Sysinternals Марка Руссиновича.

У WinDbg есть две версии: классическая и UWP. Первая устанавливается вместе с набором тулз Debugging Tools for Windows. Этот набор содержит две версии WinDbg, соответственно предназначенные для отладки 32-разрядных и 64-битных приложений. UWP-версию можно скачать из Windows Store, она имеет только 32-битную версию. Обе 32-разрядные версии абсолютно равноценны, не считая того, что в UWP-версии имеется продвинутый пользовательский интерфейс «Десятки» (кстати, весьма удобный при работе на большом экране).

Для наших экспериментов я буду применять последний. Разницы в их использовании практически нет, разве что могут немного различаться команды в пользовательском интерфейсе (именно надписи на элементах интерфейса, но не команды встроенного языка — их логическая нагрузка не изменяется).

 

Способ 0. Бряк на оригинальный пароль

С помощью WinDbg загрузим ломаемый нами файл passCompare1.exe через пункт меню Launch executable или Open Executable в классическом приложении. В дальнейшем я не буду приводить аналоги команд — не маленькие, сами разберетесь.

Сразу после открытия исполняемого файла WinDbg загрузит приложение, в окне Disassembly отладчика появятся дизассемблированные команды, а в окне Command отобразятся результаты их выполнения.

После создания окна приложения еще до вывода каких-либо данных выполнение прерывается на инструкции int 3 — это программная точка останова. Многие новички считают, что выполнение программы начинается с функции main или WinMain. Этому их учат в школе, либо они сами черпают такие сведения из учебников по C. Конечно, это неправда. Прежде чем попасть в функцию main конкретного приложения, процессор зарывается в дебри системного кода загрузчика образов, выполняет горы инструкций инициализации приложения внутри Windows, подключения различных библиотек и прочего. Поэтому такой бряк не означает вход в main нашей программы. Если взглянуть в окошко дизассемблера, мы увидим, что прерывание произошло в системной функции LdrpDoDebuggerBreak модуля ntdll.

Первым делом загрузим отладочную информацию для компонентов операционной системы. Для этого в командную строку введем

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

Эта команда определяет папку, указанную в параметре, куда отладчик при необходимости загрузит отладочные символы для подсистем Windows. Затем надо отправить команду для загрузки или обновления файлов:

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

После этого WinDbg загрузит нужные данные с серверов Microsoft.

Кроме того, можно воспользоваться уже имеющейся отладочной информацией, для этого существует команда .sympath+ <путь к директории>. Если файл с отладочными символами находится в одной папке с исполняемым файлом, он подхватится автоматически. Еще можно взять файлы исходного кода, но в таком случае проще воспользоваться отладчиком, входящим в среду разработки.

Таким образом, если натравить отладчик на дебажную версию passCompare1 и при достижении первой точки останова поставить бряк на функцию main, написав

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

то по команде g мы продолжим выполнение и, когда отладчик достигнет поставленной точки останова (начало функции main), в окне дизассемблера увидим, что листинг разделен на сегменты, в заголовке которых находятся имена функций (в частности, main). В релизной версии этого не будет. Если же мы поставим точку останова по адресу начала модуля + адрес точки входа, то мы попадем не в начало функции main, а в системный загрузчик — функцию mainCRTStartup, подготовленную компилятором.

Кроме Microsoft, мало кто предоставляет отладочные символы, так что не будем привыкать к легкой жизни. Тем более WinDbg специально заточен для отладки программ без отладочной информации и исходного кода — применим его по назначению. Между тем, если приглядеться к окошку дизассемблера повнимательнее, можно заметить, что в отличие от дизассемблера dumpbin, который мы использовали в прошлой статье, WinDbg распознает имена системных функций, чем существенно упрощает анализ.

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

Точки останова могут быть двух типов: программные и аппаратные. С первыми мы уже встречались. В программе их может быть любое количество. Для своей работы они модифицируют память исполняемого процесса, то есть в том месте, где должен стоять бряк, отладчик запоминает ассемблерную инструкцию и заменяет ее на int 3. Из-за того что программная точка останова изменяет память, ее не везде можно установить. В этом заключается ее основной недостаток.

Главная команда для установки программной точки останова — bp. Для получения списка установленных точек служит команда bl, а для удаления — команда bc, параметром которой является индекс точки останова. Звездочка в качестве параметра удаляет все бряки. Команды be и bd, соответственно, включают и выключают брейк-пойнты.

Аппаратных точек останова всегда четыре, их количество не зависит от разрядности процессора (в процессоре присутствуют восемь регистров отладки (DR0 — DR7), но только первые четыре могут быть использованы для хранения адресов точек останова).

Аппаратные бряки могут ставиться в любое место памяти процесса. Таким образом, они лишены недостатка программных бряков. Остальные регистры предназначены для хранения условий доступа — срабатывания точек останова, например чтение, запись, исполнение. Малое количество — основной недостаток аппаратных бряков. Для установки аппаратной точки останова используется команда ba с тремя параметрами: тип доступа, размер и адрес.

К текущему моменту мы рассмотрели небольшой список команд внутреннего языка отладчика WinDbg. Наверняка ты обратил внимание на их запись. В языке отладчика присутствуют три вида команд:

  • встроенные команды служат для отладки процесса и записываются без лидирующего символа, к таким командам относятся g, bp, bd;
  • метакоманды управляют работой отладчика, перед ними ставится символ точки, например .reload, .symfix, .cls;
  • команды-расширения, загружаемые из внешних DLL, имеют в начале символ восклицательного знака, например !heap, !dh.

 

Поиск адреса

Давайте попробуем наскоро найти защитный механизм и, не вникая в подробности его функционирования, напрочь отрубить защиту. Вспомним, по какому адресу расположен в памяти оригинальный пароль. Заглянем в дамп секции .rdata, где хранится пароль . Оригинальный пароль myGOODpassword находится по смещению 0x402100. Попробуем вывести находящиеся по этому адресу в памяти данные:

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

Cуществует большое количество команд для отображения содержимого памяти. Мы использовали dc, потому что она показывает значения двойных слов и символы ASCII.

Что мы видим? Неинициализированные данные. Раньше (до «Висты») кодокопателям было проще. Windows загружала образы в виртуальную память по определенному при компиляции адресу. Для проверки достаточно несколько раз запустить приложение под Windows XP (построенное соответствующим компилятором), между запусками понадобится перезагрузка системы, так как без нее и «Десятка» будет загружать одно и то же приложение по одному и тому же адресу и сравнивать адреса начала модуля, полученные с помощью того же SoftICE по команде mod -u. Соответственно, секции тоже размещались по одним и тем же адресам. А теперь нам придется самим искать секцию .rdata уже не на диске, а в памяти. Легко сказать, но сделать еще проще!

Найдем, по какому адресу расположен наш модуль в памяти. Для этого в отладчике введем lmf m passcompare1 (второй параметр — имя модуля, адрес которого надо определить). В результате на своем компе я получил:

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

Отсюда следует, что начало нашего модуля находится по адресу 0xCF0000. После каждой перезагрузки системы модуль конкретного приложения проецируется в различные адреса. Теперь выведем карту памяти нашего модуля, сведения обо всех секциях PE-файла: !dh passCompare1. Вывод команды довольно объемный.

!dh — в некотором роде аналог команды map32 из SoftICE, при этом первая предоставляет больше сведений. Найдем в выводе описание целевой секции .rdata:

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

Здесь нас интересует четвертая строчка — виртуальный адрес. Теперь можно найти, где в памяти располагается .rdata, для этого надо сложить начальный адрес модуля и виртуальный адрес секции. Посмотрим, что там находится:

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

Уже теплее: читаемые символы. Пройдем глубже в секцию и распечатаем диапазон адресов:

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

А вот и наш пароль по адресу 0xCF2100! Дамп памяти процесса:

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

Выровняем вывод так, чтобы наш пароль отобразился с начала строки. Для этого к текущему адресу 0xCF2100 надо прибавить 8 — количество символов для смещения. Это будет его фактический адрес. Проверим наше предположение:

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

Есть контакт! Задумаемся еще раз: чтобы проверить корректность введенного пользователем пароля, защита, очевидно, должна сравнить его с оригинальным. А раз так, установив точку останова на чтении памяти по адресу 0xCF2108, мы поймаем за хвост сравнивающий механизм.

Сказано — сделано. Поставим аппаратный бряк, так как программный подарит нам ошибку доступа к памяти, возникающую из-за попытки записи в секцию, доступную только для чтения, каковой .rdata и является. А программному бряку надо модифицировать память.

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.
  • Первый параметр — тип доступа (r — чтение);
  • второй параметр — количество байтов, подвергаемых операции;
  • последний параметр — адрес.

По команде g продолжим отладку и введем любой пришедший на ум пароль, например KPNC++. Отладчик незамедлительно «всплывет»:

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

В силу архитектурных особенностей процессоров Intel бряк срабатывает после инструкции, выполнившей «поползновение», то есть EIP указывает на следующую выполняемую команду. В нашем случае — jne passCompare1!main+0x62, а к памяти, стало быть, обратилась инструкция cmp dl, byte ptr [ecx]. А что находится в dl? Поднимаем взгляд еще строкой выше — dl, byte ptr [eax].

Можно предположить, что ECX содержит указатель на строку оригинального пароля (поскольку он вызвал всплытие отладчика), тому подтверждение — первая строчка листинга, где в этот регистр помещается смещение 0xCF2108, по которому, как мы помним, находится эталонный пароль. В EAX в таком случае будет указатель на введенный пользователем пароль. Проверим наше предположение.

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

И правда — догадка оказалась верна. Теперь вопрос: а как это заломить? (Не уверен, что в современном хакерском жаргоне есть слово «заломить», но Юрий ссылается на классиков. — Прим. ред.) Вот, скажем, JNE можно поменять на JE. Или еще оригинальнее — заменить EAX на ECX. Тогда оригинальный пароль будет сравниваться сам с собой!

Продолжим трассировку и с помощью команды t пройдем по условному переходу (или внутрь функции). Мы тут же попадаем на инструкцию, выталкивающую Wrong Password на вершину стека:

Скрытый контент

    Дайте реакцию на этот пост, чтобы увидеть скрытый контент.

Знакомые места! Помнишь, как мы посещали их дизассемблером? После этой инструкции вызывается функция printf. А если поднять взгляд на три строчки выше, мы обнаружим инструкцию test eax, eax, которая выполняет проверку на совпадение. Алгоритм действий прежний — запоминаем адрес команды TEST для последующей замены ее на XOR или записываем последовательность байтов.

Погоди! Не стоит так спешить! Можно ли быть уверенным, что эти байтики по этим самым адресам будут находиться в исполняемом файле? В Windows XP и версиях до нее на это в подавляющем большинстве случаев можно было хотя бы надеяться, но проверка не была лишней, поскольку, хотя системный загрузчик размещал модули по заранее определенным адресам, существовали хитрые защитные механизмы, загружавшие один и тот же модуль по двум разным адресам одновременно. В «Десятке» такой трюк не прокатывает, Windows видит, что это один и тот же модуль, и размещает его в памяти лишь единожды.

Тем не менее в «Десятке» мы даже не можем надеяться, что расположенные по определенным адресам байтики, найденные в памяти с помощью отладчика, будут по тем же адресам располагаться в файле на диске. Ибо в «Висте» и последующих системах в дело вступает механизм ASLR (address space layout randomization), который случайным образом изменяет расположение в адресном пространстве процесса важных структур данных. ASLR в некоторых случаях вполне успешно борется с переполнением буфера, возвратом в библиотеку и другими типами атакам. Лиха беда начало!

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...