Эта тема по распаковке AsProtect'a последних версий, для надругательств выбрана программа: AlfaClock 1.82
сайт программы: www.alfasoftweb.com/rus/
прямая ссылка: www.alfasoftweb.com/rus/AlfaClock_rus.exe

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

За флейм будем наказывать!

Нашел ОЕР inferno_mteam
004C5444 55 PUSH EBP
004C5445 8BEC MOV EBP,ESP
004C5447 83C4 C0 ADD ESP,-40
004C544A 53 PUSH EBX
004C544B 33C0 XOR EAX,EAX
004C544D 8945 D4 MOV DWORD PTR SS:[EBP-2C],EAX
004C5450 8945 D0 MOV DWORD PTR SS:[EBP-30],EAX
В Ольке можно быстро попасть на ОЕР сл. образом, открываем программу, жмем Ctrl+G (перейти на строку) вбиваем туда ОЕР=04С5444, правой кнопкой мыши: Breakpoint->Hardware, on execution
после чего отключаем все Exceptions: menu->Options->Exceptions и ставим все галочки, .теперь нажите F9 и вы на ОЕР

-----
Подписи - ЗЛО! Нужно убирать!

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

SergSh пишет:
VОЕР после прохода в ESP+4c. Прога Microsoft Visual C++ 6.0. IAT целая. Обкод для восстановления функций IAT сегодня FF15.
Это ты уже по новой проге, на которую я дал ссылку? Или нет? Прогу дампим в месте ее 1-го бряка
в секции кода?
SergSh пишет:
т.к CALL Dumped_.006B6394 и есть сама программа.
Правильно. И когда этот Call отрабатывает, идет переход на
/*7B102C*/ CALL Dumped_.0040913C. А у меня нет. И вообще, у меня такое впечатление, что я какую-то
системную библиотеку не подключил. Потому что прога падает, где-то после вызовов Uses32. Да бог
с ней! Я и так много подчеркнул, ее распаковывая.

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

Да это по Cros.exe. Дампим как только VOEP будет распаковано в памяти. В окне дампа пишим D addr VOEP и Shift+9 пока не увидим распакованные команды с VEOP. Далее переходим на адрес 00401000 делаем поиск келов, восстанавливаем импорт и сниваем дамр. Нужна ссылка на Сишную прогу запакованную этим Аспром, но без VM, для того, чтобы посмотреть начало. Если у тебя есть, то подкажи. Я думаю так будет быстрее распаковать. А по той проге всё из-за того, что ты не с того места дампил. У меня при закрытии проги вообще наг не выходит.

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

Порыскав маленько мне понравился DivX Player.exe запакованный старой версией Аспра, его начало и возьмём за основу. Конечно у меня не очень красиво получилось, но я начинающий:
/*973000*/ PUSH EBP
/*973001*/ MOV EBP,DWORD PTR SS:[ESP+30]
/*973005*/ SUB EBP,-53
/*973008*/ MOV EBP,NOV_1.004B0CD2
/*97300D*/ RCR EBP,0D7
/*973010*/ ADD EBP,DWORD PTR SS:[ESP+18]
/*973014*/ LEA EBP,DWORD PTR SS:[ESP+ESI+29]
/*973018*/ SUB EBP,ESI
/*97301A*/ LEA EBP,DWORD PTR SS:[EBP-29]
/*97301E*/ PUSH -1
/*973020*/ PUSH DWORD PTR SS:[ESP+20]
/*973024*/ PUSHFW
/*973026*/ PUSH ECX
/*973027*/ AND ECX,EBP
/*973029*/ LEA ECX,DWORD PTR SS:[EBP+ESI*2+73]
/*97302D*/ LEA ECX,DWORD PTR DS:[ECX+EBP-73]
/*973031*/ SUB ECX,EBP
/*973033*/ LEA ECX,DWORD PTR SS:[ESP+4A]
/*973037*/ LEA ECX,DWORD PTR DS:[ECX-4A]
/*97303B*/ LEA ECX,DWORD PTR DS:[ECX+EAX+6]
/*97303F*/ SUB ECX,EAX
/*973041*/ PUSH EAX
/*973042*/ ADC EAX,ECX
/*973044*/ LEA EAX,DWORD PTR SS:[EBP+7C3D50]
/*97304A*/ SUB EAX,EBP
/*97304C*/ PUSH EAX
/*97304D*/ POP DWORD PTR DS:[ECX]
/*97304F*/ POP EAX
/*973050*/ POP ECX
/*973051*/ POPFW
/*973053*/ PUSH 4E
/*973055*/ PUSHFW
/*973057*/ PUSH ECX
/*973058*/ OR ECX,EBP
/*97305A*/ XOR ECX,EBP
/*97305C*/ ADD ECX,DWORD PTR SS:[ESP+18]
/*973060*/ SHL ECX,0AE
/*973063*/ LEA ECX,DWORD PTR SS:[ESP+EDX+74]
/*973067*/ SUB ECX,EDX
/*973069*/ LEA ECX,DWORD PTR DS:[ECX+EDX-74]
/*97306D*/ SUB ECX,EDX
/*97306F*/ LEA ECX,DWORD PTR DS:[ECX+6]
/*973072*/ PUSH EDX
/*973073*/ LEA EDX,DWORD PTR DS:[EBX+ECX*2+29]
/*973077*/ SUB EDX,29
/*97307A*/ SUB EDX,ECX
/*97307C*/ LEA EDX,DWORD PTR DS:[EDI+6E5BD8]
/*973082*/ SUB EDX,EDI
/*973084*/ MOV DWORD PTR DS:[ECX],EDX
/*973086*/ POP EDX
/*973087*/ POP ECX
/*973088*/ POPFW
/*97308A*/ MOV EAX,DWORD PTR FS:[0]
/*973090*/ PUSH EAX
/*973091*/ MOV DWORD PTR FS:[0],ESP
/*973098*/ SUB ESP,58
/*97309B*/ PUSH EBX
/*97309C*/ PUSH ESI
/*97309D*/ PUSH EDI
/*97309E*/ MOV DWORD PTR SS:[EBP-18],ESP
/*9730A1*/ CALL DWORD PTR DS:[<&kernel32.GetVersion>]
/*9730A7*/ XOR EDX,EDX
/*9730A9*/ MOV DL,AH
/*9730AB*/ MOV DWORD PTR DS:[899870],EDX
/*9730B1*/ MOV ECX,NOV_1.0048A9EE
/*9730B6*/ SUB ECX,13
/*9730B9*/ ADD ECX,A06AE93C
/*9730BF*/ LEA ECX,DWORD PTR DS:[EAX+4D]
/*9730C2*/ LEA ECX,DWORD PTR DS:[ECX-4D]
/*9730C5*/ AND ECX,0FF
/*9730CB*/ MOV DWORD PTR DS:[89986C],ECX
/*9730D1*/ SHL ECX,8
/*9730D4*/ LEA ECX,DWORD PTR DS:[ECX+EDX]
/*9730D7*/ MOV DWORD PTR DS:[899868],ECX
/*9730DD*/ SHR EAX,10
/*9730E0*/ MOV DWORD PTR DS:[899864],EAX
/*9730E5*/ PUSH 1
/*9730E7*/ CALL NOV_1.006EBB86
/*9730EC*/ POP ECX
/*9730ED*/ TEST EAX,EAX
/*9730EF*/ JNZ SHORT NOV_1.009730F9
/*9730F1*/ PUSH 1C
/*9730F3*/ ADD BYTE PTR DS:[EAX],AL
/*9730F5*/ ADD BYTE PTR DS:[EAX],AL
/*9730F7*/ ADD BYTE PTR DS:[EAX],AL
/*9730F9*/ CALL NOV_1.006ED71C
/*9730FE*/ TEST EAX,EAX
/*973100*/ JNZ SHORT NOV_1.0097310A
/*973102*/ PUSH 10
/*973104*/ ADD BYTE PTR DS:[EAX],AL
/*973106*/ ADD BYTE PTR DS:[EAX],AL
/*973108*/ ADD BYTE PTR DS:[EAX],AL
/*97310A*/ XOR ESI,ESI
/*97310C*/ MOV DWORD PTR SS:[EBP-4],ESI
/*97310F*/ CALL NOV_1.006F6040
/*973114*/ CALL DWORD PTR DS:[<&kernel32.GetCommandLineA>]
/*97311A*/ MOV DWORD PTR DS:[89B0C4],EAX
Следующая процедура полностью проэмулирована в разных участках памяти, поэтому с ней придётся повозится...
Да хотел спросить "Где ВСЕ?",а то как то неудобно становится.

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

SergSh пишет:
Если у тебя есть, то подкажи
Есть старая версия ASProtect 1.22 - 1.23 Beta 21 -> Alexey Solodovnikov, находится
webfile.ru/538899
А вообще, я похожую прогу на Microsoft Visual C++ 6.0 разбирал, там было следующее начало:
01B86B4F 55 PUSH EBP ; 1 команда
01B86B61 8BEC MOV EBP,ESP ; 2 команда
01B86B63 6A FF PUSH -1 ; 3 команда
01B86B65 68 A82AC200 PUSH 0C22AA8 ; 4-
01B86B6A 68 DCEBAA00 PUSH 0AAEBDC ; 5-
01B86B6F 64:A1 00000000 MOV EAX,DWORD PTR FS:[0] ; 6-команда (21 байт)
Итак 21 байт,далее пропускаем мусор
01B86B90 50 PUSH EAX ; = еще 1 байт (Итак 22 байта)
01B86BA2 64:8925 0000000>MOV DWORD PTR FS:[0],ESP ; 7- эмуляция ESP
01B86BA9 83EC 58 SUB ESP,58 ; 8- (32 байта)
01B84297 53 PUSH EBX ; 33 байта
01B842C4 56 PUSH ESI ; 34 байта
01B842F1 57 PUSH EDI ; 005616A8 (35 байтов)
01B84303 8965 E8 MOV DWORD PTR SS:[EBP-18],ESP ; Все 38 байтов!!!

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

Думаю чистить код необходимости нет т.к. его очень много. За ссылку спасибо.
Принцип восстановления основной ветки такой: с VOEP копируем все байты в чистое место, в вашем дампе с восстановленным импортом, (исключая не нужные прыжки только типа JMP) до первого CALL ( у меня он был CALL 13А0000, у вас будет другим) исключая комманду РUSH перед CALL. Трассируйте этот CALL по F7 пока не вайдёте до команды JMP [esp-4] (трассировать придётся достаточно долго и эти байты копировать не надо), ставим F2 на адресс JMPа и F7. Теперь сного копируем все байты до CALL 13А0000, далее F9, сработал бряк на JMP [esp-4], F7 и т.д. Адреса ведущиие в прогу преобразуем в CALL addr. Адрес команды JMP [esp-4] изменяется с каждым перезапуском проги, но находится там-же +-50 байт. Подскажу, что в CALL 006E4EFB по адресу 40109Е есть прыжёк в память его нужно изменить JMP SHORT 006E4F0D это облегчит восстановление. Структуру самой основной ветки можно подсмотреть в DivX Player.exe, это облегчит задачу по восстановлению циклов. Пока вроде-бы всё получается. Сам код приводить не буду, он занивает много места.

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

SergSh пишет:
у меня он был CALL 13А0000
У меня этот адрес 019A1C10 CALL 02180000 (1-е обращение, для определенности). Я пока только изучая прогу.
Трассировал по F7 по немногу. Переход JMP [esp-4] не нашел (из текста не ясно, где снималось значение [esp]. По нашел очень интересное место, на которое, наверно, и ты наткнулся.
Это:
02180154 CALL NEAR ESI (или 0218013E CALL NEAR EAX) и так далее. Адрес и команда
Call <регистр> каждый раз разная, но в принципе, можно написать скрипт, считавающий каждый раз новое месторасположение этой команды.
Я подробно описал это место к тому, что оно очень похоже на call EAX в предыдущей проге (IcomLover), когда в EAX таблица адресов переходов, по которым выполняется прога. Правда в данном случае, в ЕАХ (или ESI) фигурирует один адрес - 01787088 (у тебя конечно другой, но последние 4 цифры наверно совпадут).
SergSh пишет:
Теперь сного копируем все байты до CALL 13А0000 [/i]
Извини, не понял. Обращение типа CALL 13А0000 у меня идут из секции 019A1C10 ( у тебя по другому). До следующего обращения CALL 13А0000 я прохожу еще через несколько секций притом
по 10-ку раз (см. trace). Ты предлагаешь это все копировать? Или я не правильно понял?

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

Да ты не првилино понял, 01787088 это не надо, трассируй дальше, есть что-то похожее на CALL EAX исполняется в цикле в последнем CALLе этогот цикла и есть JMP [esp-4] так что трассируй. А копировать надо все байты с VOEP до CALL 13А0000 и после JMP [esp-4] до следующего CALL 13А0000 затем бряк на JMP [esp-4] и т.д. Правда с циклами трудновато,легко запутаться.

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

Приведённая выше процедура /*97310F*/ CALL NOV_1.006F6040 не верна, поторапился, пришлось всё начать с нуля. Следи за стеком, по адресу 6ЕАСЕ0 будет RET. Ну очень тяжело идёт.

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

Я понял, что ты собирался сделать.
У меня ВМ начинается с вызова из секции 019А0000 (размер 5000) типовых команд Call 02180000 (у тебя
13А0000). Заканчивается же этот вызов в секции 02190000. В конце этой секции находим:
021900A3 JMP NEAR [DWORD SS:ESP-4], который ведет вновь в область 019А0000. Там несколько команд и вновь Call 02180000.
Сейчас думаю написать скрипт, переделывающий Call 02180000 в что-то вроде jmp XXXX, где ХХХ - это
адрес, хранящийся в [DWORD SS:ESP-4]. А потом уже можно и дампить. Секцию 019А0000 придется копировать полностью.

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

Попробуй. Но смитри за стеком, т.к. и пропускаем несколько celloв. Особенно посмотри команды типа
mov ESI,[ESP+8], должно стать mov ESI,[ESP+4].

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

SergSh
А ты заметил, что при обращении к ВМ и выходе из нее по команде JMP NEAR [DWORD SS:ESP-4] в вершине стека одно и то же число. И значение регистров остаются прежними. Правда в глубине стека, т.е. изменение локальных переменных все же происходит. Интересно, а в Олли можно посмотреть изменение переменных, например так же, как и в отладчике Си или дельфи. В Олли есть опция Inspect,
ты ей пользовался?

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

Да заметил. На этой основе и предложил использование JMP NEAR [DWORD SS:ESP-4] в качестве отправной точки при восстановлении. Но я начинающий и этим всё сказано.

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

Дошёл до Call 51с630. Там происходит запуск проги, но самое главное идёт дораспаковка файла и следовательно меняется и адрес JMP [esp-4] учти это при написании скрипта. Откуда ты взял это "чудо", сдаётся мне она запакована дважды. Об этом сведетельствует взня с функциями похожая на создание новой IAT в этом же Callе.
Said100- если первая команда PUSH EBP, затем JMP ...... то это и есть VOEP/

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

SergSh пишет:
сдаётся мне она запакована дважды
На счет дважды не знаю. Но известно, что аспр - это только 1-я линия защиты проги.
Скрипт я практически написал. Но меня смущает то, что по ходу выполнения проги встречаются 3 обращения к ВМ. Я потом прога запускается. А как быть с другими обращениями? Ведь для того, чтобы узнать адрес возврата, надо пройти через ВМ, а я не прохожу? Смысл использования скрипта для определения адреса возврата и патча команды Call 02180000 (обращения к ВМ) теряется. Поэтому пока, я
сдампил прогу, предварительно восстановив некоторые эмулированные аспром апи-функции, полностью подключил секцию 019A0000 (в ней код проги перемешан с мусором аспра, в ней расположена VOEP) и
вручную начал менять вызовы Call 02180000 на Jmp <адрес возврата>. Пока идет, что дальше будет - посмотрим. Может потом соображу, как лучше писать скрипт.

said100 пишет:
Распаковываю Aspr 1.23-rc4
Ты бы лучше, чем писать кучу кода в топике, дал ссылку. Можно было бы тогда, что-нибудь по делу подсказать. А то там, в основном, мусор.

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

В общем, я немного поторопился. Переделал скрипт и он проходит через все функции, а не через 3, как
писал ранее. У меня он вроде отработал, хотя конечно, его надо еще доделывать. Я там написал в примечаниях. Пока результаты выводит в лог-файл. И еще. Хотелось бы услышать идеи по объединению
скрипта по восстановлению апи-функций и вызовов в ВМ. Ведь прежде, чем дампить, надо восстановить
часть апи-функций. Кстати, напоролся на грабли. Восстановил апи-функции, но не посмотрел, что в скрипте прописано восстановление ввиде jmp XXX, а не Call XXX. Теперь придеться все по-новому делать.

c267_call_vm.osc

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

Кажется всё понял. Ищем CALL 13А0000 нашли, записали в переменную, New origin here на этот адрес, бряк на JMP [esp-4] после сработки бряка в EIP записываем адрес из переменной, а на месте CALL 13А0000 вбиваем JMP адрес из JMP [esp-4], примерно всё как с IAT, только возврат искусственный и т.д. Всё будет в одном месте и прога на месте стоит, затем дампим этот участок памяти, затем восстанавливаем импорт в проге дампим, дописываем к дампу проги новую секцию размером 5000 и с помощью WinHex вставляем дамп памяти в дамп проги, затем ImportRECом прикручиваем импорт. Примерно такой алгоритм, опустив пока дораспаковку и встроенные адреса. Как сразу не сообразил? Старею. Завтра попробую.

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

SergSh
Да, примерно так. По крайней мере первые 3 вызова в ВМ я прошел в легкую. Но потом доработал скрипт и понял, что в ручную это будет очень долго, там более 100 вызовов. Сейчас остановился и пытают доработать в скрипте блок, который будет менять CALL 13А0000 на JMP (адрес возврата). Там есть сложность. Если JMP в пределах одной секции - то он имеет два байта, а если в другую (т.е в секцию кода) - то размер команды 5 байт. А есть и те и другие. Значит надо писать еще и алгоритм распознования адреса возврата.
said100 пишет:
Сылкук дать немогу так как прога единственная
Раз он купил, значит есть рег. номер. А если ты ломаешь - значит есть в этом резон.
Ведь наверняка шеф не заглядывает сюда.
Ну так выбери минимальную рабочую конфигурацию (exe + др), можешь переименовать и в webfile.
А иначе я подсказать не могу. Может кто-нибудь другой?

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

Я думаю тут стоит подумать а Jmpы ли должны быть. Я больше склоняюсь к CАLLам, а переводить адрес надо обязательно и PUSHа перед CALLом. Кстати подсажи методу, а то я где-то видел, но боюсь долго буду искать.

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

Борьбу с PUSHами я кажется придумал. Было так
/*1340A57*/ PUSH EBP
/*1340A58*/ PUSH 1340AD2
/*1340A5D*/ CALL 013A0000
/*1340A62*/ PUSH EDI
Стало так
/*1340A57*/ PUSH EBP
/*1340A58*/ CALL 013A0000
/*1340A5D*/ JMP SHORT 01340AD2
/*1340A5F*/ NOP
/*1340A60*/ NOP
/*1340A61*/ NOP
/*1340A62*/ PUSH EDI
Байтов всегда хватает и можно всегда писать CALL 013A0000, т.к. первоначально предпологалось там где есть PUSH 1340AD2, то ниже будет JMP. И к тому же в дампе не будет недорозумений и вообщем легко это сделать в скрипте. Я проверил, это работает прекрасно. Остаётся один вопрос как определить нужные байты возпращаемого адреса в дампе, чтобы он стал в место CALL 013A0000. Так ка простог VA-RVA явно не достаточно. Грамотные научите.

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

SergSh пишет:
Я больше склоняюсь к CАLLам,
Ты знаешь, я начинал в ручную так, например:
019A02F6 68 79139A01 PUSH 19A1379
019A02FB E8 00FD7D00 CALL 02180000 (Ret_function = 006E6D36)
меняем на
019A02FB E9 366AD4FE JMP 006E6D36 (и все, больше ничего не трогаю).

SergSh пишет:
PUSHа перед CALLом
Но ведь не везде же идет PUSH перед Call, например:
019A047F 59 POP ECX
019A0480 E8 7BFB7D00 CALL 02180000 (Ret_function = 019A1FD0)
меняем на
019A0480 E9 4B1B0000 JMP 019A1FD0
Если использовать в этой конструкции CaLL>>CaLL, то тогда нужно будет перед ней вносить
PUSH (адрес возврата), а это по-моему сложно.

С другой стороны, что-то пока у меня не очень получается с эмулированием команд Jmp (адрес возврата).
там разные опкоды используются. На короткий переход я написал, а на более длинный - пока нет.
Здесь же нужно интерпретировать опкоды команд, а это уже функции диссассемблера. Ну не на скриптах же это писать! Ну еще попробую.

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

Писал ответ не видя предыдущего сообщения.
НЕ совсем понял твою задумку.
SergSh пишет:
/*1340A58*/ CALL 013A0000
/*1340A5D*/ JMP SHORT 01340AD2
/*1340A5F*/ NOP

Вместо CALL 013A0000 в дампе ты хочешь писать Call (Адрес возврата), так что ли?

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

Да. Call (Адрес возврата из JMP [esp-4]). И при этом дамп это участка памяти будет обсалютно корректным и его можно будет прикрутить к проге. Но вопрос о смещении пока открат. Попробуй.

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

Для чего это всё я тебе сейчас расскажу. Если делать так как ты говориш, то PUSH 19A1379 так и останется в дампе, и куда потом перейдёт JMP 006E6D36 отработав. Ведь подгружать дамп на тоже место это не серьёзно. В этом вся соль. Просто этот дам работать не будет. Нам надо привязать все относительно существующих адресов, тогда проблема будет решена.

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

SergSh пишет:
PUSH 19A1379 так и останется в дампе, и куда потом перейдёт JMP 006E6D36 отработав.
Мы наверное, говорим все же о разном. Эту секцию 19a0000-19a5000 я полностью прикручиваю к дампу.
Конечно, она встает на другие адреса, например 0970000-0975000. Но я потом с помощью VirtualAlloc создаю в у себя в дампе эту область 19a0000-19a5000 и все из секции 0970000-0975000 переношу во вновь созданную область 19a0000-19a5000. Тогда у меня JMP 006E6D36 отработав в секции кода вновь
возращается в область 19A000-19A500. И не надо ничего менять. Это 10 лишних операторов в начале кода.

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

А если эта область память окажется занята? И с VirtualAlloc не не всё так просто, даже при указании необходимой области нет гарантии, что она будет выделена в лучшем случае он вернёт 0. Да и мы вроде пытаемся разработать общий для в сех машин способ распаковки. Знатоки рассудите нас.

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

SergSh пишет:
А если эта область память окажется занята?
Как она может быть занята, если создается аспром в процессе работы. Ведь при создании дампа эти области в дамп не переносятся.
SergSh пишет:
даже при указании необходимой области нет гарантии, что она будет выделена в лучшем случае он вернёт 0
Это я нашел, как обойти. Все выделяется в нужном виде.
Другое дело, что на иной машине эта выделенная область будет располагаться в другом адресе. Как собственно у нас и получается. Тут ты прав. Но и это, в принципе, можно обойти.

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

Tar4! Ещё один совет для скрипта: каждый CALL 013A0000 необходимо проходить дважды, при этом первый раз необходимо установить флаг Z=0, а второй раз Z=1 и если возвращённые оба раза значения из JMP [esp-4] не равны Следовательно гдето выше в коде есть сравнение и следовательно это необходимо учесть, если же выше сравнения не было то оба значения будут равны, такая методика очень хорошо помогает при распаковке циков. После обнаружения разницы возвращаемых адресов я делал так: ниже, в этом куске памяти, есть достаточно места поэтому я переорентировал CALL 013A0000 в JMPв низ, а там JNZ addr 1 и JMP addr2 соответственно, но учти что значения флага Z должно контролироваться сначало 0 затем 1, иначе будут разные условные переходы, а это замудряет алгоритм исследования.

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

SergSh пишет:
Каждый CALL 013A0000 необходимо проходить дважды
Спасибо. Похоже именно на это я как раз и наткнулся. Скрипт я написал, сдампил прогу и начал ее трассировать. Сначало все шло хорошо, но потом возникла ошибка как раз связанная с JMP [esp-4]. Скрипт не правильно почему-то определил адрес возврата. Я как раз собирался сегодня разбираться с этим. По-видимому, при повторном прохождении скрипт переписал адрес возврата. Надо это как учитывать.

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

Ещё один совет. Обрати внимание на адреса, находящиеся в дампе по адресу 862e04 и ниже. В дампе соответственно по этим адресам ничего нет по этому их все надо переориентировать и записать в них данные из оригинала в районе 40 байт. Там всего 8 адресов. В дальнейшем прога будет их активно юзать. Ещё можно сказать, что предётся переделывать ещё 2 участка памяти, но там методика аналогичная адреса можно видеть по 562b27 и 62b6af соответственно. Вообщем я это вроде всё прошёл но там видимо дальше идут проверки долго возится пока остановился. Но меня не покидают ощущения, что мы делаем не совсем так как надо. К стати дамп надо снимть на VOEP.

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

SergSh пишет:
Обрати внимание на адреса, находящиеся в дампе по адресу 862e04 и ниже.
Я уже наткнулся на это.
Интересно вот что. Я доработал немного скрипт и он теперь проходит по функции два раза и можно визульно увидеть два адреса возврата. И действительно, в некоторых случаях они (адреса) отличаются.
Но ведь в адресе 019A0B8B, где у меня произошла 1-я ошибка, скрипт по-прежнему указывает одинаковые адреса возврата, а если пройти в ручную - то он другой. Не понимаю, почему.
n = 00000026
startscan = 019A0B8B
aftercalladdr = 02180000
esp_ = 0177A810
Ret_function = 019A1F8C
Ret_function = 019A1F8C //Ошибка правильно Stack [SS:0012FF0C]=019A0AD9

SergSh пишет:
К стати дамп надо снимть на VOEP.
То есть ты хочешь сказать, находясь в эмулированной аспром области (у меня она 019A000-019A5000),
а не на секции кода?

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