Я выложил свой первый туториал по анализу 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 <--

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

vnekrilov я уже посмотрел ничего там нового нет, ну константы все поменялись это естественно.

-----
Yann Tiersen best and do not fuck

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

ASPack.v2.25.incl.patch-KITA

>>> DOWNLOAD <<<

OR

>>> DOWNLOAD <<<

P.S.: может пригодится кому

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

При распаковке TranslateIt! 8.1 build 1 на шаге "Восстановление секции ресурсов .rsrc" Resource Binder v3.1 при создания бинарного дампа секции ресурсов выдаёт следующее:


При этом dumped_control.exe становится размером 1.19 Мб против 4.06 Мб до создания бинарного дампа секции ресурсов. Дамп при этом не создаётся.

dumped_control.exe прилагаю вместе с логом работы скрипта.




Вопрос: что не так? куда копать?

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

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

[0utC4St]
По-моему ссыль на него давали несколькими постами ранее

[0utC4St] пишет:
А вот решение к нему в розыске.
плохо ищете значит, оно уже как полгода валяется на каждом углу.

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

PE_Kill пишет:
я уже посмотрел ничего там нового нет, ну константы все поменялись это естественно.

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

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

vnekrilov, что скажите касаемо этого?
(мой пост выше)

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

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

[0utC4St]

Скачал программу, посмотрю, почему имеется ошибка, и напишу ответ.

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

[0utC4St] пишет:
что скажите касаемо этого?

Действительно, Resource Binder v3.1 дает сбой на этой программе. Почему - это, видимо, надо задать вопрос SetiSoft, разработчику этой утилиты. В то же время, более старая версия этой утилиты - Resource Binder v2.6, не страдает этой болезнью, и нормально создает бинарный дамп секции ресурсов. На всякий случай, прикладываю в аттаче эту версию Resource Binder.

ae18_21.11.2010_CRACKLAB.rU.tgz - Resource Binder v2.6.rar

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

vnekrilov пишет:
В то же время, более старая версия этой утилиты

более старая является лишь гуей для консольной утили другого автора

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

vnekrilov, Gideon Vi, спасибо просветили.

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

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

Недавно мне попалась программа, в которой скрип "Восстановление таблицы INIT.osc" дал сбой. Причина этого сбоя была обусловлена тем, что мной, под запись таблиц А и В, и запись раскриптованных адресов таблицы INIT был выделен небольшой объем памяти в 4000h байтов. Из этого объема памяти 50% было выделено под запись хэшей таблиц А и В, и 50% памяти было выделено по запись раскриптованных адресов таблицы INIT. В этой же программе запись хэшей таблиц А и В заняла объем около 3000h байтов, что и привело к сбою работы скрипта. Поэтому я доработал этот скрипт, и увеличил объем выделенной памяти в 10000h байтов. После чего, скрипт нормально отработал, и корректно восстановил таблицу INIT в этой программе. Поэтому замените скрипт "Восстановление таблицы INIT.osc" от 03 июня 2010 года скриптом от 24 ноября 2010 года, который приложен в аттаче к этому сообщению. Благодарю Antoskast3 за присланную им программу, которая позволила найти ошибку в этом скрипте.

537a_24.11.2010_CRACKLAB.rU.tgz - Восстановление таблицы INIT.osc

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

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

-----
Yann Tiersen best and do not fuck

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

PE_Kill пишет:
Не знаю как у тебя скрипты вкупе работают, но под инит таблицу можно и не выделять память

Можно было бы, конечно, все скрипты объединить в один скрипт, как это слелал VolX, но когда возникают какие-то проблемы с работой того или иного скрипта, искать это место сбоя - весьма сложно. Скрипт "Восстановление таблицы INIT.osc" восстанавливает таблицу INIT, и делает дамп этой таблицы с именем "table_INIT.bin". Этот дамп используется при работе скрипта "Восстановление таблицы IAT и вызовов APIs.osc", который вставляется на место нахождения таблицы INIT в памяти распакованной программы. Затем скрипт "Восстановление таблицы IAT и вызовов APIs.osc" выполняет дампирование памяти распакованной программы, и мы получаем дамп, в котором отрезаем лишние секции и прикручиваем секцию дампа со спертыми байтами.
Я получаю достаточно много писем с разными вопросами, в том числе и с сообщениями о сбоях скриптов. Наличие нескольких отдельных скриптов позволяет достаточно быстро вносить нужные изменения и доработки, что облегчает мою работу.

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

Сегодня я выкладываю 16 часть туториала по распаковке Asprotect, в котором приведено решение по поиску проверок целостности кода (CRC) второго типа. Такую проверку, я правда встречал только в программах Asprotect, в которых разработчики этого протектора используют в качестве защиты от восстановления подпрограмм с эмулированными инструкциями. Возможно, что такой метод защиты может встретиться и в других программах, где авторы этих программ применяют в качестве одной из опций эмуляцию инструкций в подпрограммах. Как всегда, буду благодарен за отзывы, замечания и критику.

e713_25.11.2010_CRACKLAB.rU.tgz - Устранение проверок CRC второго типа.rar

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

vnekrilov пишет:
Сегодня я выкладываю 16 часть туториала по распаковке Asprotect
Прошу прощения за ОФФ, но где 15-я часть ?

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

vnekrilov, может быть зальешь актуальные версии скриптов одним архивом?

Tyra пишет:
Прошу прощения за ОФФ, но где 15-я часть ?

rghost.net/3376853

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

vnekrilov моё резюме, если конечно интересно. Я то же занимался вопросом этих странных проверок и пришел к выводу, что это макросы исключительно самого ASProtect.

1) В ASProtect SDK нет ни одного макроса такого маленького размера, значит пользователи банально не знают как вставить такой макрос в код.

2) ASProtect не навешивает эту сложную виртуальную машину на маркеры UserPolyBuffer, но в нем самом все маркеры UserPolyBuffer ведут в VM, а код вырезанных процедур забит мусором. Именно с этим мусором и сверяются новые макросы при проверке. Т.е. такой макрос невозможен, если UserPolyBuffer не уходит в VM, а для обычных пользователей он туда не уходит.

3) Новые макросы портят именно тот регистр, который используется ниже, причем не просто используется, а является базой для каких либо структур. Анализатор в ASProtect очень слабый, я сильно сомневаюсь, что он может так точно предсказывать базовые регистры процедуры. Причем в некоторых процедурах этот регистр используется исключительно в вызываемых процедурах.
-----
По мне так это уже крик отчаяния, использовать для своего протектора кастомную версию протектора и не давать ее лицензионным пользователям, которые должны и дальше защищать свои творения старым гавном, которое еще 5 лет назад полностью снималось на автомате.

-----
Yann Tiersen best and do not fuck

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

Gideon Vi пишет:
может быть зальешь актуальные версии скриптов одним архивом?

Да, наверное так и сделаю

PE_Kill пишет:
моё резюме, если конечно интересно.

Конечно, твое резюме интересно. Я полностью согласен с твоим выводом о том, что эти макросы используются исключительно для Asprotect. Кстати, в последнее время пользователи начали потихоньку использовать макросы для получения подпрограмм с эмулированными инструкциями. Но пока этот чрезвычайно сильный метод защиты применяется довольно редко.

PE_Kill пишет:
По мне так это уже крик отчаяния, использовать для своего протектора кастомную версию протектора и не давать ее лицензионным пользователям, которые должны и дальше защищать свои творения старым гавном, которое еще 5 лет назад полностью снималось на автомате.
+ 1

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

vnekrilov пишет:
Такую проверку, я правда встречал только в программах Asprotect
Встречал я такую проверку в какойто проге, но точно не ASProtect,там проверка велась по такомуже принцепу.

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

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

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

-----
Yann Tiersen best and do not fuck

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

PE_Kill
Я помню точно что после восстановления был адрес call[jmp GetModuleHandleA], а должен указатель на виртуальную часть, так там велась проверка по такомуже прицепу что и писал vnekrilov

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

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

Ну как я и говорил ты путаешь. Это макрос EnvelopeCheck. Один из его вариантов проверяет чтобы в коде были украдены вызовы api (я называю эту вариацию ApiChecker). Когда аспр протектит файл он заменяет

jmp dword ptr [iat] (FF25 XXXXXX)
на
call AsprDll_GetApi (E8 XXXXXX)

Этот макрос как раз и проверяет восстановлены переходники или нет, если вместо E8 стоит FF25/FF15 то портятся регистры или стек. Это стандартный макрос SDK, ему уже лет 5-6.

-----
Yann Tiersen best and do not fuck

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

PE_Kill пишет:
если вместо E8 стоит FF25/FF15 то портятся регистры или стек

Кстати, это стандартная проверка CRC, которая прекрасно снимается скриптом. Для сведения, размер кода, выполняющий эту проверку, составляет 110h байтов.

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

Да я знаю, посмотри папку SDK в ASProtect там эти маркеры есть, сколько они там размером такой и получится в защищаемой программе.

vnekrilov пишет:
Кстати, это стандартная проверка CRC
Это не проверка CRC а проверка Envelope. Отличие в том, что в первом случае проверяется контрольная сумма кода, а во втором проверяется навешан ASProtect или его сняли.

Вот оригинал маркера:


-----
Yann Tiersen best and do not fuck

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

PE_Kill пишет:
Этот макрос как раз и проверяет восстановлены переходники или нет, если вместо E8 стоит FF25/FF15 то портятся регистры или стек. Это стандартный макрос SDK, ему уже лет 5-6.
Ну тогда понятно спс за подсказку.

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

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

PE_Kill пишет:
Это не проверка CRC а проверка Envelope.

Спасибо за уточнение.

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

После выполнения скрипта "Перенаправление прыжков из кода программы в новую секцию файла" возникает необходимость выделить в отладчике область кода программы чтобы сохранить сделанные изменения.
Как быть когда изменения были внесены в несколько секций программы?
Уточню: как оптимально выйти из этого положения?
з.ы. На деле, как правило, основная часть изменений приходится на одну секцию. Из Положения выходил следующим образом: выделял код той секции в которой было больше перенаправлений и сохранял изменения. Затем отдельно сохранял для другой, бинарно сравнивал 2 дампа и вносил изменений в хекс-редакторе в тот дамп, в который меньше писать.

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

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

[0utC4St] пишет:
бинарно сравнивал 2 дампа и вносил изменений в хекс-редакторе в тот дамп, в который меньше писать
мазохист второй раза скрипт запусти, уже на измененном файле

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

SReg пишет:
второй раза скрипт запусти, уже на измененном файле
+1

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

vnekrilov, прочтя "Распаковка Asprotect (часть 15, выпуск 2)" решил покрутить Resource Builder скаченный с офсайта. Поначалу не глянув что версия отличается от версии описанной в статье.
Увидел это когда плаг ODbgScript (1.78.3.0) приказал долго жить,

попутно накрыв мохнатым сейфом и саму ольку.

Кто сталкивался с этим и кто что имеет сказать по этому поводу?

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

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