Руководство по ida pro на русском

0x00 start

; {EN} entry point, do nothing, just run _main {EN}

Статья для начинающих “воинов тьмы”, тех, кто хочет погрузиться в темную сторону силы: реверс-инжиниринг. На нашем “операционном столе” будет небольшой кустарный сервер, который работает по протоколу TCP/IP. Для анализа протокола обмена данными нам поможет стандарт де-факто в области реверса — IDA Pro.

Статей по реверс-инжинирингу и по IDA Pro уже написано немало (хотя и не столько, как по PHP), но поскольку процесс реверса — исследовательский, то мысли, как с «другого боку» подойти к задаче обратной разработки, полезны новичкам. По крайней мере, как автор, я руководствовался тем, чтобы изложить основные практики и техники, о которых говорю в первые дни всем стажерам и на первых парах курса по реверс-инжинирингу в университете.

«Once you start down the dark path, forever will it dominate your destiny».

Подопытный: crackme — не запускайте бинари на основной системе, лучше это делать на виртуалке!

Системные требования: виртуальная машина с установленной Windows 7/0xA

0x01 mov eax, ds:__stack_chk_guard

; {EN} Disclaimer {EN}

Практически вся статья написана относительно ассемблера и, соответственно, процессора x86, поэтому работа с памятью, условными переходами (флагами), инструкциями и т.п. будет описываться в контексте именно этого процессорного ядра. На момент чтения статьи считаем, что других процессорных архитектур не существует.

0x10 Что нам нужно, чтобы понять о чём пойдет речь?

; {EN} Setups prerequisites for the consequent execution {EN}

Чтобы статья была интересна и понятна, предполагается, что читатель знает:

• язык программирования C или C++;
• основы языка ассемблера x86;
• о существовании форматов исполняемых файлов (PE, ELF);
• о кадре стека функции, поверхностно — достаточно;
• как работать с сокетами;
• математический анализ;
• теорию ядерной физики.

Итак первое, что нам понадобится — сама IDA Pro от фирмы Hex-Rays (на русском произносится, как “ида про” или просто “ида”, для тех, кто любит соблюдать правила английского звучания “ай да про”, но звучит в русскоговорящей среде немного необычно). Вы можете скачать бесплатную версию для того, чтобы попробовать освоить реверс-инжиниринг, однако у неё есть ряд ограничений, среди которых: нельзя сохранять результат (в терминах IDA — базу данных) и подходит только для x86.

Второе, что нам понадобится — подопытный. Подойдет любой исполняемый файл (он же бинарник, он же файл с расширением *.exe для Windows), но рекомендуется взять тот, что прикреплен к статье. Если вы возьмёте свой бинарник, то лучше, если это будет скомпилированный для x86 файл (для первого раза не стоит брать собранные под x64 — в них ассемблер сложнее).

Третье — конечно же, хотя бы начальные знания языка ассемблера x86 (assembler language).

Чтобы осознанно копаться в программе и реверсить её, очень желательно знание языка ассемблера x86: инструкций (mov, lea, push/pop, call, jmp, арифметических и условных переходов), регистров и принципов работы процессора. Если их совсем нет, то настоятельно рекомендуется в начале изучить, например:

• подробно, на русском: Ассемблер. Уроки 2011 (не обращайте внимание, что дизайн из 90-х);
• кратко по ассемблеру, на английском: Guide to x86 Assembly;
• средне, что на самом деле видит процессор, на английском: A Guide To x86 Assembly.

Может показаться, что инструкций огромное количество. На самом деле достаточно понять порядка 10 штук, остальные мало чем отличаются. Смотреть референс по инструкциям можно здесь или же в самой документации на процессорное ядро (предпочтительней).

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

Четвертое — 30 минут времени (хотя, может быть, 30 часов) и желание научиться.

0x20 Минутка философии или что такое IDA Pro и почему?

; {EN} Whatta hell? {EN}

Реверс-инжиниринг (или обратное проектирование) — “это процесс извлечения знаний из того, что когда-либо было сделано человеком… Фактически, реверс-инженер — исследователь (научный работник), с той лишь разницей, что разбирается в том, что получено не естественным образом, а кем-то создано” — Reversing: Secrets of Reverse Engineering, Eldad Eilam.

Что же в первую очередь нужно исследователю? Блокнот и ручка, чтобы вести и систематизировать полученные знания. Так, а при чем тут IDA? IDA — аббревиатура, которая расшифровывается как “интерактивный дизассемблер“. Ключевым и революционным в свое время было именно “интерактивный”. Это означает, что в результате работы вы получаете не просто длиннющий ассемблерный листинг, а что-то, где вы можете оставить свои заметки, то есть как будто это действительного листинг, но в котором можно сделать “заметочки на полях”, и они меняются по ходу всего листинга. Можно еще сравнить с функцией рефакторинга в современных программерских IDE — переименовали функцию в одном месте, она переименовалась везде, переменную — аналогично и т.д. Ваша задача как исследователя — из огромного массива сложно анализируемой информации оставить только важную и придать ей форму хорошо понятную для человека. Именно интерактивность IDA Pro и позволяет делать это очень эффективно, и на сегодняшний день никто её в этом не превосходит.

Стоит все же заметить, что с учетом постоянно возрастающей закрытой кодовой базы и напечатанного мартышками кода в интернете, программное обеспечение реверсить вручную и интерактивно становится все сложнее и сложнее. Из-за этого сейчас активно развиваются средства анализа кода, нацеленные на автоматизированную обработку — radare2 (что бы ни говорили адепты r2, интерактивный интерфейс Cutter не настолько интерактивен, как в IDA Pro). Более того, IDA Pro также очень хорошо автоматизирована с помощью встроенного в неё интерпретатора Python и API к нему.

И все-таки, как бы крут не был автоматизированный анализ, он не автоматический, то есть заменить на все 100% исследователя не может и рано или поздно исследователю нужно вступать в бой. Поэтому, когда все приготовления наконец-то закончены, приступаем к изучению IDA Pro! Начнём постепенно разбирать наш подопытный образец.

0x30 Смотрим на IDA Pro и познаем основы её интерфейса

; {EN}
; This function is too complex.
; Perhaps it interacts with user.
; But currently I am not sure about it.
; A lot of calls to Qt-framework.
; {EN}

0x31 Загрузка бинарника в IDA Pro

Открываем IDA Pro. Перед нами после всех стартовых окошек (которые можно сразу же закрыть), появляется начальное окно программы. Все, что нужно сделать, — перетащить в него исследуемый бинарник. После этого в появившемся окне нажать кнопку “ОК”.

Главное окно IDA Pro при загрузке бинарника

В нашем случае (если вы грузили тот самый exe-файл в IDA, который приложен к статье) никаких настроек производить не нужно, IDA Pro сама распознает формат этого файла (PE, portable execute), а вот если туда кинуть прошивку или дамп из микросхемы памяти от, например, роутера, всё будет намного сложнее.

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

После извлечения из файла обновления, код сам по себе может быть размещен по какому угодно адресу в памяти устройства. Найти точку базирования кода — отдельная задача, заслуживающая своей статьи.

Что же касается дампа памяти, то на самой микросхеме может уже находится файловая система с учетом “скрамблинга” (перемешивания блоков на флеш-памяти с целью уменьшения износа). Собрать обратно эти блоки часто является не самой тривиальной задачей. Чтобы восстановить схему скрамблинга, необходимо реверсить сам скрамблер.

0x32 Что нам IDA Pro показала?

После загрузки бинарника IDA Pro проводит его предварительный автоматический анализ: определяет функции, глобальные переменные, строки — всё, что можно автоматически вытащить из анализируемого файла. Анализ выполняется процессорным модулем IDA Pro (не путать с самим процессором). Фактически это плагин для IDA Pro (при желании можно написать свой на Python или C++). В нашем случае IDA использует так называемый Meta PC — вариант x86/x64, учитывающий большинство твиков, которые были добавлены в архитектуру от Intel и AMD. Автоматический анализ выполняется опять же на основе того, что есть полное описание формата файла, который мы загрузили в IDA, в нашем случае тот самый Portable Executable. Данный формат чётко указывает какие секции есть в файле, в какой из секций лежит код, где его точка входа, а в какой секции данные (константы или глобальные переменные). Как обычно, с прошивками такой финт не проходит и необходимо вручную размечать входной файл (или же писать loader-плагин для IDA, который сможет «рассовать» куски бинарника прошивки как нужно, после чего процессорный модуль IDA сможет приступить к анализу).

Автоматический анализ под капотом крайне сложная штука, но для каждой инструкции он состоит в следующем:

• декодирование инструкции из бинарного представления во внутреннее (analyze);
• связывание инструкции с учётом специфики её выполнения (emulate — не путать с эмуляцией, как, например, в QEMU);
• преобразование инструкции и аргументов в мнемонику.

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

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

Пару слов о том, как IDA Pro хранит результат реверса. После или во время автоматического анализа “проект” можно сохранить (если, конечно, у вас полная версия). IDA хранит результат анализа в виде специальной базы данных со своей структурой (нет, это не модная MongoDB) на жёстком диске. Она представляет собой один файл с расширением .idb (или .i64).

После того как автоматический анализ завершён, вы увидите окно, примерно такое, как на рисунке ниже. Основные элементы, на которые стоит обратить внимание начинающему исследователю, подписаны на самом скриншоте. Завершение автоматического анализа можно определить по надписе AU: Idle в левом нижнем углу IDA Pro.

Граф потока выполнения функции main

Давайте рассмотрим основные окна, которые первоначально отображает нам IDA Pro.

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

Примечание автора. На мой взгляд, представление в виде графа более удобно, так как дает представление о структуре функции.

• Список функций — окно, в котором выводятся функции, которые нашлись в бинарнике. Это те самые функции, которые были написаны программистом при создании программы (не учитывая оптимизацию). Если разработчик при компиляции не убрал отладочную информацию (в gcc это опция -s) или вообще собрал программу с опцией -g, тогда мы увидим все имена функций точно в таком же виде, как и программист. Иначе IDA Pro отобразит их в виде sub_<виртуальный_адрес _функции>;
• Список строк (Strings) — не показан, но можно построить, нажав на SHIFT+F12. Одна из самых важных менюшек IDA Pro — в ней показаны все строки, которые есть в программе. Используя строки можно в некоторых случаях, найти всю интересующую нас функциональность.

0x33 Трогаем “лапой” IDA Pro

Наконец-то открыли бинарник и увидели, как это выглядит изнутри. Что же с ним делать и с чего начать реверс? С чего начать трогание нашего основного инструмента в реверсе, IDA Pro? Первое — виртуозное владение пианино горячими клавишами. Без знания горячих клавиш жизнь реверс-инженера скучна, так как сочетания клавиш сильно помогают её разнообразить и очень поднять эффективность и скорость реверса.

Когда только учишься работать в IDA Pro лучше постоянно держать перед глазами табличку (чит-шит, cheatsheet) с горячими клавишами. Ниже приведен пример моего чит-шита. Есть и официальный чит-шит от самой фирмы разработчика IDA Pro — Hexrays. Официальный чит-шит можно найти здесь, в нем больше сочетаний кнопок, но, на мой взгляд, на первое время будет достаточно того, что приведено на чит-шите ниже.

После того, как ознакомитесь с табличкой горячих кнопок, рекомендую попробовать некоторое время понажимать их в самой IDA Pro. При этом не стоит бояться, что вы что-то сломаете или перейдете «не туда», потому что именно так и будет. Как и любую сложную систему, освоить IDA Pro до виртуозного владения за один вечер невозможно.

Пройдемся и заодно опробуем различные кнопки в IDA Pro.

0x33a Навигация по графу и листингу

Навигация — одна из самых простых и понятных задач, однако, чтобы не теряться в IDA Pro, следует потренироваться в следующем:

• перемещения по графу функции с помощью мыши;
• перейти на различные функции с помощью двойного нажатия мыши, вернуться обратно с помощью ESC и снова вперед с помощью CTRL+ENTER (нет в чит-шите — для продвинутых);
• переключения между графом и листингом — SPACE, если вдруг у вас включился другой вид (листинга);
• переход по перекрестным ссылкам: поставить указатель мыши на любое имя (функции или переменной) и нажать X. После этого вы увидите окно с другими инструкциями, которые ссылаются на это имя (или же указатель в памяти программы);
• прямой переход на имя или адрес (g): в открывшемся окне написать любое из существующих имен или же адрес (можно без 0x) из текущей база данных IDA Pro — вы перейдете на ту часть графа (листинга), где определено это имя.

0x33b Именование и заметки на полях

По изменению имен (рефакторингу) следует попробовать и отработать следующие действия:

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

0x33c Представление данных (data representation)

Любую часть анализируемого бинарника можно представить в виде различных вариантов:

• байт (byte);
• слово (word);
• двойное слово (dword);
• указатель (offset);
• неопределенное (undefined);
• дизассемблированный код (code).

Иначе говоря, каждый адрес в бинарнике можно попытаться дизассемблировать, если получится — будет код, иначе просто данные (байт, слово и т.д.). По умолчанию, если не проводить никакого анализа (в том числе и автоматического), весь бинарник представляется IDA Pro как undefined. Можно сказать, что в процессе реверса или автоматического анализа происходит разметка того, как представить каждый из байтов загруженного бинарника. То, что мы с вами видим уже размеченным (причем практически все байт), является результатом автоматического анализа, который выполнила IDA Pro.

0x33d Отличие кода от функции

Отдельно можно отметить и представление кода:

• Код без функции (в таком случае IDA Pro не сможет построить граф);
• Функция (чтобы из кода создать функцию, необходимо нажать P).
  Для большей части кода во время автоматического анализа IDA Pro сама распознает, где необходимо создать функции. Каким образом? За счет того, что если во время дизассемблирования встречается инструкция вызова (call), то анализатор однозначно может утверждать, что адрес, находящийся у этой инструкции в аргументе, — адрес начала функции.

0x33e Представление аргументов инструкций

Кроме представления каждого байта в виде различных вариантов указанных выше, можно по разному представить и аргументы большинства инструкций. Например, в инструкции записи числа в регистр mov eax, 0xFFFFFFFF второй аргумент может быть представлен, как в текущей записи, так и mov eax, -1. Для того, чтобы сменить вариант представления аргумента инструкции, необходимо нажать на него правой кнопкой мыши, и IDA Pro покажет возможные варианты представления.

0x33f Вспомогательные окна IDA Pro

В первую очередь стоит обратить внимание на Strings, Names, Functions, Hex Dump. Все эти окна можно открыть перейдя из строки меню View->Open Subviews.

0x40 Всего так много и как с этим работать?

; {EN}
; I think I found actual protocol parsing in function sub_401D3C
;
; But this function just chases bytes from corner to corner
; before actual parsing... we need to go deeper
; {EN}

0x41 Что же мы будем делать?

Теперь, когда мы знаем на какие кнопки надо нажимать и приблизительно представляем как «под капотом» работает IDA Pro, давайте попробуем вернуться к нашей задаче и найти ту часть бинарника, которая отвечает за разбор протокола обмена данными подопытного сервера.

Если внимательно посмотреть на вкладку с перечнем функций, можно увидеть, что IDA нашла в нём всего лишь 76 функций, то есть это очень маленькая программа. Реальные программы и, тем более прошивки, могут состоять из сотни тысяч функций. При этом никогда не ставится задача «втупую» восстановить исходный код программы на 100% (по крайней мере в моей практике никогда такого не было). Среди прочего от реверса бывает нужно:

• Найти в протоколе ошибки. Для этого в программе необходимо искать места, связанные с получением данных извне;
• Разобрать некий протокол взаимодействия, чтобы, например, создать свой API;
• Пофиксить баг в чужой неподдерживаемой программной библиотеке (серьёзно, такое приходилось делать пару раз);
• Что-то ещё…

Таким образом, главная задача, которая стоит перед исследователем, — найти некоторые интересующие места программы. Иначе говоря, реверсить всё целиком зачастую не имеет смысла, да и процесс этот слишком трудоёмкий. Не стоит забывать, что обратный анализ кода занимает времени больше, чем его прямая разработка.

0x42 Иголка в стоге байт

; {RU}
; Ищем функцию получения данных извне;
; Ищем на неё ссылки;
; Если не нашли, пытаемся искать по логам (повторяем пп.1-3);
; {RU}

Как же найти иголку в стоге сена? На самом деле, подходы практически такие же, как когда знакомишься с новым API или OpenSource-проектом, а вся документация в нем сделана в «doxygen»: пытаемся искать функции с вменяемыми именами или идём от API операционной системы.

Поскольку исходно сказано, что это TCP/IP-сервер, логично предположить, что данные будут “приезжать” в обработчик через recv, хотя в реальности могут быть использованы и другие функции. Например, recvfrom, или API более низкого уровня — самой ОСи (для Linux — read).

Заметка: кто хочет вспомнить/познакомиться с работой с сокетами в Си, тот читает Socket programming in c using TCP/IP.

Как сделать это в IDA Pro? Сначала нам нужен перечень всех имен (строк и имен функций, вкомпилированных в программу и импортируемых из библиотек). Для этого служит сочетание клавиш SHIFT+F4. После нажатия откроется вкладка с именами (Names).

На вкладке с именами можно воспользоваться поиском, точнее фильтром (в широком смысле, это более сложная функция с возможностью фильтрации строчек с помощью регекс выражения). Для того, чтобы вызвать поиск, необходимо, находясь во вкладке с именами, нажать сочетание клавиш CTRL+F. После этого внизу вкладки откроется строка ввода (как показано на рисунке). В эту строку необходимо написать часть слова, которое мы хотим найти (в нашем случае это будет recv), список сократится, и в нем останутся только те строки, в которых встречается заданное ключевое слово (на рисунке не показано).

Во второй колонке выводится адрес соответствующего имени. Для перехода на этот адрес в листинге следует дважды кликнуть по нему (или ENTER).

Заметка: переход назад в листинге выполняется по горячей клавише ESC.

Окно имен данного бинарника

И вот мы попадаем обратно в листинг. Теперь уже по адресу функции recv (вспоминаем, что recv в данном случае — библиотечная функция, и её код находится в динамической библиотеке).

Следующим шагом необходимо найти те места в программе, в которых происходит вызов функции recv. Для этого во время анализа IDA Pro создает перекрёстные ссылки между инструкцией вызова функции (или другим обращением к функции) и самой функцией. Чтобы посмотреть места, где используется функция, необходимо навести мышку на адрес (или имя), к которому мы хотим найти перекрёстные ссылки, и нажать кнопку X. Вслед за этим откроется окно, как на рисунке ниже. В окне будут перечислены все найденные перекрестные ссылки. Причем в колонке type используется следующая нотация:

• p[rocedure] — перекрёстная ссылка “по вызову”, то есть адрес (имя) используется в инструкции call;
• r[ead] — перекрёстная ссылка на чтение; в этом месте программы происходит чтение из данного адреса (имени);
• w[rite] — перекрёстная ссылка на запись; в этом месте программы происходит запись в данный адрес (имя).

В нашем случае ссылок всего две:

1. Чтение адреса функции recv в регистр (тип r),
2. Непосредственный вызов recv (тип p).
   Можно заметить, что реально прямой перекрёстной ссылки на recv в инструкции вызова нет. Листинг вызова выглядит следующим образом:

push    0
push    1000h   ; len
push    ebx     ; buf
push    edi     ; s
call    esi     ; recv   <----  Вызов recv здесь

Как видно из кода ассемблера, инструкция call выполняет переход по адресу из регистра esi. Во время автоматического анализа IDA отслеживает, какое значение было занесено в регистр esi, и делает вывод, что при выполнении call в регистре esi всегда будет адрес recv. Именно поэтому IDA создает перекрёстную ссылку на recv в этом адресе.

Перекрестные ссылки на recv

Выбираем из списка ссылку с типом p, и IDA перекидывает нас в граф (или листинг), где происходит вызов функции recv. Выше на экране — листинг IDA. Мы можем увидеть функцию, вызывающую recv: sub_401D3C.

Просто? Да. В данном случае. В реальности же может оказаться, что прямых ссылок нет, а вместо recv вызываются другие функции, или же данные сохраняются в какой-то буфер в структуре, и потом обрабатываются неизвестно где (но анализ всего этого — отдельная статья).

0x43 Делаем “заметки на полях”: sub_401D3C

; {EN} x_vserv_protocol {EN}

Функция sub_401D3C в отличие от recv является частью данной программы. Поэтому можно исследовать, что происходит в этой части «подопытного».

Заметка: вообще исследование программы часто делится на два основных метода: статический и динамический анализ. Статика подразумевает, что весь анализ выполняется только на основе кода (без запуска программы), динамика — с учётом информации получаемой в дебаге.

В нашем случае проще было бы запустить подопытного в дебаге (англ. «debug» — отладка) и уже после этого начать изучать, что с ним происходит. Но, во-первых, чтобы поучиться мы проведем исследование чисто статикой: где-и-что делается в обработке сразу после получения данных из сокета. Во-вторых, прежде чем что-то запускать даже на виртуалке, я предпочитаю понять, чем это может закончиться

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

Место вызова функции recv

Начнем делать “заметки на полях”. Если окинуть взором функцию sub_401D3C, в которой мы очутились, можно увидеть в ней вызовы двух функций с неизвестными именами: sub_401CF0 и sub_401BFD. Кроме этого, мы видим и вызов функции puts — стандартная библиотечная функция из libc. Она выводит строку в стандартный поток вывода (stdout). Раз функция что-то печатает на экран, значит, должны быть и строки, из которых можно получить какую-то информацию!

Заметка: в предыдущем разделе мы нашли интересующую нас функцию по библиотечной функции recv. Однако “золотой жилой” являются строки. Просто пробежавшись взглядом по строкам в окне Strings (SHIFT+F12) или поискав в нём различные ключевые слова, можно извлечь очень много дополнительной информации о работе программы или же найти места, в которых происходит что-то интересное для нас как для реверс-инженеров. Никогда не пренебрегайте возможностью посмотреть на строки, которые остались в программе.

Даже не особо разбираясь в ассемблере, можно легко понять, что выводит конкретно здесь puts. В блоке по адресу 0x00401D64 (чтобы перейти в этот блок, нужно нажать кнопку g и вставить в окно указанный адрес) будет выведена строка “Received failed», в блоке по адресу 0x00401D7A — «Client disconnected», а в блоке 0x00401D9C — “VSERV protocol error…”. На основании этих строк можно сделать вывод, что данный сервер имеет внутреннее название VSERV (далее при именовании функций будем использовать такой идентификатор). Кроме этого нужно поименовать метки блоков по адресам:

• 0x00401D76 как RECV_SUCCESS;
• 0x00401D8C как CLIENT_NOT_DISCONNECTED.

Заметка: надо стараться именовать всё во время реверс-инжиниринга. Если вы натыкаетесь на функцию и у вас есть хотя бы малейшее предположение, что делает эта функция, — переименовывайте её. В будущем, когда натыкаетесь на эту же функцию, но при других обстоятельствах, вы будете помнить, что уже имели дело с ней, и она где-то была важна для вас. Также можете провести анализ её использования по нескольким случаям применения. Дальше по тексту уже не будет приводиться фраза: “надо переименовать”, предполагается, что это рефлекс.

Далее видно, что адрес 0x00401D54 — начало цикла, в котором сервер постоянно “крутится” и получает данные от клиента. Этот адрес можно назвать “RECV_LOOP”. Цикл в IDA Pro легко найти с помощью графового представления: стрелка перехода от нижнего блока (окончание цикла) к верхнему (начало цикла) выделяется жирным.

Хорошим вариантом для имени функции по адресу 0x00401D3C, в которой мы находимся, является, например, x_vserv_protocol. Видно, что в ней происходит приём данных от клиента, после чего вызываются две функции — в них будет либо полный разбор протокола, либо же предразбор (преобразование потока данных из TCP в “сообщения”). Из кода, который есть в функции x_vserv_protocol, невозможно сделать полноценный вывод, что же происходит внутри функций sub_401CF0 и sub_401BFD, поэтому давайте зайдем поочередно в каждую из них и попробуем понять их функциональное назначение (вернуться назад можно кнопкой ESC).

Не забываем переименовывать метки и имена функций

0x44 Делаем “заметки на полях”: sub_401CF0

; {EN} x_vserv_parse_header {EN}

Начнем, пожалуй, с sub_401CF0, так как она идёт первая по ходу выполнения. Чтобы перейти в функцию, необходимо дважды нажать на неё мышью, в результате чего мы оказываемся в очень маленькой функции sub_401CF0. Граф её потока выполнения приведён на рисунке ниже. Судя только по общему виду графа (не вдаваясь в подробности ассемблера), сразу можно сделать вывод, что эта функция:

• На вход получает только один аргумент (причем, скорее всего, с помощью функции recv данные из TCP-сокета);
• Не имеет циклов и содержит одно ветвление (if-else);
• Вызывает две библиотечные функции memcmp и atoi;
• В одной из веток возвращается 0xFFFFFFFF (-1) в качестве результата;
• Проверяет сигнатуру в пришедших данных.

_Реверс функции sub_401CF0 она же x_vserv_parse_header_

Разберёмся по порядку, откуда что взялось.

0x44a Один аргумент и его назначение в функции sub_401CF0

Аргументы IDA пытается распознать сама (для этого она, точнее её конкретный процессорный модуль, использует знание о calling convention (соглашение о вызовах) и другие методы эвристики, но может ошибаться). Если аргумент передается через стек, а не через регистр (для x86 при соглашении о вызовах cdecl, которое используется чаще всего, это именно так), то такие смещения в стеке IDA Pro сама именует с префиксом arg_.

Заметка: передача аргументов и возврат значения из функции при компиляции целиком и полностью определяются соглашением о вызове функции (calling convention). В соглашении много нюансов, и самих вариантов соглашений довольно много (какой из них используется, определяется в том числе и компилятором). Основное, что нам сейчас нужно знать, — x86-аргументы передаются через стек (с помощью инструкции push), а возвращаемое значение через регистр eax (то, что на Си пишется после return).

Назначение аргумента. Почему на скриншоте агрумент уже назван packet_buffer? Разобраться с этим можно, взглянув на предыдущую функцию, а точнее на то, что ей передается в качестве аргумента. Для разъяснений ниже приведён еще один скриншот из функции x_vserv_protocol. Аргументом в функцию приходит значение из регистра ebx. Если нажать на ebx мышкой, IDA подсветит все его использования, за счёт чего можно легко найти предыдущее применение этого значения. Оно же передается в функцию recv (да, в ту самую) вторым аргументом (вспоминаем, что согласно соглашению о вызовах в стек аргументы в коде заносятся в «обратном порядке»).

_Аргументы функции x_vserv_parse_header_

Следующим шагом (для тех, кто забыл определение функции recv) необходимо заглянуть в документацию на recv. Из неё станет понятно, что второй аргумент — адрес буфера, в который recv запишет принятые данные. Думаю, теперь очевидно, что единственный аргумент функции sub_401CF0 и есть адрес буфера с принятыми из TCP-сокета данными.

0x44b Функция sub_401CF0 не имеет циклов и содержит одно ветвление

Вспоминаем, как в IDA Pro быстро понять, есть ли в функции циклы или нет (стрелка от нижнего блока к верхнему). Аналогично смотрим на граф функции sub_401CF0 и делаем вывод, что в sub_401CF0 циклов нет.

Наверное, уже все догадались, что две выходящие стрелочки из блока в графе IDA Pro означают, что данный блок программы является частью if-else в исходном коде. Цвет стрелки означает следующее:

• Красный — путь выполнения программы, если переход не выполняется;
• Зеленый — если выполняется.

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

Заметка: обычно конструкция if-else после компиляции превращается в две инструкции (как минимум):

1. Сравнение значений (эта инструкция выставит флаги процессора);
2. Условный переход на основании выставленных флагов.

0x44c Функция sub_401CF0 вызывает две библиотечные memcmp и atoi

Если мы не помним определение и функциональное назначение библиотечных функций, их необходимо загуглить, так как эта информация позволит нам понять, что делает анализируемый код. Иногда названия API-функций могут быть совсем не очевидны и даже если считаете, что хорошо знаете ту или иную функцию, но возникла тень сомнения, лучше сразу посмотреть документацию, в данном случае на memcmp.

Примечание автора: иногда “fear … leads to suffering”, давным-давно, в одной забытой Галактике, я реверсил устройство и, находясь в режиме отладки при загрузке Линукса, наткнулся на вызов функции reboot. В тот момент, когда выполнение повернуло в ветку с этой функцией, я остановил отладку и начал разбираться, в чём проблема. На все разборки ушёл практически весь рабочий день. Под конец заглянув в документацию на reboot, я прочитал следующее: «or enables/disables the reboot keystroke». Победив «страх» и нажав на F8, находясь на функции reboot, я понял, что устройство не перезагрузилось, а продолжило выполняться… RTFM!

Довольно легко можно найти, что memcmp сравнивает два массива в памяти и на вход принимает указатели этих массивов и количество байт, которое необходимо «подвергнуть» сравнению. Вроде всё просто и понятно, а вот с возвращаемым значением не всё так очевидно, и новички в Си часто делают ошибку. Предполагают, что 0 — строки неравны, а 1 — строки равны. В реальности в случае равенства строк функция вернет 0, а если строки неравны, то либо > 0, либо < 0.

Вторая API-функция atoi преобразовывает число, записанное в ascii-строке, в integer. Соответственно, на вход приходит указатель на строку, а на выходе — целочисленное значение.

0x44d Собираем всё вместе и отвечаем на два оставшихся вопроса

Какие выводы можно сделать из анализа использования этих двух API-функций в исследуемой функции?

Во-первых, memcmp проверяет сигнатуру протокола (уникальную последовательность байт, чтобы «удостовериться», что пакет реально относится к заданному протоколу). Этот вывод можно сделать на основе того, что в функцию memcmp передается напрямую буфер с принятыми данными (постарайтесь отследить это сами), константная строка «VMES» и значение 4 (очевидно длина VMES). После этого, если сигнатура не нашлась, программа может повернуть в ветку, где в регистр eax заносится значение 0xFFFFFFFF (-1), или в ветку с atoi.

В данной случае используется функция memcmp, а не strcmp, хотя и сравниваются две строки, из-за того, что необходимо указать максимальную длину сигнатуры, 4 байта. Функция strcmp будет сравнивать до тех пор пока не встретит нуль-терминатор. Хотя у сигнатуры «VMES» нуль-терминатор идет последним, пятым символом, в пришедшем пакете — нуль-терминатор может быть где угодно. Из-за этого, даже если в пакете в начале будет эта сигнатура, strcmp определит эти строки как различающиеся.

Во-вторых, atoi, скорее всего, получает длину тела-сообщения (хотя напрямую это не следует из анализа только этой части кода). Взгляните внимательно и вы увидите, что atoi берёт из полученных данных кусок буфера — четыре байта следом за VMES (это можно понять, если разобрать ассемблер в блоке по адресу 0x00401D19) — и преобразует его в число. Результат преобразования atoi передается в eax. Таким образом, в eax на выходе из функции оказывается либо значение, полученное из принятых данных, либо -1. Также вспомним, что согласно соглашению о вызовах для x86 результат возврата функции находится в регистре eax, функция проверяет наличие сигнатуры в первых четырех байтах, если этих байтов в буфере нет — возвращает -1, иначе преобразует следующие четыре байта в число и возвращает его из функции. Что может быть лучше, чем описать код на естественном языке? Правильно, написать сам код:

char tmp[5] = { 0 };
if (memcmp(&buf[0], "VMES", 4) != 0)
    return -1;
*(int*) tmp = *(int*)(&buf[4]);
return atoi(tmp);

По началу код может показаться странным. Могут возникнуть такие вопросы, как: откуда буфер на 5 байт? Зачем он вообще здесь? Почему просто нельзя передать в atoi(buf + 4)? Начнем разбираться с последнего вопроса и для этого нам понадобится документация на atoi, а точнее на документация на strtol (если открыть доку на atoi, то она ссылается на strtol с указанием системы счисления 10). В ней сказано, что конвертация происходит, пока не будет встречен символ, который не подходит для данной системы счисления. То есть, для 10-ой системы это любой символ не из диапазона от 0 до 9. В ходе реверса в таких случаях, можно предположить, что автор программы хотел защититься от того, что в сервер могли отправить специально подобранный пакет, где это значение будет указано каким-угодно большим. Однако при этом (как увидим дальше) допустил другие ошибки. По итогу: копирование в отдельный буфер с нуль-терминатором позволит избежать проблемы неправильной конвертации ascii-строки.

Размер буфера в 5 байт можно определить, если заглянуть в стек программы (о котором подробнее чуть позже в статье): в списке переменных функции сразу за buffer_length идет переменная var_D (поэтому в стеке они распологаются друг за другом). В нее заносится 0 в самом начале функции, и больше эта переменная никак не изменяется. Поэтому var_D и есть нуль-терминатор.

На основании анализа предлагается дать функции гордое название x_vserv_parse_header (на скриншотах уже была переименована).

0x45 Делаем “заметки на полях”: sub_401BFD

; {EN} x_vserv_parse_body {EN}

0x45a Немного о стеке и его кадре

Итак, мы дошли до последней неразобранной функции, чтобы целиком охватить «архитектуру» той части программы, которая отвечает за обработку протокола. Как и на предыдущем этапе реверса, начать следует с её аргументов. Обратимся к блоку функции x_vserv_protocol, который мы ранее поименовали как PARSE_BODY (для этого, как обычно, можно нажать g, вставить туда название блока и нажать ENTER). Перед вызовом самой функции видны две инструкции push, которые, очевидно, передают аргументы в нужную нам функцию sub_401BFD (на скринах она уже переименована в x_vserv_protocol_body). С этой целью взглянем на рисунок, приведенный ниже.

_Что за body_buffer?_

Первым аргументом передается адрес (так как используется инструкция lea) некой переменной (на скриншоте названа body_buffer). Вторым аргументом — то, что было получено из функции x_vserv_protocol_header (так как регистр eax передается в инструкцию push без изменений). Если со вторым аргументом все очевидно — число после atoi-преобразования, то с первым давайте разберёмся.

Чтобы понять, что такое body_buffer, следует обратить внимание на пару моментов:

• Каким образом получен указатель на буфер, который передается в recv;
• Структура стека функции x_vserv_protocol.

Указатель на буфер, передаваемый в recv, формируется довольно очевидно. Он передается вторым аргументом в recv и, следовательно, адрес буфера находится в регистре ebx перед вызовом функции recv (см. блок RECV_LOOP). Если нажать на ebx и отследить, какое значение заносится в него перед этим, то видно, что туда перекладывают регистр esp. Регистр esp является крайне важным (хотя все регистры важны) тем, что он всегда указывает на вершину стека и, кроме этого, неразрывно связан с push/pop. Конкретно в этом случае в esp хранится начало стекового буфера, что в исходном коде выглядело как:

char buffer[0x1000];

Заметка: почему так? Чтобы ответить, нужно разобраться с тем, что такое кадр стека, и как разложены локальные переменные, а также аргументы в стеке. Подробно тому, как располагаются данные в стеке лучше почитать по одной из ссылок в начале статьи, так как тема кадра стека сама по себе заслуживает отдельной статьи. Также можно почитать статью на Wikipedia.

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

Стековый кадр функции

Как было написано выше, указатель для приема данных через recv соответствует самому началу кадру стека (так как esp используется без смещения). В связи с этим можно поименовать (как обычно — кнопочкой N) верхушку как vmes_sign (в первых четырех байтах ожидается сигнатура «VMES»).

Следующие четыре байта — это байты, которые передаются в atoi в функции x_vserv_parse_header. Вывод о группе в четыре байта, можно сделать из первой инструкции левого блока функции x_vserv_parse_header (адрес 0x00401D19). Инструкция mov перекладывает именно четыре байта из [ebx+4] в регистр eax для последующего преобразования в atoi. Поскольку мы решили, что это длина тела пакета, поименуем их как vmes_body_len.

Теперь становится понятно, что после восьми описанных байт идут оставшиеся данные из TCP-пакета. Если вы разрабатывали клиент-серверное приложение, то очевидно, что эти оставшиеся данные — тело пакета, и его парсинг (разбор), скорее всего, будет в функции, вызываемой следом за x_vserv_parse_header. Собственно, эта функция на скриншотах практически сразу и была названа как x_vserv_parse_body.

0x45b Разбираем функцию разбора тела пакета

Вернёмся обратно в саму функцию (кнопка ESC) и соберём всё вместе. Первый аргумент для функции sub_401BFD (x_vserv_protocol_body — уже можно переименовать) — тело пакета, данные, пришедшие из TCP-сокета с помощью recv, за исключением первых восьми (судя по всему, первые восемь — заголовок пакета). Второй аргумент – данные, находящиеся по смещению +4 от начала пакета (предположительно, длина тела пакета) и «пропущенные» через atoi, чтобы получить из них число.

Заметка: если кто-то со знанием Stack BOF (он же Stack Buffer Overflow, оно же переполнение буфера в стеке) решил почитать статью, он наверняка уже учуял запах крови этого самого переполнения буфера в стеке. Из пользовательских данных берётся значение, которое преобразовывается в число. Если дальше нет валидации этих данных, жди беды переполнения.

Настала пора заглянуть в саму функцию x_vserv_protocol_body, граф которой показан на рисунке ниже.

_Граф функции x_vserv_protocol_body_

После долгих вечеров и дней реверс-инжиниринга граф функции в стиле «лесенки» практически сразу говорит о том, что в исходном коде была цепочка из if-else-if-else-if-else (возможно, также и switch). И действительно, если внимательно посмотреть на функцию, то хорошо видно, что в каждом из блоков берутся первые байты тела пакета и поочередно сравниваются с “HEXDUMP”, “TALK2ME”, “B64DECO”, “DISCONN”, “STOP!!!”. Если ничего из этого не нашлось, то в консоль выводится строка «Unknown command». Таким образом, понятно, что перечисленные выше строки — команды протокола. При обнаружении одной из них выполнение переходит на соответствующую функцию. Их можно поименовать следующим образом: x_vserv_hexdump, x_vserv_talk2me, x_vserv_b64deco, x_vserv_disconn, x_vserv_stop. Это и есть обработчики команд протокола.

0x45c Пощупаем некоторые обработчики команд vserv

Интересно отметить, что число, которое передано вторым аргументом, нигде не используется в этой функции напрямую, а только передается дальше в обработчики команд протокола. Кроме того, нет и валидации количества принятых данных, то есть программа считает, что ей обязательно пришёл пакет как минимум из 15 байт (хотя это может быть вовсе не так). Чтобы всё-таки убедиться, что второй аргумент, он же len, реально является числом, применяемым как размер данных, обратимся к одному из обработчиков x_vserv_hexdump. Интересующий нас кусок функции приведён на рисунке ниже.

_Второй аргумент x_vserv_hexdump_

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

0x45d Закругляемся на сегодня

0x50 Is this the end?

; {EN} x_vserv_parse_body {EN}

Статья направлена на то, чтобы изложить максимально подробно базовую технику реверс-инжиниринга, которая была бы понятна новичку и он смог бы попробовать изучить другие бинарники. Конечно, мы не коснулись разбора алгоритмов, а фактически только посмотрели, как понять структуру программы и куда вообще лезть после того, как открыл её в IDA Pro.

Если вдруг эта статья окажется не 9-й жизнью котика реверс-инженера, он расскажет об анализе обработчиков протокола VSERV в IDA Pro, поможет написать для него клиент и вместе с читателем поищет уязвимость RCE (она там есть и лежит на поверхности) в этом сервере.

В сегодняшней статье мы окунемся в глубокий и подробный статический анализ с помощью IDA Pro — сверхпопулярного среди хакеров и специалистов по информационной безопасности дизассемблера. С первых же версий IDA Pro занял заслуженное место лидера рынка. Это своего рода швейцарский армейский нож, которым можно раделывать цифровую добычу. Начнем с самого базового анализа и постепенно будем пробираться вперед, разгребая заросли кода.

С легкой руки Денниса Ритчи повелось начинать освоение нового языка программирования с создания простейшей программы «Hello, World!». Не будем изменять традициям и оценим возможности IDA Pro следующим примером.

Компилятор сгенерирует исполняемый файл объемом почти 190 Кбайт, большую часть которого займет служебный, стартовый или библиотечный код. Попытка дизассемблирования с помощью таких средств, как W32Dasm, не увенчается быстрым успехом, поскольку над полученным листингом размером в два с половиной мегабайта (!) можно просидеть не час и не два. Представьте, сколько времени уйдет на серьезные задачи, требующие изучения десятков и сотен мегабайтов дизассемблированного текста.

Чтобы все было подобно в статье, компилируйте примеры с помощью Visual C++ 2017 вызовом
cl.exe first.cpp /EHcs. Флаг
/EHcs нужен, чтобы подавить возражение компилятора и вместе с тем включить семантику уничтожения объектов.

Попробуем дизассемблировать даную программу с помощью IDA. Если не изменять настройки по умолчанию, то после завершения анализа файла экран должен выглядеть таким образом:

Чтобы открыть текстовое представление, нужбно открыть контекстное меню и выбрать пункт Text view.

Какую версию IDA Pro выбрать?

На момент написания статьи последней версией IDA Pro была 7.3. Цена программы может показаться великоватой для покупки в исследовательских целях. Как известно, разработчик IDA Pro Ильфак Гильфанов очень строго относится к утечкам и появлению взломанных версий своих продуктов в интернете и жестоко с этим бориться.

Но, несмотря на это на сайте компании Hex-Rays в публичный доступ выложена бесплатная версия дизассемблера с функциональными ограничениями. Например, она не получает обновления после достижения майлстоуна целой версии, то есть сейчас для свободной загрузки доступна версия 7.0. Также она поддерживает только архитектуры x86 и x64.

РЕКОМЕНДУЕМ:
Как убить защитный драйвер в Windows

Тем не менее этого вполне достаточно для наших целей. Потому что у нас нет необходимости разбираться в коде для процессоров ARM, Motorola, Sparc, MIPS или Zilog. Еще одно ограничение накладывается на использование в коммерческих целях, но и в этом случае наша совесть чиста.

Закончив автоматический анализ файла
first.exe, IDA переместит курсор к строке
.text:0040628B — точке входа в программу. Не забудьте из графического режима отображения листинга переключиться в текстовый. Также обратите внимание на строчку
.text:00406290 start endp ; sp—analysis failed, выделенную красным цветом в конце функции
start. Так IDA отмечает последнюю строку функции в случае, если у нее в конце
return и значение указателя стека на выходе из функции отличается от такового на входе.

Среди новичков в программирование широко распространено заблуждение, что якобы программы, написанные на языке С, начинают выполняться с функции
main. В действительности это не совсем так. На самом деле сразу после загрузки файла управление передается на функцию
Start, вставленную компилятором. Она подготавливает глобальные переменные:

• argc — количество аргументов командной строки;
• argv — массив указателей на строки аргументов;
• _environ — массив указателей на строки переменных окружения.

Заполняется структура
OSVERSIONINFOEX, которая среди прочего включает:

• dwBuildNumber — билд;
• dwMajorVersion — старшую версию операционной системы;
• dwMinorVersion — младшую версию операционной системы;
• _winver — полную версию операционной системы;
• wServicePackMajor — старшую версию пакета обновления;
• wServicePackMinor — младшую версию пакета обновления.

Далее
Start инициализирует кучи (heap) и вызывает функцию main, а после возвращения управления завершает процесс с помощью функции
Exit. Для получения значений структуры
OSVERSIONINFOEX используется функция
GetVersionEx.

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

CRtO.demo.c

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

Очевидно, нет никакой необходимости анализировать стандартный стартовый код приложения, и первая задача исследователя — найти место передачи управления на функцию
main. К сожалению, чтобы гарантированно решить эту задачу, потребуется полный анализ содержимого функции
Start. У специалистов есть много всяких трюков, которые позволяют не делать этого, но все они базируются на особенностях реализации конкретных компиляторов и не могут считаться универсальными.

Например, Visual C++ всегда, независимо от прототипа функции
main, передает ей три аргумента: указатель на массив указателей переменных окружения, указатель на массив указателей аргументов командной строки и количество аргументов командной строки, а все остальные функции стартового кода принимают меньшее количество аргументов.

Советую ознакомиться с исходниками стартовых функций популярных компиляторов. Для Visual C++ 14 в соответствии с архитектурой они находятся в подпапках каталога
%\Program Files (x86)\Microsoft Visual Studio 14.0\VC\crt\src\. Их изучение упростит анализ дизассемблерного листинга.

Ниже в качестве иллюстрации приводится фрагмент стартового кода программы
first.exe, полученный в результате работы W32Dasm.

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

Поэтому способности дизассемблера тесно связаны с его версией и полнотой комплекта поставки — далеко не все версии IDA Pro в состоянии работать с программами, сгенерированными современными компиляторами.

Перечень поддерживаемых компиляторов вы можете найти в файле
%IDA%/SIG/list. В нем есть старинные Microsoft C и Quick C, Visual C++ с первой по восьмую версию и Visual.Net. А вот Visual C++ 14 из Visual Studio 2017 здесь нет. Однако, взглянув в окно IDA, мы видим, что дизассемблер сумел определить многие (но не все) функции.

Заглянем в окно вывода, находящееся внизу. Там, немного прокрутив вывод, мы обнаружим строчку
Using FLIRT signature: SEH for vc7—14, говорящую о том, что используемая версия IDA все же понимает компиляторы Visual C++ от 7 до 14.

Попрубем разобраться в получившемся листинге. Первое и в данном случае единственное, что нам надо найти, — это функция
main. В начале стартового кода после выполнения процедуры
sub_406992 программа совершает прыжок на метку
loc_406109:

Для перехода на метку достаточно поставить на нее текстовый курсор и нажать Enter. Если подвести курсор мыши к метке или вызову функции, появится окно, в котором будет показано начало выбранной функции или место листинга, куда переводит метка, что очень удобно.

В данном случае, как мы видим по комментарию, IDA отправила нас в начало стартового куска кода. Немного прокрутим листинг вниз, обращая внимание на плавные переходы по меткам.

РЕКОМЕНДУЕМ:
Способы обхода защиты и взлома программ

В итоге доходим до вызова функции:
call    sub_4010D0. Похоже, это и есть функция
main, поскольку здесь дизассемблер смог распознать строковую переменную и дал ей осмысленное имя
aHelloSailor, а в комментарии, расположенном справа, для наглядности привел оригинальное содержимое
Hello, Sailor!\n. Смещение этой строки компилятор закинул на вершину стека, а затем ниже через строчку, по всей видимости, происходит вызов функции вывода на экран:

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

Если поместить курсор в границы имени
aHelloSailor и нажать Enter, IDA автоматически перейдет к строке, в которой выполняется определение переменной:

Выражение
DATA XREF: sub_4010D0+3↑o называется перекрестной ссылкой и свидетельствует о том, что в третьей строке процедуры
sub_4010D0 произошло обращение к текущему адресу по его смещению (
o от слова offset), а стрелка, направленная вверх, указывает на относительное расположение источника перекрестной ссылки.

Если навести курсор на выражение
sub_4010D0+3↑o и нажать Enter, то IDA Pro перейдет к следующей строке:

Нажатие Esc отменяет предыдущее перемещение, возвращая курсор в исходную позицию.

К слову, дизассемблер W32Dasm даже не смог распознать строковую переменную.

Что не так с IDA?

Положа руку на сердце — я был слегка разочарован, ибо ожидал, что IDA распознает больше библиотечных процедур. Поэтому я решил натравить «Иду» на такую же программу, но сгенерированную более ранней версией компилятора. Подопытным кроликом был Visual C++ 8.0 (VS 2005).

Сравним результаты работы компиляторов. Тот же исходник, компиляция из командной строки (папка
first05). Загрузим итоговый экзешник в «Иду». Листинг приводится в сокращенном виде для экономии пространства.

Мало того что стартовый код меньше по объему, так еще было автоматически определено большее количество библиотечных функций, среди которых: GetVersionExA, GetProcessHeap, HeapFree и ряд других. Среди них достаточно просто найти вызов main и перейти на саму функцию.

На этом анализ приложения
first.cpp можно считать завершенным. Для полноты картины остается переименовать функцию
sub_4010D0 в
main. Для этого подведите курсор к строке
.text:004010D0 (началу функции) и жмите N. В появившемся диалоге можете ввести
main. Результат должен выглядеть так:

Обратите внимание: IDA в комментарии подставила прототип функции, а ниже параметры по умолчанию.

Анализ зашифрованных программ в IDA

Другое важное преимущество IDA — возможность дизассемблировать зашифрованные программы. В примере
Crypt00.com используется статическое шифрование, которое часто встречается в «конвертных» защитах. Между тем этот файл не запустится в Windows 10, поскольку *.com для работы требует 16-разрядную исполняемую среду.

Я думаю, это не повод отказаться от анализа столь интересного примера, тем более что существуют мощные средства виртуализации, поэтому поставить 32-битную Windows XP, которая выполняет 16-битные проги, — не проблема. К тому же анализ файлов .com значительно проще, чем .exe, так как первые сильно короче вторых.

Мы уже видели непроходимые заросли библиотечного кода, вставленного компилятором в минимальной exe-программе, тогда как в com все по минимуму, в чем мы скоро убедимся. Отмечу также, что последней версией IDA Pro, работающей в 32-разрядных средах, была 6.8.

Рассматриваемый прием шифрования полностью «ослепляет» большинство дизассемблеров. Например, результат обработки файла
Crypt00.com при помощи Sourcer выглядит так:

Самостоятельно Sourcer не сумел дизассемблировать половину кода, оставив ее в виде дампа. С другой стороны, как-то помочь ему мы не можем. Напротив, IDA изначально проектировалась как дружественная к пользователю интерактивная среда. В отличие от Sourcer-подобных дизассемблеров, IDA не делает никаких молчаливых предположений и при возникновении проблем обращается за помощью к человеку. Результат анализа «Идой» файла
Crypt00.com выглядит так:

И тут необходимо помочь дизассемблеру. Новички в этой ситуации обычно ставят курсор на соответствующую строку и нажимают клавишу C, заставляя IDA дизассемблировать код с текущей позиции до конца функции. Несмотря на кажущуюся очевидность, такое решение ошибочно.

Данные

Что представляет собой число
10Dh в строке
0x100 — константу или смещение? Очевидно, в регистр SI заносится смещение, потому что впоследствии операнд по этому смещению в памяти интерпретируется как байт и над ним выполняется операция XOR.

Чтобы преобразовать константу в смещение, установите текстовый курсор на
10Dh и нажмите O. Дизассемблируемый текст станет выглядеть так:

IDA Pro автоматически создала новое имя
locret_1010D, которое ссылается на зашифрованный блок кода. Попробуем преобразовать его в данные. Для этого надо поставить курсор на строку 010D и дважды нажать D, чтобы утвердительно ответить на вопрос во всплывающем диалоге. Листинг примет следующий вид:

Но на что именно указывает
word_1010D? Понять это позволит изучение следующего кода:

После того как в регистр SI попадает смещение, начинается цикл, который представляет собой простейший расшифровщик: значение в регистре SI указывает на символ, команда XOR с помощью числа
0x77 расшифровывает один байт (один ASCII-символ). Напомню, в ассемблере запись шестнадцатеричных чисел вида 77h. После этого инкрементируется значение регистра SI (указатель переводится на следующий символ) и получившееся значение сравнивается с числом
0x124, которое равно общему количеству символов для расшифровки.

РЕКОМЕНДУЕМ:
Отладка MIPS с помощью GDB

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

Давайте расширим сегмент подопытной программы. Жмем Shift-F7 (View → Open subviews → Segments), откроется вкладка Program Segmentation. В контекстном меню единственного существующего сегмента
seg000 выбираем пункт Edit Segments (Ctrl-E). В диалоге в поле ввода End address введите значение побольше, например
0x10125. Подтвердите свое намерение в появившемся диалоге.

Можете полюбоваться на увеличившийся сегмент. Вернемся к изучению кода. Если в результате сравнения значение в регистре SI меньше общего количества байтов или равно ему, выполняется переход на метку
loc_10103 и блок кода повторяется для расшифровки следующего байта. Отсюда можно заключить, что
word_1010D указывает на начало последовательности байтов для расшифровки. Подведя к ней курсор, жмем N и можем дать ей осмысленное имя, например
BeginCrypt. А константу
124h можем сначала преобразовать в смещение (Ctrl-O), а затем переименовать, например в
EndCrypt.

Расшифровка

Непосредственное дизассемблирование зашифрованного кода невозможно — предварительно его необходимо расшифровать. Большинство дизассемблеров не умеют модифицировать анализируемый текст на лету, и до загрузки в дизассемблер исследуемый файл должен быть полностью расшифрован.

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

Достоинство IDA заключается в том, что она позволяет выполнить ту же задачу значительно меньшими усилиями, никуда не выходя из дизассемблера. Это достигается за счет того, что в IDA есть механизм виртуальной памяти. Если не вдаваться в технические тонкости, можно упрощенно изобразить IDA в виде прозрачной виртуальной машины, которая оперирует с физической памятью компьютера. Для модификации ячеек памяти необходимо знать их адрес.

Слева каждой строки указывается имя сегмента и его смещение, например
seg000:0103. Но нам нужно другое значение. Установив текстовый курсор на нужную строку, смотрите на нижнюю часть текущей вкладки (полагаю, у вас это IDA View-A).

При перемещении курсора соответствующее смещение тоже меняется (на рисунке выше оно обведено рамочкой). С его помощью можно обратиться к любой ячейке сегмента. Для чтения и модификации ячеек предусмотрены функции
Byte и
PatchByte соответственно. Их вызов может выглядеть, например, так:
a=Byte(0x01010D) читает ячейку, расположенную по смещению
0x01010D;
PatchByte(0x01010D,0x27) присваивает значение
0x27 ячейке памяти, расположенной по смещению
0x01010D. Как следует из названия функций, они манипулируют ячейками размером в один байт.

Знания языка C и этих двух функций вполне достаточно для написания скрипта-расшифровщика.

Реализация IDA-С не полностью придерживается стандарта, в частности IDA не позволяет разработчику задавать тип переменной и определяет его автоматически по ее первому использованию, а объявление осуществляется ключевым словом
auto. Например,
auto MyVar, s0 объявляет две переменные —
MyVar и
s0.

Для создания скрипта необходимо нажать Shift-F2 или выбрать в меню File пункт Script Command. В результате откроется окно Execute script. Большую его часть занимают список скриптов и поле ввода для редактирования выбранного скрипта.

Дополнительно внизу окна находятся ниспадающий список для выбора используемого языка (IDC или Python), ниспадающий список для указания размера табуляции и четыре кнопки: Run (выполнить скрипт), Export (экспортировать скрипт в файл), Import (загрузить скрипт из файла) и Save (сохранить скрипт в базу данных проекта).

После первого открытия окна в списке скриптов по умолчанию выбран скрипт Default snippet. В качестве его тела введем такой код:

Как было показано выше, алгоритм расшифровщика сводится к последовательному преобразованию каждой ячейки зашифрованного фрагмента операцией
XOR 0x77:

Сам же зашифрованный фрагмент начинается с адреса
0x01010D и продолжается вплоть до
0x010123.

В конце командой
Message отправляем модифицированный символ в область вывода IDA.

Чтобы запустить скрипт на выполнение, достаточно нажать кнопку Run. Если при вводе скрипта не было опечаток, листинг примет следующий вид:

А в окне вывода появится надпись

Возможные ошибки: несоблюдение регистра символов (IDA к этому чувствительна), синтаксические ошибки, неверно заданные адреса границ модифицируемого блока. В случае ошибки необходимо подвести курсор к строке
seg000:010D, нажать клавишу U (для удаления результатов предыдущего дизассемблирования зашифрованного фрагмента) и затем C (для повторного дизассемблирования расшифрованного кода).

Символы перед фразой «Hello, World!» не выглядят читаемыми; скорее всего, это не ASCII, а исполняемый код. Поставим курсор на строку
seg000:010D, жмем C («Преобразовать в инструкцию»). В результате листинг будет выглядеть так:

Цепочку символов, расположенную начиная с адреса
seg000:0115, можно преобразовать в удобочитаемый вид, если навести на нее курсор и нажать A. Еще можно преобразовать константу
115h в строке 010F в смещение. Теперь экран дизассемблера будет выглядеть так:

Команда
MOV AH, 9 в строке
seg000:010D подготавливает регистр AH перед вызовом прерывания
0x21. Она выбирает функцию вывода строки на экран, а ее смещение следующей командой заносится в регистр DX. Иными словами, для успешного ассемблирования листинга необходимо заменить константу
0x115 соответствующим смещением.

Но ведь выводимая строка на этапе ассемблирования (до перемещения кода) расположена совсем в другом месте! Одно из возможных решений этой проблемы — создать новый сегмент и затем скопировать в него расшифрованный код. Это будет аналогом перемещения кода работающей программы.

Создание сегмента

Для создания нового сегмента надо открыть вкладку Segments (Shift-F7) и нажать Insert. Появится вот такое окно.

Базовый адрес сегмента может быть любым, если при этом не перекрываются сегменты
seg000 и
MySeg; начальный адрес сегмента задается так, чтобы смещение первого байта было равно
0x100; размер нового сегмента сделаем таким же, как
seg000. Не забудьте выбрать тип создаваемого сегмента: 16-битный сегмент.

Далее будем двигаться поэтапно. Сначала скопируем команды для вывода символов в консоль. Начнем брать байты со смещения
10D сегмента
seg000, а вставлять — с самого начала сегмента
MySeg. Это можно сделать скриптом следующего содержания:

Для его ввода необходимо вновь нажать комбинацию клавиш Shift-F2. Создать еще один скрипт можно нажатием Insert. После выполнения экран дизассемблера будет выглядеть так (показано только начало сегмента
MySeg):

Надо преобразовать данные в инструкции: поставить курсор на строку
MySeg:0100 и нажать C. Листинг примет ожидаемый вид:

Чтобы программа-клон вела себя немного не так, как ее родитель, добавим ожидание ввода символа. Для этого надо поставить курсор на команду
retn и выбрать Edit → Patch program → Assemble…

Введите
XOR AX, AX, нажмите Enter. Затем
INT 16h, снова Enter. Последняя инструкция — RET, Enter и Esc для закрытия диалога.

Теперь с помощью следующего скрипта скопируем байты, составляющие текст «Hello, World!»:

Поставив курсор на строку
MySeg:010C, нажимаем A и преобразуем цепочку символов в удобочитаемый вид. В строке
MySeg:0102 надо изменить константу
115h на фактическое значение, по которому расположена фраза для вывода:
MySeg:010C. Для этого ставьте курсор на указанную строку и открывайте диалог Assemble Instruction (Edit → Patch program → Assemble…) и введите
MOV DX, 10Ch.

РЕКОМЕНДУЕМ:
Режим гаммирования в блочном алгоритме шифрования

Теперь надо преобразовать константу
10Ch в смещение, а последовательность символов, расположенную по нему, обратить к светскому виду. Как это делать, вы уже знаете. Напоследок рекомендую произвести косметическую чистку — уменьшить размер сегмента до необходимого. Чтобы удалить адреса, оставшиеся при уменьшении размеров сегмента за его концом, поставьте флажок Disable Address в окне свойств сегмента.

Казалось бы, можно уже начать ассемблирование, однако не стоит спешить! У нас в программе есть три смещения, которые являются указателями. В дизассемблированном листинге они выглядят прекрасно:

1. mov     si, offset BeginCrypt в сегменте
   seg000;
2. cmp     si, offset EndCrypt в сегменте
   seg000;
3. mov     dx, offset aHelloWord_0 в сегменте
   MySeg.

Между тем после ассемблирования символьные имена будут заменены числовыми константами. Будут ли в таком случае в результирующей программе эти смещения указывать на те же вещи, что в исходной? Давайте еще раз проанализируем наш листинг. Первое смещение,
BeginCrypt, указывает на строку
seg000:010D. По сути, весь предыдущий код будет скопирован, поэтому ее значение менять не нужно. Второе смещение,
EndCrypt, указывающее на конец сегмента, должно увеличиться на четыре байта, так как мы добавили две инструкции:

Чтобы подсчитать их размер, достаточно из следующего за ними смещения вычесть их начальное: 118h – 114h = 4h байта. В результате
EndCrypt должно указывать на 124h + 4h = 128h. Установите курсор на строку
seg000:0107, вызовите окно ассемблера и замените инструкцию в ней на
cmp si, 128h.

Третье смещение,
aHelloWord_0, в исходной программе равно
10Ch. Подумаем, как должен измениться адрес. Если
aHelloWord_0 находится в сегменте
MySeg, то нам просто нужно прибавить к имеющемуся смещению размер расшифровщика в сегменте
seg000. Его можно посчитать как разность начального смещения зашифрованного блока и начального адреса: 0x010D – 0x0100 = 0xD байт.

В итоге смещение
aHelloWord_0 должно указывать на 0x10C + 0xD = 0x119. Изменим код: установив курсор на строку
MySeg:0102, с помощью встроенного ассемблера модифицируем ее содержимое на
mov dx, 119h.

В результате полный листинг выглядит следующим образом:

Создание клона

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

Для решения этой задачи напишем скрипт, автоматически выполняющий копирование и шифрование необходимых частей программы:

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

Итоги

Выполнение скрипта приведет к созданию файла
crypt01.com, запустив который можно убедиться в его работоспособности — он выводит строку на экран и, дождавшись нажатия любой клавиши, завершает работу.

Огромным преимуществом такого подхода является сквозная компиляция файла, то есть дизассемблированный листинг в действительности не ассемблировался! Вместо этого из виртуальной памяти байт за байтом читалось оригинальное содержимое, которое за исключением модифицированных строк идентично исходному файлу. Напротив, повторное ассемблирование практически никогда не позволяет добиться полного сходства с дизассемблируемым файлом.

Дизассемблер и отладчик в связке

Дизассемблер, включенный в отладчик, обычно слишком примитивен и не может похвастаться богатыми возможностями. Во всяком случае, дизассемблер, встроенный в WinDbg, недалеко ушел от DUMPBIN, с недостатками которого мы уже сталкивались. Насколько же понятнее становится код, если его загрузить в IDA!

Чем же тогда ценен отладчик? Дело в том, что дизассемблер из-за своей статичности имеет ряд ограничений. Во-первых, исследователю приходится выполнять программу на «эмуляторе» процессора, «зашитом» в его собственной голове, следовательно, необходимо знать и назначение всех команд процессора, и всех структур операционной системы (включая недокументированные).

Во-вторых, начать анализ с произвольного места программы не так-то просто — требуется знать содержимое регистров и ячеек памяти на текущий момент, а как их узнать? С регистрами и локальными переменными еще не так плохо — достаточно покрутить экран дизассемблера вверх и посмотреть, какие значения им присваиваются. Но этот фокус не пройдет с глобальными переменными, модифицировать которые может кто угодно и когда угодно. Вот бы установить точку останова… но какая же в дизассемблере может быть точка останова?

РЕКОМЕНДУЕМ:
Распаковка исполняемых файлов на примере банковского трояна GootKit

В-третьих, дизассемблирование вынуждает реконструировать алгоритм каждой функции, в то время как отладка позволяет рассматривать ее как «черный ящик» со входом и выходом. Допустим, имеется у нас функция, которая расшифровывает основной модуль программы. В дизассемблере нам придется сначала разобраться в алгоритме шифрования (что может оказаться совсем не просто), затем переложить эту функцию на язык IDA-С, отладить ее, запустить расшифровщик… В отладчике же можно поручить выполнение этой функции процессору, не вникая в то, как она работает, и, дождавшись ее завершения, продолжить анализ уже расшифрованного модуля программы.

Можно перечислять бесконечно, но и без того ясно, что отладчик отнюдь не конкурент дизассемблеру, а, напротив, партнер. Опытные хакеры всегда используют эти инструменты в паре. Алгоритм реконструируется в дизассемблере, а все непонятные моменты оперативно уточняются прогоном программы под отладчиком.

При этом возникает естественное желание видеть в отладчике все те символьные имена, которые были внесены в дизассемблерный листинг. И IDA Pro предоставляет два способа это сделать! Рассмотрим оба.

Способ 1

Вернемся в Windows 10 и загрузим в IDA Pro файл
first.exe (или ранее созданный «Идой» проект). Выберем в меню File подменю Produce file, а в нем — пункт Create MAP file. На экране появится окно с запросом имени файла (введем, например,
first.map), а затем откроется модальный диалог, уточняющий, какие имена стоит включать в map-файл. Нажмем Enter, чтобы оставить все галочки в состоянии по умолчанию.

Мгновение спустя на диске образуется файл
first.map, содержащий всю необходимую отладочную информацию в map-формате Borland. Отладчик WinDbg не поддерживает такой формат, поэтому перед его использованием файл необходимо конвертировать в формат DBG — отладочный формат Microsoft.

Конвертировать можно с помощью утилиты map2dbg, свободно распространяемой вместе с исходными кодами. Запускать ее нужно из командной строки. В один каталог с ней кладем map-файл и соответствующий .exe. Затем в нашем случае выполняем команду
map2dbg first.exe.

В результате утилита выведет число преобразованных символов, а в текущей папке будет создан новый файл с расширением dbg. Теперь можно загрузить
first.exe в WinDbg. При этом, если
first.dbg находится в том же каталоге, файл подхватится автоматически и будет скопирован в системную папку
C:\ProgramData\dbg\sym\first.dbg\ для дальнейшего исследования экзешника.

Сейчас в WinDbg надо выполнить команду
.reload /f. Она заставит отладчик перезагрузить информацию из модулей. Затем можете выполнить
lm, чтобы увидеть список загруженных модулей. Модуль first будет отмечен как codeview symbols, иначе было бы deferred:

Исполнение команды
x first!* выведет все символы в файле
first.exe (показана только малая часть списка):

Посмотрим содержимое системной переменной:

Способ 2

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

У бесплатной версии IDA Pro есть и другие недостатки: некорректное создание выходных файлов (в том числе map-файла), некорректное построение диаграммы и прочие пока не затронутые нами вещи.

Теперь можно подключить WinDbg к IDA. Для этого надо открыть конфигурационный файл
ida.cfg, находящийся в каталоге
С:\Program Files\IDA 7.0\cfg\. Проматываем его содержимое до такой строки:

Ниже или вместо нее вставить путь к инструментам отладки WinDbg. В моем случае:

Отсюда вытекает третья мудрость: в случае с IDA 7.0 и новее, даже если приложение дизассемблируется и отлаживается в 32-битной разновидности IDA, путь надо указывать к 64-битной WinDbg. Иначе при запуске отладки вас ждет сообщение об ошибке.

Следующим шагом надо запустить IDA, выбрать WinDbg из ниспадающего списка на панели задач и, нажав F9, запустить отладку. Только отладка приложения
first.exe закончится, не успев начаться. Нужно сделать так, чтобы на точке входа программа замерла. Для этого надо вызвать диалоговое окно Debugger setup (пункт Debugger options в меню Debugger).

Нашу задачу призвана решить область Events. Здесь можно выбрать, на каких событиях мы хотим подвешивать программу. Поставим третий флажок Suspend on process entry point, в результате чего выполнение проги приостановится на стартовом коде.

Знакомые места? Еще бы! Обратите внимание: программа оперирует регистрами процессорной архитектуры x86-64: RCX, RDX, RCI и так далее. Ядро Windows 10 экспортирует 1595 символов, учитывая все установленные обновления операционной системы на моем компьютере.

Это можно проверить, дважды щелкнув на модуле
kernel32.dll в окне Modules во время отладки IDA Pro. Откроется дополнительная вкладка Module: KERNEL32.DLL. Ее можно отцепить и перетащить в любое место. На нижней части рамки окна отображается общее количество символов, экспортируемых данным модулем.

Подключение WinDbg к IDA позволяет «Иде» использовать символьную информацию модулей с публичного сервера Microsoft. Для этого можно создать переменную окружения или определить директорию непосредственно из IDA без ее перезапуска. Пойдем второй, более короткой дорогой, а создать переменную окружения вы можете на досуге. В командную строку IDA (в нижней части окна рядом с кнопкой WINDBG) введи:

После этого перезагрузите символы командой
.reload /f. Число экспортируемых модулем
kernel32.dll символов стало 5568.

Теперь символьные имена не только отображаются на экране, что упрощает понимание кода, — на любое из них можно быстро и с комфортом установить точку останова (скажем,
bp GetProcAddress), и отладчик поймет, что от него хотят! Нет больше нужды держать в памяти эти трудно запоминаемые шестнадцатеричные адреса!

РЕКОМЕНДУЕМ:
Взлом приложений для Андроид с помощью отладчика

Заключение

IDA — очень удобный инструмент для модификации файлов, исходные тексты которых утеряны или отсутствуют. Это практически единственный дизассемблер, способный анализировать зашифрованные программы, не прибегая к сторонним средствам. Ну и конечно, IDA обладает отличным пользовательским интерфейсом и удобной системой навигации по исследуемому тексту. В результате с таким инструментом в руках вы можете справиться с любой мыслимой и немыслимой задачей… если, конечно, владеете языком скриптов, что и подтвердили приведенные выше примеры.