Руководство по 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 скачать:

https://download.csdn.net/download/larry_zeng1/11122054

Как говорится, если вы хотите хорошо работать, вы должны сначала отточить свои инструменты. При изучении безопасности двоичного кода использование инструментов особенно важно. IDA — это артефакт игры с двоичным кодом. При использовании IDA в прошлом использовались лишь несколько наиболее часто используемых инструментов. Функции, другие функции IDA не изучались, поэтому в духе обучения обратитесь к «Авторитетному руководству IDA pro» (второе издание), напишите эту статью, запишите свой собственный опыт обучения, следующие записи находятся в IDA pro7.0 на платформе Windows

Некоторые бинарные инструменты

В первых двух главах «Авторитетного руководства IDA Pro» я впервые представил несколько инструментов, обычно используемых в бинарных исследованиях. Я кратко напомню некоторые из них и представлю волну:

C++filt：
можно использовать для отображения имени сложной перегруженной функции в C ++.

PE tools：
— это набор инструментов для анализа запущенных процессов и исполняемых файлов в системе Windows.

string：
можно использовать для прямого поиска всех строк в файле elf
Параметр -a означает поиск по всему файлу, параметр -t может отображать смещение каждой строки, а параметр -e может использоваться для поиска дополнительных строк с кодировкой символов, таких как Unicode. кодирование

strip：

Его можно использовать для elf для удаления символов. После удаления символов он по-прежнему поддерживает нормальные функции, но увеличивает сложность обратного проектирования.

Гений, разработавший IDA, — Илфак, и в его личном блоге есть множество руководств по IDA.
https://www.hexblog.com/

Структура каталогов IDA

В корневом каталоге установки IDA есть много папок, и в каждой папке хранится различное содержимое.

cfg: содержит различные файлы конфигурации, базовый файл конфигурации IDA ida.cfg, файл конфигурации графического интерфейса idagui.cfg, файл конфигурации интерфейса пользователя в текстовом режиме idatui.cfg,
idc: содержит основные файлы, необходимые для встроенного в IDA языка сценариев IDC.
ids: содержит файлы символов
loaders: содержит загрузчики, используемые для идентификации и анализа PE или ELF.
плагины: дополнительные подключаемые модули
procs: содержит процессорные модули

Общие ярлыки

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

a: преобразовать данные в строку

f5: разборка в один клик

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

shift + f12: вы можете открыть окно строки, найти все строки одним щелчком мыши, щелкнуть правой кнопкой мыши настройку и установить свойства окна

ctrl + w: сохранить базу данных ida

ctrl + s: выбрать сегмент данных и перейти напрямую

ctrl + колесо мыши: можно настроить размер представления процесса

x: нажмите сочетание клавиш для функции или переменной, чтобы просмотреть перекрестную ссылку

g: переход прямо к адресу

n: изменить имя переменной

y: изменить тип переменной

/: Написать комментарий в интерфейсе псевдокода после декомпиляции

: Скрыть / показать описание типа переменных и функций в интерфейсе псевдокода после декомпиляции. Иногда, когда переменных слишком много, скрыть описание типа намного проще.

;: Напишите комментарий в разобранном интерфейсе

ctrl + shift + w: сделать снимок IDA

u: undefine, отменить определение функций, кодов и данных

Общие настройки

Сделать снимок

Поскольку IDA не предоставляет функцию отмены, если вы случайно нажмете клавишу и вызовете изменение базы данных ida, вам придется начать заново, поэтому не забудьте добавить моментальный снимок, когда вы часто работаете: file -> take database снимок
После добавления снимка будет сгенерирован новый файл базы данных ida, что по сути немного похоже на операцию сохранения как

Сочетание клавиш: ctrl + shift + w

Общие настройки панели меню

view -> open subviews: вы можете восстановить окно отображения данных, которое вы случайно закрыли

windows -> сбросить рабочий стол: вы можете восстановить исходный макет ida

option -> font: вы можете изменить связанные атрибуты шрифта

Добавить смещение адреса в представлении процесса

Можно сказать, что представление процесса в IDA очень простое в использовании.Оно просто и понятно, чтобы увидеть процесс выполнения программы, особенно если смотреть на код ветвления if и код цикла, он может быть очень интуитивно понятным.

Однако мы также можем изменить его, чтобы упростить использование. Если вы добавите смещение адреса в это представление, нам будет очень удобно получить адрес. Вам больше не нужно нажимать пробел, чтобы переключить представление, чтобы найти его. Установите в строке меню: option -> general

После выбора этой опции вы можете увидеть эффект:

Автоматически добавлять комментарии к дизассемблированию

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

То же самое и в строке меню: option -> general

Эффект такой:

Общие операции

Создать массив

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

Сначала щелкните, чтобы выбрать область, которую вы хотите преобразовать в массив:

Затем выберите в строке меню: редактировать -> массив, появится следующее диалоговое окно.

Поясним значение каждого параметра:

Array element size Это значение представляет размер каждого элемента массива (здесь 1 байт), который определяется в соответствии с размером выбранного вами значения данных.

Maximum possible size Это значение рассчитывается автоматически, оно представляет собой максимально возможное значение элементов в массиве.

Array size Указывает количество элементов массива, обычно значения по умолчанию генерируются автоматически в соответствии с вашим выбором

Items on a line Это представление определяет количество элементов, отображаемых в каждой строке разборки, что может уменьшить пространство, необходимое для отображения массива.

Element print width Это значение используется для форматирования. Когда несколько элементов отображаются в строке, оно определяет ширину столбца.

Use “dup” construct : Используйте повторяющуюся структуру, этот параметр может объединять одни и те же значения данных и объединять их в один элемент с повторяющимся спецификатором

Signed elements Указывает, отображать ли данные как подписанные или как неподписанные

Display indexes Отображать индекс, чтобы индекс массива отображался в обычной форме. Если этот параметр выбран, панель параметров Индексы справа также будет активирована для выбора формата отображения индекса.

Create as array Созданный как массив, обычно выбирается по умолчанию.

После создания он становится таким:

)

Вы можете видеть, что эти данные были объединены в массив, где2 dup(0FFh)Таким образом, это означает, что есть два повторяющихся данных 0xff

блок-схема

Свернуть ветви на блок-схеме

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

Эффект такой:

Блоки ветвей могут быть названы сами по себе, чтобы облегчить их обратное понимание

График вызовов функций

Строка меню: просмотр -> графики -> вызовы функций (сочетание клавиш Ctrl + F12)

На этой картинке хорошо видно, как функции вызывают друг друга

Блок-схема функций

Строка меню: вид -> графики -> блок-схема (горячая клавиша F12)

Это фактически похоже на представление процесса разборки, которое поставляется с IDA, его можно экспортировать как отдельную картинку

Создайте структуру:

Создать структуру вручную

Создание структуры осуществляется в окне структур IDA. Эта операция часто используется в pwn-вопросах об уязвимостях кучи.

Как видите, здесь уже есть четыре структуры.Если сама программа существует, вы можете щелкнуть правой кнопкой мыши и выбрать скрыть / показать, чтобы увидеть содержимое конкретной структуры.

Горячая клавиша для создания структуры: вставить

Во всплывающем окне вы можете редактировать название конструкции.

Внизу есть три флажка, первый означает отображение перед текущей структурой (она будет расположена в первой позиции, в противном случае она будет расположена в позиции, выбранной вашей мышью), второй означает, отображать ли новую структуру в окне Третий указывает, создавать ли объединение.

Следует отметить, что размер структуры — это сумма размеров полей, которые она содержит, а размер объединения равен размеру самого большого поля.

После нажатия кнопки ОК устанавливается пустая структура:

Наведите указатель мыши на конечную строку и нажмите сочетание клавиш D, чтобы добавить член структуры. Имя члена по умолчанию представлено field_x, а x представляет смещение элемента в структуре.

В то же время вы можете навести указатель мыши на строку элемента структуры, нажать D, вы можете переключаться между разными размерами байтов

По умолчанию доступны только варианты db, dw, dd (размер 1, 2, 4 байта)

Если вы хотите добавить тип, вы можете установить его в опции -> настроить типы данных (сочетание клавиш Alt + D)

Как показано на рисунке, если пятый и девятый отмечены, появятся dq и xmmword (представляющие 8 байтов и 16 байтов).

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

Как показано на рисунке, необходимо создать 4-байтовый массив из 16 элементов.

Если вы хотите удалить структуру, нажмите клавишу удаления напротив структуры, чтобы удалить

Если вы хотите удалить член, нажмите u (undefine) на члене, но следует отметить, что здесь удаляется только имя члена, а выделенное им пространство не удаляется.

Как показано на рисунке, мы удалили элементы массива field_10 посередине:

Станет так:

20-байтовое пространство, выделенное массивом, не было удалено. Если вы хотите удалить эти пробелы, вам нужно нажать Ctrl + S в первой строке исходных элементов массива, чтобы удалить пространство (Правка -> сжать типы структур)

Фактически вы можете удалить участника

Вы можете использовать горячую клавишу N, чтобы переименовать элементы структуры.

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

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

Можно видеть, что v1 — это адресный указатель вновь созданного фрагмента, а последующие операции должны записывать содержимое в разные позиции смещения фрагмента. Чтобы облегчить обратное наблюдение, мы можем превратить его в структуру с помощьюv1 v1+4 v1+0x48 Такое смещение после создания конструкции будетchar *v1Измените тип наmail *v1, (Ярлык Y может изменять тип и параметры функций и переменных) Это письмо является именем созданной нами структуры, и эффект будет следующим:

Импортировать структуру, объявленную языком C

Фактически, IDA предоставляет более удобный способ создания структуры, заключающийся в непосредственном написании кода для импорта

В View -> Open Subviews -> Local Types вы можете увидеть существующую локальную структуру, щелкните правой кнопкой мыши по вставке в этом окне

Вы можете добавлять новые конструкции:

Это импортирует новую структуру:

Но в то же время мы обнаружили, что такой структуры нет в представлении структуры. Нам нужно щелкнуть правой кнопкой мыши my_structure и выбрать синхронизировать с idb

Итак, вид структуры есть, как показано на рисунке.

Здесь вы обнаружите, что есть еще два неопределенных члена db. Это связано с тем, что ida по умолчанию выравнивает структуру равномерно на 4 байта, а размер структуры равен 0x28.

IDA динамически отлаживает elf:

Здесь я беру эльфа на виртуальной машине Ubuntu в качестве примера для отладки

Сначала скопируйте linux_server64 из папки dbgsrv в каталоге ida в папку elf Ubuntu. Этот elf 64-разрядный и все использует linux_server64. Если вы отлаживаете 32-разрядную программу, вам нужно скопировать linux_server

Не забудьте дать им разрешение и запустить ее в терминале. Эта программа действует как мост между ida и elf на виртуальной машине.

Затем перейдите в ida для настройки:

Выберите в строке меню: отладчик -> параметры процесса

Обратите внимание, что и приложение, и входной файл заполняются по пути эльфа на виртуальной машине, не забудьте добавить имя файла

И каталог заполните каталог, в котором находится elf, без добавления имени файла

hostname — это IP-адрес виртуальной машины, порт — порт подключения по умолчанию

Параметр и пароль обычно не требуются

Нажмите ОК после настройки

Затем вы можете напрямую щелкнуть точку останова в представлении разборки, просто щелкните маленькую синюю точку слева

Нажмите сочетание клавиш F9 в это время, чтобы начать отладку напрямую.

Нажмите горячую клавишу F4, чтобы перейти непосредственно к точке останова и остановить

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

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

Вот несколько часто используемых сочетаний клавиш

F7 Войдите в функцию, вы введете код функции
F8 Перейти, выполнить следующую инструкцию без ввода кода функции
F4 Бежать к курсору (точка останова)
F9 Продолжать работать
CTRL+F2 Завершить запущенный процесс отладки
CTRL+F7 Выполните, чтобы вернуться, и остановитесь, пока не встретится RETN (или точка останова).

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

IDA-python

Внизу IDA находится скромный интерфейс окна вывода, который на самом деле является терминальным интерфейсом: терминалы python и терминалы IDC.

Здесь используется питон версии 2.7. Хотя он немного устарел, нам его достаточно. В приложении IDA нам часто требуется вычислять адрес и вычислять смещение. Вы можете напрямую работать с этим терминальным интерфейсом, что очень удобно.

Конечно, это просто очень простое использование Python, реальное использование IDA-python выглядит следующим образом:

Вот пример с простым обратным вопросом

Эта программа очень проста. Вначале цикл for выполнит XOR всего содержимого функции судейства до 0xc. Это приведет к уничтожению функции оценки непосредственно во время выполнения программы.

Это делает невозможным последующее вынесение решений по флагу.

Здесь нам нужно сначала написать сценарий для восстановления поврежденного содержимого, здесь IDA предоставляет два метода для написания операций сценария, один — это сценарий IDC, другой — сценарий Python.

Вот только краткое введение в IDA-python

IDA-python внедряет код Python в IDA через три модуля Python:

Модуль idaapi отвечает за доступ к основному API IDA.

Модуль idc отвечает за предоставление всех функций в IDA.

Модуль idautils отвечает за предоставление большого количества полезных функций, многие из которых могут генерировать списки Python для различных объектов, связанных с базой данных.

Все скрипты IDApython автоматически импортируют модули idc и idautils, тогда как модули idaapi должны быть импортированы сами по себе.

Вставьте сюда IDApythonОфициальная документация по функциям, Сюда включены все функции, стоит посмотреть

Для решения вышеуказанных проблем нам нужно только создать сценарий, указать байт XOR 0xc в диапазоне 0-181 функции judg, а затем восстановить

judge=0x600B00
for i in range(182):
    addr=0x600B00+i
    byte = get_bytes (addr, 1) # Получить указанное количество байтов указанного адреса
    byte=ord(byte)^0xC
         patch_byte (addr, byte) # Воспроизвести патч для изменения байтов

В файле строки меню -> файл сценария загрузите сценарий python

Затем не определите исходную функцию в функции оценки и повторно создайте функцию (горячая клавиша p), вы можете повторно использовать f5
Все функции, представленные в скрипте, инкапсулированы в модуле idc. Подробности см. в официальной документации.

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

Нажмите PATCH

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

Здесь я использую плагин под названием keypatch для работы, функция исправления, которая поставляется с IDA, не проста в использовании

Установить патч

Это очень просто, руководство находится вgithubЕсть

Загрузите Keypatch.py ​​и скопируйте его в каталог плагина.

IDA 7.0pluginsKeypatch.py

Загрузите и установите модуль keystone python, 64-битные системы должны установить только этот

https://github.com/keystone-engine/keystone/releases/download/0.9.1/keystone-0.9.1-python-win64.msi

После установки вы обнаружите, что есть опция keypatch

Изменить инструкции программы

Что, если мы хотим изменить инструкции самой программы

Как показано на рисунке, мы должны изменить значение 63h

Наведите указатель мыши на изменение строки и нажмите сочетание клавиш Ctrl + Alt + K

Его можно изменить, напрямую введя оператор сборки, и эффект после исправления показан на рисунке:

Здесь будет сгенерировано примечание, чтобы сообщить вам, что здесь был патч, который очень удобен для пользователя.

Затем вы должны установить его в строке меню, чтобы патч действительно вступил в силу.

Таким образом была изменена исходная программа.

Отменить патч

Если вы случайно ввели неправильный патч, вы можете отменить последнюю операцию патча здесь

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

Просмотрите все исправления, щелкните правой кнопкой мыши и выберите «Вернуть», если хотите отменить один

Файл данных экспорта IDA

В строке меню есть возможность создавать различные файлы вывода.

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

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

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

Общее значение именования IDA

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

sub Отправная точка инструкций и подфункций
locret Инструкция по возврату
loc инструкция
off Данные, включая смещение
seg Данные, включая значение адреса сегмента
asc Данные, строка ASCII
byte Данные, байт (или массив байтов)
word Данные, 16-битные данные (или массив слов)
dword Данные, 32-битные данные (или массив двойных слов)
qword Данные, 64-битные данные (или массив из 4 слов)
flt Данные с плавающей запятой, 32 бита (или массив с плавающей запятой)
dbl Число с плавающей запятой, 64 бита (или массив двойной точности)
tbyte Число с плавающей запятой, 80 бит (или число с плавающей запятой повышенной точности)
stru Структура (или массив структур)
algn Инструкции по выравниванию
unk Необработанные байты

В IDA есть общие описательные символы, такие как db, dw и dd, соответственно, представляют 1 байт, 2 байта и 4 байта.

Ошибка декомпиляции IDA

В настоящее время, как правило, встречаются два случая ошибки декомпиляции.

• Во-первых, из-за динамического шифрования программы некоторые сегменты кода программы модифицируются, что приводит к ошибке декомпиляции. В этом случае вам нужно использовать IDA-python для расшифровки волны, а затем выполнить дизассемблирование F5

• Во-вторых, из-за некоторых метафизических проблем что-то пошло не так, как правило, для внесения изменений следуйте подсказкам IDA.

  Например, возникает следующая ошибка:

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

Вы также можете использовать сочетание клавиш Alt + K

Иногда возникала такая ошибка

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

В настоящее время у меня не так много ошибок, как правило, я могу их решить указанными выше способами.

Настроить IDA

Папка cfg в корневом каталоге ida предназначена для хранения файлов конфигурации.

Главный файл конфигурации ida — ida.cfg, а два других файла конфигурации, idagui.cfg и idatui.cfg, соответствуют конфигурации графического интерфейса пользователя и версии IDA в текстовом режиме.

Один, ida.cfg

Этот файл содержит конфигурацию всех опций в option -> general. Вы можете найти соответствующую опцию в файле конфигурации через описание в опции

Вот несколько примеров:

SHOW_AUTOCOMMENTS Указывает, следует ли автоматически создавать комментарий для инструкций по сборке

GRAPH_SHOW_LINEPREFIXES Указывает, следует ли отображать адрес в представлении управления процессом

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

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

INDENTATION Указывает расстояние отступа инструкции

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

Два, idagui.cfg

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

Три, idatui.cfg

Кажется, это используется реже. . . Нечего сказать

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

Однако во всех случаях есть исключения. Две опции в option -> font и option -> colors являются глобальными параметрами. Изменения вступят в силу постоянно. Вам не нужно изменять их в трех указанных выше файлах конфигурации.

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 (она там есть и лежит на поверхности) в этом сервере.