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

Сначала краткая предыстория. Крякингом я занимаюсь меньше полугода, научился за это время ломать сильно тупые защиты, где разработчик понадеялся на упаковщик/протектор. Автоматическим распаковщиком (или на "полуавтомате" - break'n'enter - EP - bpm esp-4 - OEP - dump - ImpRec) снимаем защиту, патчим пару байт - и готово. Но это, понятно, проходит далеко не всегда. Тупая защита + не самый простой пакер = приехали
И где-то месяца 2 назад я начал писать собственный универсальный распаковщик. Принцип действия у него задумывается такой:
- создаём замороженный поток.
- в EP втыкаем хук (jmp eip, чтобы не трассировать стандартным методом через TF, что обычно палится защитой) отпускаем программу до EP, замораживаем (SuspendThread), снимаем хук.
- далее эмулируем работу подопытной программы на виртуальных регистрах, но на её реальной памяти (Read/WriteProcessMemory).
- при этом ловим программу при возникновении исключений на входе в обработчик и на выходе из него; на возврате из системных вызовов (KiFastSystemCallRet); вообще, полностью отслеживаем передачу управления. Для этого предусмотрено втыкание хука в любое нужное место.
- на всём пути выполнения каким-либо образом запоминаем порядок передачи управления и адреса участков памяти, которые были изменены в адресном пространстве подопытной программы.
- когда доходим до OEP (определим, например, на основе статистики по нескольким файлам, покарёженных одним и тем же пакером), дампим всё, что было изменено.
- восстанавливаем импорт (пока с этим вопросом подробно не разбирался)
- делаем ещё какие-нибудь дополнительные приседания
- получаем рабочий дамп, который можно изучать в дизассемблере

Понятно, что, например, для Armadillo дополнительных приседаний будет очень много, но ASProtect вполне мог бы поддаться на такую провокацию.
С него я и решил начать. Запаковал виндовский блокнот с помощью ASProtect2.1, научился проходить на EP и стал "обучать" свой распаковщик ассемблерным инструкциям по одной. Проверка простая: если при встрече с незнакомой инструкцией актуализировать контекст и отпустить программу (ResumeThread), и она не грохнется, то с большой вероятностью все предыдущие инструкции выучены правильно.

<отредактировано Wolfram>
(Перенёс первый вопрос в свой второй пост, чтобы он не повторялся на каждой странице)

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

| Сообщение посчитали полезным:

2 Archer
Спасибо ещё раз (надеюсь, не последний )

Раскурил мануал по FPU. Вставляет не по-детски! Поэтому пока эмулировал все его команды через исполнение, вроде работает. В Аспре дошёл до OEP!!!!! Пора прикручивать дампер и поиск OEP (сейчас она у меня пока что в тексте анпакера вбита).

Идеи такие:
Трейсить прогу уже знакомым методом от EP и до обеда , попутно запоминая по каким адресам шло управление и модификация. Также фиксировать все вызовы VirtualAlloc и VirtualFree, чтобы иметь в руках список выделенных областей памяти. Когда мы решим, что OEP уже пройдена, мы остановим процесс. Анпакер может подсказать этот момент, но всё равно должна быть возможность трейсить дальше. Затем анпакер выдаст графики передачи управления и модификации памяти в осях [адрес в памяти - количество пройденных команд]. Чтобы размер трейс-файла был не слишком большим, можно запоминать адрес с точностью, например, до 4кб и сохранять трейс в формате [номер участка - количество пройденных в нём команд]. Переход на OEP, скорее всего, будет как-то визуально выделяться (по крайней мере, там обычно кончается самомодифицирующийся код). В итоге, положение OEP определяем мы, задаём его анпакеру, и снова запускаем трейсинг.
Дойдя до OEP, дампим все секции, которые были в исходном файле, плюс все области памяти, которые были выделены и не освобождены, засунув каждую в отдельную секцию. В итоге получаем для любого пакера/протектора рабочий дамп с офигенным количеством секций. Если это пакер или не очень хороший протектор, то с таким дампом уже можно работать - патчить и т.д. Если же прот качественный, то дамп нужно будет ещё каким-либо образом обработать - вернуть краденые байты с функций, убрать проверки CRC, обрезать лишние секции и т.д. Наиболее общие из таких дополнительных задач можно засунуть в основную программу, а узкоспециальные - сделать в виде плагинов.
Основная задача - даже при отсутствии соответствующего плагина в любом ring3 протекторе дойти до OEP и получить рабочий дамп. В нём, по крайней мере, можно будет изучить оставшуюся антиотладку, защиту от дизассемблирования, патча и др. и написать тот самый плагин.

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

| Сообщение посчитали полезным:

Wolfram
Главная проблема не поиск OEP и не дампер. Как у тебя с восстановлением импорта?

з.ы. доходишь до OEP в аспре без антидебага? Если с ним, то как ты проходишь?

| Сообщение посчитали полезным:

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

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

| Сообщение посчитали полезным:

Можешь почитать статью Hump-and-dump: efficient generic unpacking using an ordered
address execution histogram. Там идея на твою похожая. Имеет много ограничений, типа стыренный оеп/несколько процессов и тд. Но идея похожа, возможно, попервой сгодится.

| Сообщение посчитали полезным:

Wolfram
Основная задача - даже при отсутствии соответствующего плагина в любом ring3 протекторе дойти до OEP и получить рабочий дамп.
А какже это рабочий дамп без импорта, без ресурсов?

Конкретное пожелание по импорту: я в "вопросах новичков" поднимал тему про импорт --> Link <-- Суть в том, что все известные мне анпакеры при восстановление импорта берут только имя длл и не учитывают путь к ней. Это не сложно поправить руками в ImpRec, да и QuickUnpack вроде позволяет исправить имя длл (дописать перед именем путь). Но удобнее было бы это автоматизировать - получилась бы уникальная фича. Мелочь, но приятно.

Еще вопрос: когда планируешь выкладывать свой анпакер на всеобщее обозрение? СДК для плагинов начал делать?

| Сообщение посчитали полезным:

Прошу прощения за долгое молчание.

Archer
Спасибо, почитал. Статья отличная.
Стыренный OEP, думаю, можно будет научиться находить на гистограмме. А с многопоточностью возможны варианты. Когда с ней столкнусь - появятся новые вопросы.

user_
На всеобщее обозрение буду выкладывать, когда прикручу поиск OEP и добьюсь стабильного анпака на некотором количестве пакеров/протекторов. Возможность написания плагинов, конечно, будет, но, возможно, не с первой версии (чтобы труд их создателей не пропал даром после исправления мной очередного бага).

SVIN95
Из антидебага в той версии Аспра вроде только исключения, но они у меня отлично ловятся, поэтому и дохожу.
А с импортом - да, осознал, что эта проблема покруче будет , когда начал ею вплотную заниматься. Пока делаю так: дохожу до OEP, делаю дамп (расширяя SizeOfRawData всех секций до VirtualSize) и прикручиваю к нему импорт с помощью ImpREC. Ограничения: иногда ImpREC находит не весь импорт (например в PEspin), а ещё проблема с протекторами, утягивающими часть кода в выделенные области памяти (тот же Аспр). Изначальная идея - сдампить на OEP все области, оставшиеся к этому моменту - потерпела крах. Путём долгих экспериментов в LordPE я выяснил, что файл запустится только если проекции всех его секций в память лежат одна за другой без всяких промежутков, причём в том же порядке, что и в таблице секций. В принципе, эту проблему можно решить, отсортировав области по базовому адресу и добавив между полученными секциями секции-заглушки с атрибутом Discardable и нулевым значением SizeOfRawData. Мне таким способом удавалось добавлять к экзешнику различное количество областей памяти, лежащих _ниже_ заголовка и не по-порядку. Но проблема в том, что куча, а значит, и все выделенные области лежат _выше_ заголовка.

Отсюда вопрос:
Можно ли как-то усовершенствовать такую технику дампа, чтобы обойти эту проблему, или же нужно что-то в ней радикально менять? Ещё хочется узнать (сорри, если вопрос глупый), чем ограничены возможности протекторов по утягиванию кусков кода в виртуальную память?

Теперь вопросы по восстановлению импорта. Хочется попросить знающих людей порекомендовать статьи или ссылки по механизмам и методам импорта, о том, как его можно испортить, сохранив работоспособность файла, и как потом восстановить. В частности, хочу понять, как работает ImpREC, и как некоторые протекторы умудряются прятать от него импорт?

Теперь пару слов о наших успехах:
После исправления критического косяка в определении метода адресации распаковщик научился доходить до OEP ещё в PEspin, FSG, PECompact, WinUpack, MEW. При этом UPX, ASPack, ORiEN, NSPack, PECompact, WinUpack, MEW распаковываются полностью, т.е. после прикручивания импорта получается рабочий дамп!

| Сообщение посчитали полезным:

В FSG импорт не сильно защищен. Так что дерзай. Добавь и его в список поддерживаемых пакеров.

P.S. WinUpack тоже вроде не злой.

| Сообщение посчитали полезным:

Собирать память не всегда удобно, ниже хедера в образ не впишутся полюбас, выше хедера, если их слишком много, задолбаешься собирать, ибо в хедер произвольное число секций не влезет. Поэтому в идеале надо восстанавливать код, ибо могут быть антидампы и тд, на которых свалишься при условии, что даже если ты и соберёшь всё в кучу. Это и будет основная проблема.
А импорт как раз не проблема, его всегда можно восстановить полностью автоматически при грамотном подходе (ну в крайнем случае кой-где ручками чуть подрихтовать). Импрек ищет границы импорта, что есть жопа, поэтому и сам импрек говно и часто лажает. Надо искать обращения к импорту и фиксить их, формат импорта бери из дока по пе формату. Ну и сложности будут с перенаправленным импортом, который указывает не прямо сразу на импортную либу, а на переходник, который ещё фейковые вызовы импорта может делать.
Возможности протов по вынесению кода в выделенную память теоритически не ограничены ничем. Практически релоками, которых обычно нет в оригинальном ехе, некоторые хандлеры сех опираются на хардкоденые адреса ещё, но это в работе с анпакером никак не поможет, 1 хрен.

| Сообщение посчитали полезным:

Обращения к импорту - это call dword ptr[xxxxxxxx] и jmp dword ptr[xxxxxxxx]. Так?

| Сообщение посчитали полезным:

Я бы посоветовал автору и задавшему вопрос выше пополнить раздел практики. Сдаётся мне, он слабоват. Т.е. взять и самому руками пощупать разные проты, поглядеть на импорт, как он заполняется, как восстанавливается, в каких случаях его не находит импрек и тд.
Обращения к импорту далеко не только такие, в чистом виде бывает вызов ещё через регистры типа mov reg32, dword ptr[xxx] ... call reg32. А проты могут извратить, как хотят, включая call xxx, jmp xxx, push xxx, ret и тд.

| Сообщение посчитали полезным:

progopis, Archer
Большое спасибо. То, что практики у меня мало - не отрицаю, буду восполнять пробелы.

Этот пост - не то чтобы очередной progress report, просто не удержался. Я уже говорил, что пока мой анпакер не умеет находить OEP сам, она в тексте прописана. Соответственно, если OEP спёрта, то мы проскочим мимо. Впервые такой проскок случился в Yoda Protector, блокнот запустился, и я в нём даже печатать смог! Конечно, жутко медленно, но зато под полным моим контролем!!!

| Сообщение посчитали полезным:

Прикрутил к своему распаковщику какой-никакой GUI с модулем, рисующим граф передачи управления. Поигрался с разными пакерами и понял, что прав был Hellspawn, когда писал:

Hellspawn пишет:
полезнее было бы накодить эмулятор, засунуть его в длл, вывести основные функции в экспорт и снабдить подробным описанием, вот это было бы полезно и более реально.

Сейчас у меня всё же не распаковщик, а эмулятор. И если сделать его не в виде проги, а в виде библиотеки, то потом можно будет использовать при написании действительно распаковщика. А там уже можно будет сосредоточиться на поиске OEP, восстановлении импорта, собирании кусков кода из памяти, деобфускации и т.д.

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

| Сообщение посчитали полезным:

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

сомневаюсь я, что бы когда-нибудь она (тема) ожила. Вот так бесславно окончилась эпопея с написанием еще одного универсального распаковщика, что, собственно говоря, и следовало ожидать

| Сообщение посчитали полезным:

dimaxmaster пишет:
Вот так бесславно окончилась эпопея с написанием еще одного универсального распаковщика, что, собственно говоря, и следовало ожидать

потому-что изначально была поставлена не правильная задача.

Wolfram пишет:
Сейчас у меня всё же не распаковщик, а эмулятор. И если сделать его не в виде проги, а в виде библиотеки, то потом можно будет использовать при написании действительно распаковщика.

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

-----
[nice coder and reverser]

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным: