Эта тема по распаковке 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 и вы на ОЕР

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

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

Когда сдампил программу, востановил импорт (без проблем*)
то программа упала тут:
00406B8F 90 NOP
00406B90 $ E8 6B948E00 CALL 00CF0000
00406B95 2A DB 2A ; CHAR '*'
00406B96 8BC0 MOV EAX,EAX
00406B98 $-FF25 08505800 JMP [DWORD DS:<&kernel32.LocalAlloc>] ; kernel32.LocalAlloc
00406B90 - это и есть видимо новая защита импорта про которую говорил Марио, переход идет в секцию аспра, где наша прога благополучно падает.

а вот что мы видим после первой расшифровки секции:
00406B8F 90 NOP
00406B90 E8 946A0C2B CALL 2B4CD629
00406B95 2A8B C0FF2580 SUB CL,[BYTE DS:EBX+8025FF>
00406B9B B2 4C MOV DL,4C
00406B9D 008B C0FF257C ADD [BYTE DS:EBX+7C25FFC0]>
Тут уже изначально всё изгажено, но как аспр определяет какую ф-ию использовать? Сейчас и посмотрим...

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

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

А я нахожу ОЕР так.
1. Сначало отключанию все игноры и запускаю прогу (так быстрее). Смотрю адрес последнего исключения.
2. Включаю (возвращаю обратно) все Exceptions.
3. Пишу простой скрипт, в который вношу адрес последнего исключения

var last
mov last,00F19BF7 // адрес последнего исключения
eob L1
eoe L1
run // до первого исключения
L1:
cmp eip, last
je L2
esto
jmp L1
L2:
cmt eip,"Last Exception"
ret

4. Скртпт отработал и находимся на последнем исключении. Ниже по коду ищу строку ADD ESP,4 (она как правило присутствует) и ставлю бряк (по F2). Так же можно ставить бряк на адрес [esp+4]
5. Далее Shift-F9 и мы на строке ADD ESP,4
6. Убираем бряк, открываем "Memory map" и новый бряк на доступ к области кода 401000 (size С5000)
7. Далее RUN и прерываемся на ОЕР (004C5444 55 PUSH EBP)

Не смог все это объединить в один скрипт. Почему-то после команды esto не срабатывает даже команда pause. Прога просто далее запускается. Может это только у меня на Win2000.

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

reversing.net/viewtopic.php?t=3&start=45 - читайте, хотя ссылка уже и давалась когда-то =)

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

Первую функцию я восстановил вручную так:
Вместо
00406C60 CALL dumpnew_.00406B90
заменил на
00406C60 CALL dumpnew_.004C5FE0 ; Переход в свободное место в конце файла
а там
004C5FE0 ADD ESP,4
004C5FE3 CALL kernel32.GetModuleHandleA ; "Забраннная" аспром функция
004C5FE8 MOV [DWORD SS:ESP],dumpnew_.00400000 ; корректировка стека
004C5FEF PUSH dumpnew_.00406C65 ; адрес возврата
004C5FF4 RETN ; RET used as a jump to 00406C65

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

Getoric[b][/b]
А ты трассировал функцию по адресу 00406C60 ?
Я делал так.
00406B90 CALL 01160000 // поставить бряк по F2
далее F8 (или F9)
00406B90 E8 6F94F600 CALL 01370004 // вызов изменился
теперь трассируем по F7
...
01360007 68 0DAB3A79 PUSH 793AAB0D //в стек заносится адрес API-функции
0136000C C3 RETN //переход на 793AAB0D
переходим в модуль Kenrel32.dll на адрес 793AAB0D
Выше этого адреса можно учидить 3 команды, начиная с
793AAB06 PUSH EBP ; это начало функции
курсор на нее и "View call tree" и видишь название функции.
Что касается корректировки стека, то ее можно и не делать, но надо правильно
обратиться к этой функции (часть выполнения кода этой функции аспр забирает на себя). После ее выполнения в оригинале ЕАХ=400000 и в вершине стека то же значение. Корректировкой я просто подогнал значения.

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

Ремэйк минитутора от SergSh, за что ему отдельное спасибо!
на примере AlfaClock
1. Стоя на ОЕР:004C5444 делал в ОЛЛИ поиск всех call-ов.
2. Ставил New origin here на интересующий меня калл (CALL 00CF0000) у вас могут быть другие адреса, точно вы можете посмотреть, например, тут: 00406B90
3. При этом был установлен бряк ret в VirtualAlloc (Ctrl+G, вводим VirtualAlloc и на первом RET жмем F2) и бряк на доступ к секции кода в AlfaClock.exe (нажимаем Alt+M и перейдя на секцию Address=00401000 Size=000C5000 (806912.) нажимаем F2)
4. Далее Shft+F9, останавливаемся на ret в VirtualAlloc в стеке по ESP+40 нужная нам функция. Записываем её на бумажку. (На самом деле остаточно нажать F4 или F9 находясь на строке 00406B90)
5. Далее Shft+F9 и ещё Shft+F9 и ещё Shft+F9 срабатывает бряк на секции кода в AlfaClock.exe, смотрим call 00CF0000 стал call 00CF31000(приблизительно, у вас адреса будут другими)
6. В IAT ищем нашу библиотеку и вбиваем адрес из ESP+40 (предварительно записанный на бумажке)
7. call 00CF0000 изменяем на jmp на вбитый в IAT адрес (при этом необходимо в ОЛЛИ снять галочку о занопливании инструкций)
8. И "New origin here" на другой call 00CF0000 и т.д.
9. После замены всех call 00CF0000 в ImportREC. Вбиваем ОЕР, IAT вбваем из выскакиваемой мессаги RVA: 000b6000 size 00003000. Далее Get Imports, Show Invalid и обязательно Plugin Tracers c ASProtect 1,22. Затем Cut thunt(s) и привинчиваем к дампу.
10.Всё. Осталось пара косяков но они легко исправляются. Распакованная прога работоспособна на всех системах. Удачи.

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

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

Я делал так:
1. В ОЛЛЕ делал Search for, binary string, FF25, до нужной мне dll.
2. Показать в дампе. Поск по номеру. Если поиск не принёс результатов то смотрю неверные значения AIP
в dll и вбиваю адрес из ESP+40.
3. В данной прге необходимо произвести искустванное разделение dll нулями.
4. После на место Сall 00CF0000 пишем jmp [ наш адресс в IAT].
5. В данной проге есть ещё несколько Call 00f90004. Там Jmp на код в котором уже спёрта часть AIP.
Просто на этапе загрузке проги бряк на ret в VirtualAlloc и когда начнется выделение памяти по 1000 байт смотрим в стек и видим интересующую нас функцию, записывая адрес выделенной помяти и AIP на бумажку.
6. Затем вместо Call 00f90004 вбиваем известный нам JMP IAT
7. Да при востановлении импорта одной dll в IAt нет я над IAT нопил и создавал её искуственно. Там всего 2 или 3 функции.
8. Ещё при восстановлении иморта ранее предложенным способом в ESP+40 будет что вроде 00B????? , так это аспровский аналог GetProcAddress.

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

Просто на этапе загрузке проги бряк на ret в VirtualAlloc и когда начнется выделение памяти по 1000 байт смотрим в стек и видим интересующую нас функцию, записывая адрес выделенной помяти и AIP на бумажку.
[b][/b]
Следует понимать на этапе прохода до OEP......

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

Вот тут происходит генерация API для определенного адреса

/*B9480B*/  MOV     CX, WORD PTR [EBP-14]

/*B9480F*/  MOV     DX, WORD PTR [EBP-18]

/*B94813*/  MOV     EAX, DWORD PTR [EBP-C]

/*B94816*/  CALL    00B93EE4

/*B9481B*/  MOV     DWORD PTR [EBP-4], EAX - Some API

Адресс Call'a откуда происзошел вызов Some API находиться в EBP+0B8. Вот в принципе и все с альфаклоком пишем не большую обработку чтоб в место

/*406EB4*/  CALL    00D60000 Был 

/*406EB4*/  CALL    Some API

и востанавливаем импорт.

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

Bit-hack пишет:
А может кто поможет мне найти место, где виден адрес импортируемой функции
тоже по ссылке не ходил ? =)) там вообще-то дана сигнатура места вызова функции определяющей адрес апи (причём как раз от той версии аспра которая на альфаклоке).

Cigan пишет:
/*406EB4*/ CALL Some API
а я то думал что

 JMP DWORD PTR [addr_api_in_iat] 

;)

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

Мне кажется метод, описанный SergSh [/i] не всегда дает правильные результаты. Например, прога второй раз "падает" в адресе:
00406B23 CALL d_pe_too.004012F4
и далее
004012F4 Call 00f90004 ( у каждого по разному)
Находясь здесь, ставим бряк на выходе из VirtualAlloc и бряк в памяти на доступ к секции кода (как описано выше). Запускаем и прерываемся на Retn (VirtualAlloc).
Смотрим стек, там
ESP+40 > 793B49DF kernel32.GetStartupInfoA
Но на самом деле здесь эмулируется
004012F4 JMP NEAR [DWORD kernel32.GetCommandLineA]
Ее можно увидеть, только когда вручную протрассируешь Call 00f90004.
Кто-нибудь сумел автоматизировать этот процесс?

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

nice пишет:
10.Всё. Осталось пара косяков но они легко исправляются.
Эти косяки не связаны с ошибкой обращения к несуществующим участкам памяти? Как обошли эти проблемы? Созданием (дублированием) этих участков или иначе? Или все только восстановили импорт
и прога заработала.

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

Я делал так:
На этапе прохода к ОЕР смотрел, что ложится в выделенную память. Меня привлекло название библиотеки TreyClock.dll. При повторном проходе я изменил адрес после VirtualAlloc для этого участка на адрес последней секции в exeшнике. Провда немного пришлось повазиться. Но эта запись оказалась у меня в exeшнике. Затем стоя на ОЕР я посмотрел то место куда ссылается протектор при дальнейшей своей распаковке (кажется 4с?????). Там несколько ссылок на память, я просто периориентировал их на свободный участок последней секции exeшника, а там набил то что бало в памяти.
Да действительно при прходе по Call EAX падает где-то на А5 и появляются новые Call 00f90004 просто при повторном проходе я это учёл.
Распаковал. Наг всплывает. Но после нажатия кнопки "Попробовать" просто закрывается. Ошибку не выбивает. Вроде химичит с размером файла, но где надо пропатчить не могу найти. Подскажите пожалуста.

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

SergSh пишет:
Меня привлекло название библиотеки TreyClock.dll.
Я до этого места еще не дошел. С восстановлением импорта вроде разобрался. Трассирую с помощью скрипта по ходу выполнения проги и где она "падает" из-за отсутствия апи-функции, восстанавливаю ее
в таблице импорта.

SergSh пишет:
там несколько ссылок на память, я просто периориентировал их на свободный участок последней секции exeшника, а там набил то что бало в памяти.
Я не понял этой записи. Например, у меня возникает ошибка при обращении к участку памяти по адресу 13С000 (пример). У меня его нет, есть только 130000-138000. Вижу, что в запакованном файле этот участок памяти эмулируется аспром (у меня 138000-13F000). Находясь на ОЕР, я дамплю этого участок (регион) и добавляю его как новую секцию в свой файл. Затем в конце своего файла пишу патч, который создает область 138000-13F000 и переносит данные из новой секции в эту область памяти. Ты это имел ввиду или нет?

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

Посмотри стоя на ОЕР на адрес 4с9620. Там несколькоадресов из памяти (у меня было 13 на 159с80 и рядом). В своём дампе с восстановленным импортом я изменил их на 584000 (конечно для каждого свой), а по адресу 584000 вбил то, что было по адресу 159с80. Там были адреса из проги. А там где был переход на этот же участок памяти я прсто занулил. Там же была ссылка на dll.
Я восстанавливал импорт стоя на ОЕР, а не походу выполнения программы.
А про dll может тебе и не понадобится. Но благодаря этому не упал на call eax №9. Кстати ты прошёл call eax?

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

Здарова мужики!
Руки так и чешутся написать Сорри что не по проге в топике, но вопрос тоже относится как ни странно к АСПРу
Возникла такая трабла - прохожу до ОЕР, но код немного странноват

Этот якобы ОЕР идет сразу после последнего ехсер. на бряке к CODE

0048AFE8   XOR EAX, EAX
0048AFEA   PUSH 0
0048AFEC   CMP DWORD PTR SS:[ESP+8], EAX
0048AFF0   PUSH 1000
0048AFF5   SETE AL
0048AFF8   PUSH EAX
0048AFF9   CALL DWORD PTR DS:[49D130]               ; kernel32.HeapCreate
0048AFFF   TEST EAX, EAX
...
0048B001  PUSH DWORD PTR DS:[4B9B60]
0048B038  CALL DWORD PTR DS:[49D134]               ; kernel32.HeapDestroy
0048B03E  XOR EAX, EAX
0048B040  RETN                                       <---------- return to 00c71290

Ну а с7**** соответственно код аспра.

/*C71290*/  POP ECX
/*C71291*/  TEST EAX, EAX
/*C71293*/  CALL 00CD0000
/*C71298*/  LEA EAX, DWORD PTR DS:[EDI*4+4]
/*C7129F*/  PUSH EAX
/*C712A0*/  PUSH 0C7081E
/*C712A5*/  CALL 00CD0000
.......

Дальше выходит из аспра на 48d07с

/*48D07C*/  PUSH ESI
/*48D07D*/  CALL test.0048C259
/*48D082*/  CALL DWORD PTR DS:[49D118]
/*48D088*/  CMP EAX, -1
/*48D08B*/  MOV DWORD PTR DS:[4B6770], EAX
/*48D090*/  JE SHORT test.0048D0CC
...
/*48D0BA*/  POP ECX
/*48D0BB*/  CALL 00C90000
/*48D0C0*/  ADD DWORD PTR DS:[EBX+6AFF044E], 58068901
/*48D0CA*/  POP ESI
/*48D0CB*/  RETN                            <------- снова в код аспра

Это хваленая VM или подставная ОЕР? Создается впечатление что программа выполняется по кускам, после каждого куска прыгает в аспр, занимается фигнёй, а потом снова на след. прыжок. Удалось найти в аспре функции создания адреса возврата, т.е. после выполнения кода аспра можно найти куда возвращает он управление, может руками править каждый такой RET сразу на код проги? Надо будет попробовать Фигня в том что во течении всего этого процесса прога выполняется, а найти ОЕР не получается :\ У меня вообще проблемы с поиском ОЕР, как определить что это и есть ОЕР, а не подставная лафа или вообще не ОЕР? Допустим первые команды выполняющиеся в секции кода не обязаны быть точкой входа? Хотя слишком я много размышляю, еще до ответа додумаюсь ненароком
Так вот, по дороге встречаются всякие прыжки на переходники аспра, их восстановить можно, а вот что делать с этими RETами? :\ Кстати вопрос по существу - а как можно определить что вообще есть краденые байты? Тоесть они спокойно могут выполнятся в коде аспра и о них даже ничего известно не будет. Млин, уже 4 свои проги распаковал аспр2.12 на макс. защите, а тут лажа какаято :\ Вот.

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

SergSh пишет:
Кстати ты прошёл call eax?
Прохожу 7-й call eax. как-то быстро не получается. Кстати я долго разбирался с адресом [4с9620]. Там действительно проходит 13 обращений.

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

Странно, но у меня в Сall eax были проблемы только на 9 и на А5(там как раз всплывала функция Call 00f90004 и ещё несколько, невидимых с ОЕР)

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

SergSh пишет:
Странно, но у меня в Сall eax были проблемы только на 9 и на А5(там как раз всплывала функция Call 00f90004 и ещё несколько, невидимых с ОЕР)
Мы, наверное, разное имеем ввиду.
Я устал в ручную восстанавливать апи-функции и пытаюсь сейчас написать скрипт. Только почему-то
возникают ошибки там, где их не должно быть. И Олли сразу вылетает. Например, написал простой кусок скрипта, который перебирал значения в области (.data). Где-то в середине возникала ошибка присвоения, типа mov tmp,[add_iat]. Решил проверить и сделал log [add_iat] и то же ошибка. В переменной add_iat перечисляются реальные адреса, в чем можент быть дело?

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

1. Запускаем Ollydbg. Открываем AlfaClock.exe. Доходим до ОЕР аналогично предыдущим версиям Аспра. Делаем поиск всех подпрограмм: Search for-All intermodular call. Поднимаемся вверх и видим много CALL 00CD0000 и один CALL 00F10004. Скажу сразу, что CALL 00F10004 на самом деле является CALL 00CD0000, отработанным один раз. Поэтому наша задача состоит в том, чтобы прервать выполненее программы до первого его срабатывания. Поэтому записывае адрес этой подпрограммы на бумажку. Он у меня 0040130С.
2. Перезапускаем программу. В окне дампа вбиваем "D 0040130С" и жмём Shift+9 до тех пор пока по этому адресу не станет CALL 00CD0000. Теперь проходим ещё 5 исключений по Shift+9 запоминая или записывая адреса ивключений. Идём пока CALL 00CD0000 не станет CALL 00F10004. Запомнили адрес предыдущего исключения и перезапускаем программу. У меня этот адрес был 00В8В4АС. Останавливаемся на этом исключении. И переходим на известное нам ОЕР. Делаем поис всех подпрограмм и видим, что все подпрограммы имеют вид CALL 00CD0000.
3. Вообщем-то программа уже распакована, необходимо только восстановить таблицу импорта и снять дамп. Стоя на ОЕР запускаем скрипт от BiT-H@ckа. Скрипт успешно отработал. Но снимать дамр не спешим. Сначало делаем поис команд в Ollydbg: "Search for-Сommand-CALL 00CD0000". Видим, что скрипт невосстановил две подпрограммы по адресам 00401264 и 00406Е6С. Восстановим их ручками. О востановлении импорта я уже писал. Дампим.
6. Осталось пара косяков, которые будем устранять трассируя наш дамп. Загружаем исправленный дамп в Ollydbg и трассируем его по F8. Дамп упадёт на CALL 004BD5E8, там по адресу 004BD608 команда MOV EAV,[004C7D6C]. Ниже CALL LoadLibraryA, не трудно догадаться, что по адресе 004C7D6C должно быть название dll. Закрываем дамп, запускаем оригинальную программу, доходим до ОЕР, устанавливаем F2 на 004BD608 и запускаем программу на выполнение. Программа выдала НАГ и затем остановилась на 004BD608, смотрим в 004C7D6C лежит 00Е00000, а в нём TrayClock.dll. Копируем TrayClock.dll в наш дамп на адрес 00584000. Вместо MOV EAV,[004C7D6C] пишем MOV EAV,00584000. Сохраняем изменения. Но дамп всё равно не работает. Скорее всего эта уже защита самой программы, а не Аспра. Здесь всё оказалось до смешного просто. Программа вызывает функцию GetFileSize и на оснавании полученного значения в EAX производит дальнейшую распаковку. GetFileSize находится по адресу 004DВFF0. Следовательно по адресу 004DВFF0 вбиваем MOV EAX,0EFC00 и нопим предыдущиеся два пуша. Значение 0EFC00 подсмотрели в оригинальной программе.
6. Запускаем наш дамп всё работает. Спасибо ВСЕМ

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

SergSh [/i]
Молодец, хватило терпения закончить эту прогу. А я, разобравшись с восстановлением импорта, бросил
ее. Появилась новая задача и снова в виде 2-го аспра. Притом в нем все значительней сложнее.
Там есть и спертые байты и похоже VM. И пока я даже не пойму, где лучше дампить. Не хочешь помочь мне определить спертые байты, а то я не уверен, что все их нашел.

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

SergSh
Молодец!
Парни вы не против, если я эту тему переделаю в некий тутор по снятию?


tar4
Создавай новую тему, т.к. виртуальная машина это отдельная песня

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

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

www.webfile.ru/513652. Там самое необходимое, в минимальной конфигурации.

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

Спасибо Друзья! Я был бы очень признателен если бы NICE написал хороший тотоур. Давайте продолжим.
Предлагайте жертву. Хотя Icolover.exe из одного из топиков подходит. Я мельком глянул. VM на лицо. И спёртые байты вроде есть. Предыдущий скрипт не рулит. Но ручная методика работает прекрасно. Так-что имеет смысл перейти на тот топик.

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

tar4
Последнее исключение:
01009B4A 53 PUSH EBX

Выход на VM:
01009D55 E8 16>CALL 01007170

Частичное востановление ОЕР:
011F02A9 55 PUSH EBP
....
011F02DA 8D6C2>LEA EBP,[DWORD SS:EBP-29] // PUSH EBP,ESP
011F02DE 6A FF PUSH -1
011F1C3A 51 PUSH ECX
011F1C5E 50 PUSH EAX
011F1A9E 52 PUSH EDX
011F1ABF 64:A1>MOV EAX,[DWORD FS:0]
011F1AC5 50 PUSH EAX
011F1AC6 64:89>MOV [DWORD FS:0],ESP
011F1ACD 83EC >SUB ESP,58
судя по всему программа сишная
011F1AD0 53 PUSH EBX
011F1AD1 56 PUSH ESI
011F1AD2 57 PUSH EDI
011F1AD3 8965 >MOV [DWORD SS:EBP-18],ESP
011F1AD6 FF15 >CALL [DWORD DS:7832A8] ; kernel32.GetVersion
ну и так далее, пока времени не хватает

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

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

nice пишет:
nice
Спасибо за то, что посмотрел. То, что ты написал, я все это прошел. Но не был уверен, что правильно определил спертые байты. Например, между командами
011F02DE 6A FF PUSH -1
011F1C3A 51 PUSH ECX
мне казалось, что я пропустил что-то.
Но что мне до сих пор непонятно, а далее за kernel32.GetVersion это чей код: проги или аспра. И где лучше дампить, на
011F1ABF 64:A1>MOV EAX,[DWORD FS:0]
а потом дописывать спертые байты?

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

tar4
я бы сдампил тут:
011F02A9 55 PUSH EBP

tar4 пишет:
Но что мне до сих пор непонятно, а далее за kernel32.GetVersion это чей код: проги или аспра
это код аспра, и если ты видел, Стиппер прикрепляет секцию с крадеными байтами прям к дампу и запускает выполнение с неё
Меня другой вопрос мучает, если не привязывать секцию, то как найти где располагалось старое ОЕР?
ведь аспр записал на место краденых команд мусор...

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

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

nice
Не понимаю, зачем за собой тянуть весь мусор аспра между адресами 011F02A9 и 011F1ABF. Разве не проще, дампить например на 011F1ABF, а затем дописать спертые байты и соотвественно поменять точку входа в прогу. Или я что-то упускаю?[b][/b]

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

inferno_mteam
Представь, что сразу на ОЕР программа ХОRит группу байт и ты после этого дампишь
думаю тебе не нужно рассказывать что будет при повторном проходе
так что лучше дампить прямо на ОЕР, зачем создавать себе головняки???

tar4 пишет:
Не понимаю, зачем за собой тянуть весь мусор аспра между адресами 011F02A9 и 011F1ABF.
я не предлагаю тебе тянуть, я сказал, что стриппер так делает

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

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

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