Перевод - Введение в реверсинг с нуля, используя IDA PRO.

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

https://yutewiyof.gitbook.io/intro-rev-ida-pro

 

Какой ассемблер использует IDA Pro? МАСМ не понимает, особенно структуры без полной переделки не работают.

 

Ещё вопрос? Есть такая штука как smart_cast, структуры определяющие типы и наследования объектов, в общем, есть ли макрос для IDA Pro, позволяющие восстановить данные. Сейчас те структуры определены как не определённые.

 

ЗЫ: если собираешься рипать, сноси все структуры к черту и выключай локальные переменные. Кроме вреда никакой пользы они не принесут.

 

Это почему сноси, я как раз закончил рефакторить XRayExtensions, я там как раз определял структуры из данных IDA Pro(получил из декомпиляции движка XRay версии 1.0007RC1 ("KD and Co" rev10)), чтобы код был более наглядный и технологичный, в прочим тут можно попробовать UASM переделать, чтобы понимал структуры как есть. Реально, высокоуровневый ассемблер гораздо круче низкоуровневого.
Например, мой пример, есть игровой движок, т.е. игра S.T.A.L.K.E.R. надо её модернизировать, поначалу исходники были недоступны (выложены в свободный релиз в конце 2014). По этому 7 ноября 2010 возник проект XRayExtensions, расширения возможностей движка с помощью ассемблера, расширенный код подключается к новым секциям, и связывается ссылками с основной секцией. Сначала использовалось утилита malandrinus'а и ещё какого перца(добавляется одна секция размером 256 кб, адреса релокаций основной секции не меняются), потом я создал более совершенную утилиту AddCode, там добавляется несколько секций: код, конст-данные, данные, и возможность изменять адреса релокаций основной секции. Для этого проекта используется следующий софт, IDA Pro для разбора и анализа ресурсного и целевого файла, Notepad++ как IDE, и ассемблер МАСМ, который я заменил на UASM.
Вот тут то мне и нужен ассемблер который понимает структуры из IDA Pro как есть.

 

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

 

Оказывается smart_cast это обёртка dynamic_cast в XRay, там ещё используется приведение через виртуальные методы, если есть такой метод, то он используется, иначе используется dynamic_cast.
Вопрос, если макрос в ИДА Про который разгребает поля структуры наследования классов?

--- Сообщение объединено, 29 авг 2019 ---

Ааааа понял, в версии 6.8 нет такой функции, а вот в 7.0 есть, разгребает нормально!

 

Ну а что не так? для других платформ это не мешает, к примеру NES. Только в начале побольше гемора.
https://www.youtube.com/playlist?list=PLxFctBJ9O7-Z6YSrpc7mGSpQU3HdEUlsR

 

Сложность проца и компилеров не сопоставима с 8-битной приставкой, где картриджи по несколько десятков килобайт. Особенно когда адреса кейсов считаются динамически, обязаны быть кратны степени двойки, их гориллиард, а ида такую адресацию не сворачивает. А еще студия обожает делать выравнивания кривыми форматами инструкций, произвольно удлинняя их лишним полем SIB или offset'ом. Или например длинным переходом там, где подходит короткий. Наверное и штаны можно через голову надеть, если много тренироваться, вопрос в том каким количеством времени пассажир готов пожертвовать ради красоты и технологичности исходника.

 

f13nd,

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

 

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

Если на пальцах, допустим есть элемент структуры anystructure.element1, у которого есть оффсет и длина и например он адресуется в листинге как [eax + n], где n можно заменить на anystructure.element1. Одна загвоздка - допустим оффсет меньше 127, а компилер выбрал 4-байтный оффсет, потому что ему так было удобно выравнять код. Директив х86 ассемблера, дающих возможность так тонко настроить формат инструкции я например не знаю. Для переходов есть, для оффсетов/сиб нету. В итоге код на выходе слегка сдвигается (транслятор не станет от балды выбирать неоптимальный формат), если все существующие и гипотетические выравнивания (которых формально нет потому что хорошо совпало) в нем поедут, то какая-нибудь мишура типа кейса jmp [eax*8 + n] начинает передавать управление не туда куда задумано. Плюс могут быть таблицы непонятно откуда взявшихся оффсетов между хрен знает чем и хрен знает чем. Отлаживать множество всех этих нюансов (а их будет целая гора) крайне тяжело, изрядная часть ошибок будет неявная и и не проявится аксесс виолейшном. Такие кривоформатные инструкции надо либо объявлять тупо как данные (если в них нет базы), либо заменять макросом, который сгенерирует нужный формат, либо целенаправленно искать такие нюансы и расставлять алигнменты вручную. Многое от компилера и его настроек зависит, но обычно геморроя достаточно и без дополнительно созданных самому себе сложностей.

 

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

 

Мы говорим о разных вещах. На видео risc-архитектура с одним регистром-аккумулятором. Автор видоса похоже снял трассу эмулятором, пропарсил ее idc-криптом, задефинившим код, и два часа сидел прибирал данные в массивы. Странный подход, ну да и бог с ним. При экспорте не выключил отображение референсов и автокомментов, тоже фиг с ним. Ни одной структуры в получившихся исходниках у него нет, мы говорим о разном вообще.

 

f13nd с трассой это только в случае плаща, там выше ссылка на плейлист, там уже есть чип и дейл, там без данного подхода. Там уже отделяют движок игры, разбирают скрипты с помощью которых строится игровой процесс и тд. Вплоть до того что можно на этих скриптах дальше самому собирать все что хочется https://github.com/g0me3/bfs_nes_cd2/blob/master/bank2.inc

Блин, и как у него на большом экране от такого синего глаза не вытекают %)

 

Это же основные цвета досовской (и не только) палитры, цвета SpaceCadet'а. Олдскул одним словом. Если от мониторов, выпущенных до 97 года, глаза не вытекли, значит ни от чего не вытекут.

 

там был меньше экран, меньше разрешение. Оно не выжигало как ЖК моники. под рукой имеется старый ЭЛТ моник (правда чуть помоложе), там всё вменяемо. Хотя может и ЖК так настроили. Но мы ушли от темы.
Ну вон по чип и дейл вполне себе вменяемый исходник, котоырй удобно можно править, хоть и на асме. Но тогда под консоли на Сях и не писали. Конечно, я понимаю, что с реальным более менее современным приложением, это совсем другой уровень сложности. Но неужели только вариант рипать кусками и на основе этого писать с нуля?

 

Когда-то пару месяцев работал на заводе - глядел в 4 старинных пузыря, управляя 4мя производственными линиями. Очень быстро началась резь в глазах и с каждым днем все хуже, еле доработал эти два месяца. С 97м промахнулся, TCO99 (наклейки такие вешались на переднюю панель монитора) - стандарт эргономичности с которым мониторы стали более-менее безопасны для зрения.

Я пытаюсь донести мысль, что листинг очень условно можно назвать исходным текстом. Во-первых потому что в х86 мнемоническая запись инструкции не тождественна ее способу кодирования и это порождает проблемы с длинами инструкций и выравниваниями. Во-вторых программа может содержать смещения данных относительно чего-нибудь, и это не будет обработано идой как надо, соответственно внося изменения можно получить нерабочий код, потому что смещения поедут. И так далее. А сравнивать очень простую архитектуру с интелом в плане риппинга некорректно, в ней каждая инструкция обычно кодируется единственно возможным образом и нет сложных способов адресации.

Я обычно разбираю всю программу/прошивку/бутладер руками, отключая аргументы и локальные переменные, удаляя структуры, если ида их начнет впаривать. Если между процедурами или данными есть выравнивания до какой-то величины, то обычно весь код такой - между процедурами принудительно вставляются алигнменты. Если на какие-то данные нету референсов - их надо найти, иначе 100% код будет нерабочий. Потом под директиву virtual (в fasm) вставляю указатели на каждую процедуру, чтобы все они были подключены, потом добиваюсь полного совпадения с оригиналом после пересборки (или хотя бы по длинам инструкций), получившийся рип тестируется и если работает нормально, можно попробовать исключить часть процедур и связанных с ними глобальных переменных (под директиву used убрать) или еще какие-то изменения внести, проверяя работоспособность после каждого изменения.

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

 

А тут говорится, что есть еще английская версия: https://weekly-geekly.github.io/articles/458354/index.html

Какую лучше читать, английскую или русскую?

Также, есть ведь еще Reverse Engineering for Beginners, написанная Денисом Юричевым, и еще The IDA Pro Book: The Unofficial Guide to the World's Most Popular Disassembler by Chris Eagle.

Если кто все три читал, есть ли смысл читать эту книгу "Введение в реверсинг с нуля, используя IDA PRO", когда есть две вышеуказанные? И если есть, то в каком порядке лучше читать эти три книги?

По моим настоящим знаниям:
Я в реверсинге нуб, но не полный: по x86 архитектуре я знаю, как найти простые переменные и struct'ы, составить к ним мультипоинтеры и базовый статический адрес, от которого по оффсетам найти конечный адрес переменных после перезапуска программ, знаю где-то около 50 самых часто используемых x86 инструкций и могу писать очень простенькие функции на ассемблере, понимаю базы PE формата и имею базовое представление о memory management Windows'а.

Меня интересует непосредственно реверсинг x86 и x64 приложений на Windows.

 

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

Без разницы, имхо каждая самодостаточная, курса от Нарвахи вполне хватает; та книга по Иде это больше по самому дизассемблеру, а курс посвящен и асму, и регистрам; Юричев изучает все , немного архитектуры винды, немного компиляторы и т.д. Читайте как хотите, как удобно.

 

Имхо с Петзольда и Икзелиона надо начинать.