Здравствуйте.
Взялся я за очередной крякми (прилагается), который судя по результатам exeinfo и по списку секций был накрыт ASPack. Казалось бы, распаковывается просто и безболезненно, но как-то не вышло.
Стандартная процедура:
1. Открываю в x86dbg
2. Нахожу OEP
3. Делаю дамп сциллой
4. Восстатавливаю таблицу импорта сциллой
Но не работает. Вроде как проблема с базовым адресом, но я не смог разобраться откуда она растет.
Думал что делаю что-то не так, проверил на других exe накрытых ASPack - распаковываются без проблем.
Что это? Какая-то дополнительная защита? Баг сциллы? Кривые руки?

ae09_02.04.2018_EXELAB.rU.tgz - registration.exe

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

для сверки OEP: 004016BB

>> Почему так происходит? ASLR?
13E: 40 -> 00

>> Можно поподробнее?
Запускаем хекс-редактор, открываем то что распаковали, идем по указанному выше смещению патчим - profit.

... не IMAGE_OPTIONAL_HEADER.Win32VersionValue
нет, не оно.

А мне кажется, что оно. В любом случае, я бы хотел понять почему так происходит. header.PNG
Переубеждать не будем. Действительно, не зачем обнулять флаг "can be relocated at load time" - главное, что кажется, а "кажется" - это неоспоримый аргумент!, что это Win32VersionValue.
... казалось, что уже ничто не может спасти отважных моряков ! Оказалось - не казалось! ....

e_lfanew (F0) + Signature (4) + IMAGE_FILE_HEADER (14) + DllCharacteristics offset (47) = 14E
У нас разные файлы - из-за оптимизации в моем случае e_lfanew = E0. В не оптимизированном e_lfanew = F0.

-----
Don_t hate the cracker - hate the code.

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

mysterio пишет:
для сверки OEP: 004016BB
RVA тот же - 16BB, но в отладчике у меня другой адрес, 012E16BB. Хотя CFF explorer показывает именно 004016BB, если преобразовать RVA в VA. Почему так происходит? ASLR?

Добавлено спустя 7 минут
mysterio пишет:
>> Почему так происходит? ASLR?
13F: 40 -> 00
Можно поподробнее?

Добавлено спустя 57 минут
mysterio пишет:
>> Можно поподробнее?
Запускаем хекс-редактор, открываем то что распаковали, идем по указанному выше смещению патчим - profit.
Разве это не IMAGE_OPTIONAL_HEADER.Win32VersionValue?

Добавлено спустя 1 час 14 минут
А мне кажется, что оно.
В любом случае, я бы хотел понять почему так происходит.

fa6c_02.04.2018_EXELAB.rU.tgz - header.PNG

Добавлено спустя 2 часа 19 минут
mysterio пишет:
А мне кажется, что оно. В любом случае, я бы хотел понять почему так происходит. header.PNG
Переубеждать не будем. Действительно, не зачем обнулять флаг "can be relocated at load time" - главное, что кажется, а "кажется" - это неоспоримый аргумент!, что это Win32VersionValue.
... казалось, что уже ничто не может спасти отважных моряков ! Оказалось - не казалось! ....
e_lfanew (F0) + Signature (4) + IMAGE_FILE_HEADER (14) + DllCharacteristics offset (47) = 14E
Что никак не 13F и не 13E.
Однако, спасибо, исправил. Можно было просто указать на флаг. Получается, ASLR.
Но почему так вышло? Сцилла где-то ступила, или у нее всегда один набор флагов на все случаи жизни? И почему оно работало до этого (до распаковки)?

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

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

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

Да, я это уже понял.
Однако, я решил что ASPack сам обрабатывает релоки запакованного PE при распаковке, а .reloc запакованного файла содержит таблицу релоков для незапакованной части кода (те самого распаковщика). Я прав?

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

Да.

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

Uval

Ваша ошибка на п.2. Что вы понимаете под OEP" ?

Есть криптор - который слит воедино с приложением, в динамике не отличим от запуска апп. В простых случаях анпак очевиден - формируется образ в памяти, но это лишь редкие и самые примитивные варианты. Вы смотрите видеоуроки", авторы которых сами не понимают суть, они лишь вводят в заблуждение. Потом и появляются такие вопросы.

-----
vx

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

проблемы в том что люди совсем не связанные с программированием насмотрятся и начитаются туторов где крутые ньюкрекеры ломают мега защиты упакованные всякими упх йодами солодовниками и обламываются потому что не знают как оно работает для этого есть автораспаковщики + когда дойдете до земиды нигмы пепы и дерматолога то интерес к крекми отпадет) путь осилит идущий...

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

difexacaw пишет:
Что вы понимаете под OEP"
Точку входа в само приложение, какой бы она была не будь там упаковщика (точку, в которую переходить упаковщик после распаковки).
difexacaw пишет:
Есть криптор - который слит воедино с приложением, в динамике не отличим от запуска апп.
По моему, это все же упаковщик, так как никакой защиты он не добавляет.
difexacaw пишет:
Вы смотрите видеоуроки", авторы которых сами не понимают суть, они лишь вводят в заблуждение.
Каюсь, смотрю. Раскурить алгоритм ASPack - благое дело, и я им займусь позже, но сейчас мне нужно было просто получить распакованный образ.

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

Uval пишет:
но сейчас мне нужно было просто получить распакованный образ.

--> Link <--

-----
http://ntinfo.biz

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