Я выложил свой первый туториал по анализу ASProtect v2.4 build 12.20 (Анализ подпрограммы эмуляции инструкций.rar http://dump.ru/files/o/o489862518/ ). В этом туториале я подробно описал процесс восстановления эмулированных инструкций типа:


Полный цикл статей по распаковке ASProtect (Актуальная версия 25 декабря 2009):
ASProtect_Unpacking_Tutorial_2009-12-25.rar http://rapidshare.com/files/325720799/ASProtect_Unpacking_Tutorial_2009-12-25.rar 7,9 МБ
Программы, рассматриваемые в статьях:
ASProtect_Unpacking_Apps_2009-12-25.rar http://rapidshare.com/files/325718084/ASProtect_Unpacking_Apps_2009-12-25.rar 22,2 МБ

Буду благодарен за критику, замечания, пожелания и отзывы.

Скрипты:
Текущая рекомендуемая версия ODBGScript [1.78.3]:
ecf1_03.06.2010_CRACKLAB.rU.tgz - ODbgScript.dll

Последний текущий комплект скриптов [от 19 февраля 2011]:
69ca_18.02.2011_CRACKLAB.rU.tgz - Скрипты для распаковки Asprotect от 19 февраля 2011.rar

Статьи по частям:
Актуальная версия статей [Последняя - 25.11.2010]:
Выпуск 2
0754_29.11.2009_CRACKLAB.rU.tgz - Распаковка ASProtect - Часть 1
2844_29.11.2009_CRACKLAB.rU.tgz - Распаковка ASProtect - Часть 2
8e06_30.11.2009_CRACKLAB.rU.tgz - Распаковка ASProtect - Часть 3
50a0_03.12.2009_CRACKLAB.rU.tgz - Распаковка ASProtect - Часть 4
1b51_05.12.2009_CRACKLAB.rU.tgz - Распаковка ASProtect - Часть 5
0ff8_05.12.2009_CRACKLAB.rU.tgz - Распаковка ASProtect - Часть 5 (продолжение)
a182_06.12.2009_CRACKLAB.rU.tgz - Распаковка ASProtect - Часть 6
82b8_15.12.2009_CRACKLAB.rU.tgz - Распаковка ASProtect - Часть 7
74e4_16.12.2009_CRACKLAB.rU.tgz - Распаковка ASProtect - Часть 8
b2e1_17.12.2009_CRACKLAB.rU.tgz - Распаковка ASProtect - Часть 9
532c_18.12.2009_CRACKLAB.rU.tgz - Распаковка ASProtect - Часть 10
76af_20.12.2009_CRACKLAB.rU.tgz - Распаковка ASProtect - Часть 11
fe67_22.12.2009_CRACKLAB.rU.tgz - Распаковка ASProtect - Часть 12
079c_20.01.2010_CRACKLAB.rU.tgz - Распаковка ASProtect - Часть 13
8415_03.06.2010_CRACKLAB.rU.tgz - Распаковка Asprotect - Часть 14
0a66_18.02.2011_CRACKLAB.rU.tgz - Распаковка Asprotect - Части 15 и 16

DriEm конвертировал мой цикл статей в формате PDF, который можно скачать по ссылке --> Link <--

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

n0name пишет:
У меня создалось ощущение что цикл ориентирован на результат - распаковка аспра, а не на его исследование.

Вы абсолютно правы - цикл ориентирован на распаковку аспра, и очень сжато даны основные моменты, которые проясняют некоторые вещи. Более подробный анализ некоторых элементов аспра я излагал в RAR-статьях, которые выложены на Crack@Lab. Если Вас интересуют этот анализ, прочитайте эти статьи.

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

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

kanck666
Спасибо, пошёл качать )))
n0name
Полностью согласен, частично может помочь просмотр самих скриптов, но хотелось бы описание того, как это было получено, т.е. описание исследований.
vnekrilov пишет:
Но это Вы можете, при желании, сделать сами.
Ну, если так рассуждать, то мы всё при желании можем сделать сами, но сколько у вас ушло времени на исследование и написание скриптов? Жалко убить столько времение, тем более если кто-то уже это сделал.

-----
Stuck to the plan, always think that we would stand up, never ran.

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

А самому посмотреть содержимое скриптов, потрейсить код на магических байтах? Или должна была быть цель составить документированные сорсы прота?
Можно конечно, однако на это уйдет куда больше времени, чем если бы основные блоки были немного описаны.
Хотя да, скрипты и цикл очень помогут.
Вы абсолютно правы - цикл ориентирован на распаковку аспра
С этой позиции цикл очень замечательный
Я сам не специализируюсь на распаковке АСПРа, не часто он мне попадается, поэтому хотелось увидеть фишки именно этого протектора. Частично описано в статьях, частично сам исследовал. Спасибо за скрипты и хоть небольшие, но описания внутренностей

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

ARCHANGEL пишет:
но сколько у вас ушло времени на исследование и написание скриптов?

Кстати, на исследование и написание скриптов ушло не так уже и много времени. Намного больше времени ушло на написание и оформление цикла статей. Первое, что нужно было выяснить - это какая подпрограмма в Asprotect.dll выполняет определенные действия - заполнение таблицы IAT, запись прыжков в области со спертым кодом, и т.д. Это было достаточно легко сделать, устанавливая брекпойнты на запись. Вторая часть работы - это поиск одинакового кода в этих подпрограммах, чтобы сделать универсальный шаблон для поиска этих подпрограмм в разных версиях прота. Вот она заняла немного больше времени, поскольку надо было найти программы, упакованные разными версиями прота, и их проанализировать.

ARCHANGEL пишет:
но хотелось бы описание того, как это было получено, т.е. описание исследований.

Исследования почитайте в RAR-статьях.

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

vnekrilov, у Вас в статьях (на скринах) русская Олька, причём очень хорошо русифицированная.
Не поделитесь вашим дистрибутивом?
з.ы. в сети есть недорусифицированная, собсна и на cracklab нашел её же.

-----
z+7v+/Lq4CAtIO/l8OL76SD44OMg6iDv8O7i4OvzLiCpIMPu7OXwINHo7O/x7u0=

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

[0utC4St] пишет:
Не поделитесь вашим дистрибутивом?

Можете скачать по ссылке multi-up.com/192869

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

Распаковал программу Event Log Explorer v 3.0, и в ней оказалась одна интересная изюминка, которая мне раньше не попадалась. В ней протектор заполнил таблицу Импорта мусорным кодом, в результате чего скрипт "Восстановление секции импорта (.idata) в распакованных программах.osc" не смог работать. Пришлось вручную вводить начало секции Импорта, которая находится перед таблице IAT, поскольку программа написана на Delphi. Кроме того, после восстановления импорта, дамп не загрузился в отладчик, и показал ошибку. Просмотр дампа в PE Tools v1.8.800.2006 RC7 показал, что в директории импорта имеется несколько "Error", поскольку разделительные ноли перед таблицей IAT были заполнены мусорным кодом. Пришлось загружать дамп в отладчик, и 14h байтов перед таблицей IAT заполнять нолями. После чего, программа нормально загрузилась в отладчик, и запустилась. Придется еще поработать над доработкой скрипта "Восстановление секции импорта (.idata) в распакованных программах.osc". Убедительная просьба ко всем - если у Вас попадутся какие-либо нюансы с использованием этого скрипта, сообщите мне об этом. Это позволит его качественно доработать.

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

Если ещё актуально то я придумал способ получения полного имени с правельным расширением используемых бибблиотек

c9e9_29.12.2009_CRACKLAB.rU.tgz - test.txt

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

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

Спасибо за материал, я посмотрю.

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

При расспаковке одного файла скриптВосстановление таблицы IAT и вызовов APIs давал сбой при просмотре нашёл где скрипт остановился
eval "{call_const}"
asm temp_1,$RESULT==============>error(Result="CALL PdfPC8.007D25A4")

оказывается в call_const записан адресс вместе с именем , нашёл код в скрипте где заносится
данные в call_const

opcode temp_1
mov call_const,$RESULT_1

решил заменить н команду opcode temp_1 на GCI temp_1, COMMAND
но эффек такойже, оказалось на много проще в настройках зашёл Disasm=>Show local module name
убрал галочку и в переменную стало записыватся правельные значения

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

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

ClockMan пишет:
оказалось на много проще в настройках зашёл Disasm=>Show local module name
убрал галочку и в переменную стало записыватся правельные значения

Я давно у себя убрал флажок с параметра Disasm=>Show local module name, в настройках отладчика, поэтому у меня такой проблемы никогда не возникало.

ClockMan Спасибо за замечание, надо это учесть в шапке скриптов.

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

ClockMan пишет:
я придумал способ получения полного имени с правельным расширением используемых бибблиотек

Здесь я хочу поблагодарить ClockMan за его очень ценные советы и замечания по работе скрипта "Восстановление секции импорта (.idata) в распакованных программах.osc". Благодаря его подсказкам и советам, я доработал этот скрипт, в котором:
1. Предусмотрел ручной ввод начала таблицы Импорта, если протектор Asprotect заполняет ее мусором.
2. Ввел определение имени библиотеки, путем получения полного пути, и извлечения из полного пути имени библиотеки.
3. Исправил ошибку в скрипте, связанную с проверкой имени API в ntdll.dll и kernel32.dll. Теперь имена APIs записываются правильно.

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

В аттаче приложен откорректированный скрипт "Восстановление секции импорта (.idata) в распакованных программах.osc" от 06 января 2010 года.

2649_06.01.2010_CRACKLAB.rU.tgz - Восстановление секции импорта (.idata) в распакованных программах.osc

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

offtop
vnekrilov пишет:
от 06 января 2009 года
СНовым 2010 Годом!
/offtop

-----
127.0.0.1, sweet 127.0.0.1

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

OKOB

Спасибо за указанную ошибку. Всегда в начале Нового Года почему-то живу несколько дней в Старом Году. Текст топика я поправил, а Вы в скриптах сами исправьте дату.

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

vnekrilov пишет:
Распаковал программу Event Log Explorer v 3.0, и в ней оказалась одна интересная изюминка, которая мне раньше не попадалась. В ней протектор заполнил таблицу Импорта мусорным кодом, в результате чего скрипт "Восстановление секции импорта (.idata) в распакованных программах.osc" не смог работать. Пришлось вручную вводить начало секции Импорта, которая находится перед таблице IAT, поскольку программа написана на Delphi. Кроме того, после восстановления импорта, дамп не загрузился в отладчик, и показал ошибку. Просмотр дампа в PE Tools v1.8.800.2006 RC7 показал, что в директории импорта имеется несколько "Error", поскольку разделительные ноли перед таблицей IAT были заполнены мусорным кодом. Пришлось загружать дамп в отладчик, и 14h байтов перед таблицей IAT заполнять нолями.

Проблема осталась и в доработаном скрипте "Восстановление секции импорта (.idata) в распакованных программах.osc" от 06 января 2010 года.
Мне кажется что все дело в строчке 310 : FILL Start_Import_Table,Size_Import_Table-14,00.
В ней таблица импорта обнуляется меньше, как раз на тех 14h байт, добаленных в строчке 140 : add Size_Import_Table,14.

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

badzed пишет:
В ней таблица импорта обнуляется меньше, как раз на тех 14h байт, добаленных в строчке 140

Это в скрипте сделано сознательно. Мне попадались упакованные программы, у которых, если не вычесть эти 14h байтов, то затирались первые APIs в таблице IAT. Поэтому я и ввел эту команду. Лучше вручную поправить таблицу Импорта (обнулить эти 14h байтов), чем повредить таблицу IAT.

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

Уже почти 2 года я смотрю на эту тему, и до сих пор не понял тайного смысла попыток вогнать восстановление иморта в убогий оллискрипт. Шаманство с импортом это больше трети всего функционального кода аспа. Сдампите скриптом замангленую таблицу, перестройте ее внешней тулзой, и залейте обратно. Деманглер импорта займает меньше 3000 строк на С++, а формат не менялся уже последних офицальных билдов 20.

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

DrGolovaВсе тузлы которые мне известны восстонавливают по сишному шаблону и ниодна неможет восстановить по дельфийскому варианту...

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

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

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

А тайного смысла нет. Можно секцию импорта прикрутить в конец распакованной программы, как это делает ImpREC. А можно восстановить эту секцию на ее родное место, как это можно сделать с помощью скрипта в ODbgScript. Все это - отдано на усмотрение юзера. Лично мне, больше нравится загнать секцию импорта на ее родное место, поэтому я предложил такой вариант во втором выпуске статей.

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

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

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

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

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

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

Gideon Vi пишет:
во-первых, так интереснее.
Согласен.

Gideon Vi пишет:
Во-вторых, категорически уверен, что на написание статей времени было потрачено больше, чем на разбор.
Может быть, во всяком случае проделанная работа меня впечатляет.

Gideon Vi пишет:
В-третьих, инлайн - это не красиво
А вот тут я с вами не согласен, категорически не согласен, но может быть каждому своё....

Added:
vnekrilov пишет:
Но, когда имеется набор скриптов, то распаковка программы занимает намного меньше времени, чем инлайн.
А вот тут чуть-чуть вы не правы, юбо для инлайна тоже есть скрипты, которые писать ИМХО быстрее этак раз в 10. Ну а то, что насчёт кусков кода которые в инлайне дописывать не очень удобно.....это конечно да, но иногда это обходиться обычным копипастом.
Ну вот наткнулся на либу одну - которую никак заинлайнить не получаетцО, её проще расспаковать.
Вообщем ещё раз повторюсь и скажу - что кому как удобнее. Для меня например лучше сначала попробывать заинлайнить, а вот потом уже распаковать, а для некоторых всё наоборот.

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

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

Да, инлайн хорош, если имеется валидный регистрационный ключ. А если его нет, то приходится дописывать целые куски кода, что делать в инлайне не очень удобно.
И второе. Например, если проводить исследование создания протектором Asprotect.dll (а это очень интересный процесс), то без восстановления подпрограмм с эмулированными инструкциями здесь не обойтись. Ведь разработчики заэмулировали именно те подпрограммы, которые делают наиболее интересные вещи, и таких подпрограмм в протекторе - около двух десятков.
И третье. Да, написание статей занимает довольно много времени. Но, когда имеется набор скриптов, то распаковка программы занимает намного меньше времени, чем инлайн.

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

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

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

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

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

DrGolova пишет:
в убогий оллискрипт.
Чем меньше средств тем лучще для мозга Да кой же он убогий если есть асм
А табличку писать в оригинал иногда необходимо не только для аспра да и вообще полезный навык

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

pavka пишет:
А табличку писать в оригинал иногда необходимо не только для аспра да и вообще полезный навык

Обоими руками ЗА!!!

pavka

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

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

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

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

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

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

Вполне возможно, что я что-то не так понял. Просто мысли...

-----
Stuck to the plan, always think that we would stand up, never ran.

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

ARCHANGEL
ты всё правильно понял
голова в своё время выкладывал подобную тулзу с сорсами

-----
EnJoy!

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

vnekrilov пишет:
Я надеюсь на то, что кто-то также встречался с такой подменой библиотек, и поделится этой информацией.
Распарсил я таблицу эспорта kernel32.dll и вытащил ашь 30шт подменных api список прилагаю в аттаче


940d_12.01.2010_CRACKLAB.rU.tgz - Import ntdll to kernel32 restore full.txt

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

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