Сейчас на форуме: vsv1, NIKOLA, r0lka, johnniewalker (+4 невидимых) |
eXeL@B —› Крэки, обсуждения —› Реверс AsProtect |
Посл.ответ | Сообщение |
|
Создано: 15 ноября 2018 08:34 · Личное сообщение · #1 Доброго времени суток! Решил разобраться с AsProtectом. Начал с версии 1.33. Она первая из ранних версий которая запустилась на моей тачке. Как всегда есть вопросы. понял что аспр создает кучу секций в которые ворует начала Api функций или всех их если апишки небольшие. Нашел секцию aspr.dll размером 33000. Разобрался что и как в ней. Остался один вопрос. Как восстановить call переходники в секцию аспра. Вроде накатал простенький скрипт для x64dbg но восстанавливает он не все и не всегда. Как делал: Сохраняем регистры и флаги Ставим выполнение на переходник и переходим в него Ставим бряк на секцию кода программы. Отпускаем прогу и еще раз переходим в уже новый, перезаписанный call. проходим по F7 чуть дальше и оказываемся в одной из 35 секций. Выделяем определенное количество байт и ищем их. Находим откуда воровано начала и чиним call Восстанавливаем регистры. Ставим выполнение на точку входа в программу Повторяем со всеми. Восстановил бы руками но переходников там 100+ штук. Поэтому пишу скрипт. Пишу чисто для саморазвития. Но мозгов не хватает Скрипт переделаю попозже под другой способ Сам скрипт Code:
Вначале скрипта проход на oep а дальше восстановление переходников. Скриптопис из меня херовый так что не бейте сильно) Только учусь. Тем более скриптовая платформа скудна на x64dbg. Пользуюсь им. Задача не просто распаковать а понять как и что делается в проте. Заранее спасибо. |
|
Создано: 15 ноября 2018 08:55 · Личное сообщение · #2 RoKZaR пишет: Задача не просто распаковать а понять как и что делается в проте Материалы Валентина Некрылова читал? Скрипты Валентина смотрел? Есть RoKZaR пишет: Она первая из ранних версий которая запустилась на моей тачке Виртуалка с Windows XP и будет тебе счастье ) Хороший способ исследовать: - Выбираешь несколько близких версий протектора (в твоём случае 1.3x) - Собираешь из примеров бинарь с маркерами - Защищаешь свой бинарь с разными опциями защиты разными версиями протектора - Распаковываешь полученные сэмплы существующими распаковщиками (например, DecomAS) - Извлекаешь ASProtect.dll - Исследуешь как загрузчик аспра, так и его длл; смотришь оригинальный файл и сравниваешь; смотришь распакованные сэмплы ----- EnJoy! | Сообщение посчитали полезным: hlmadip |
|
Создано: 15 ноября 2018 08:59 · Личное сообщение · #3 |
|
Создано: 15 ноября 2018 09:05 · Личное сообщение · #4 RoKZaR пишет: Если не сложно скиньте пожалуйста. Выделил ссылку в посте: ----- EnJoy! |
|
Создано: 17 мая 2019 10:26 · Поправил: dosprog · Личное сообщение · #5 Тему решил не создавать - задам вопрос в уже существующей. С самим Asprotect'ом напрямую не связанный. После автораспаковки Decomas'ом файл выходит нерабочим. При попытке запуска его система выводит месиджбокс с сообщением "Приложение не было запущено поскольку оно некорректно настроено. Повторная установка сможет решить эту проблему". Хьюшечный PEVerify не находит ошибок в структуре распакованного PE файла. Программа до распаковки была вполне портабельная, никаких MSVC Redistributable не требовала. Собственно вопрос - в каких ещё случаях система выдаёт такое сообщение о "некорректной настроенности"? |
|
Создано: 17 мая 2019 10:47 · Личное сообщение · #6 |
|
Создано: 17 мая 2019 10:57 · Поправил: plutos · Личное сообщение · #7 dosprog пишет: в каких ещё случаях система выдаёт такое сообщение о "некорректной настроенности"? ты будешь смеяться, но у меня была подобная ситуация, когда VMware пожирала всю память и ее просто не хватало. Закрыл пару virtual machines и все с программой стало ОК и куда делась "некорректность настроенности", а до того, хоть головой об стенку. Но это, так, мысли вслух, на всякий пожарный. ----- Give me a HANDLE and I will move the Earth. | Сообщение посчитали полезным: dosprog |
|
Создано: 17 мая 2019 16:25 · Поправил: mak · Личное сообщение · #8 dosprog пишет: Тему решил не создавать - задам вопрос в уже существующей. С самим Asprotect'ом напрямую не связанный. После автораспаковки Decomas'ом файл выходит нерабочим. При попытке запуска его система выводит месиджбокс с сообщением "Приложение не было запущено поскольку оно некорректно настроено. Повторная установка сможет решить эту проблему". Хьюшечный PEVerify не находит ошибок в структуре распакованного PE файла. Программа до распаковки была вполне портабельная, никаких MSVC Redistributable не требовала. Собственно вопрос - в каких ещё случаях система выдаёт такое сообщение о "некорректной настроенности"? Опции распаковки(чистка и оптимизация пе), система распаковки(на хп и 7 обычно ок), криптоучастки, кастом проверки, отсуствтие длл переходника для эмуляции лицензии, отрезана часть кастом секций, битые ресурсы. ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube |
|
Создано: 17 мая 2019 19:04 · Поправил: dosprog · Личное сообщение · #9 difexacaw пишет: Покажите файл. Вот файлы: mak пишет: Опции распаковки Да перепробовал все варианты. Под WinXP. Заметил, что в "директории" описан TLS длиной 18h байтов, в таблице же объектов секция .tls имеет нулевую физическую длину. Перекрывается следующей секцией. |
|
Создано: 17 мая 2019 19:13 · Личное сообщение · #10 |
|
Создано: 17 мая 2019 19:22 · Личное сообщение · #11 |
|
Создано: 17 мая 2019 19:33 · Поправил: Alchemistry · Личное сообщение · #12 dosprog пишет: Идентичен тому, что в исходном файле. Нет. Начато создание контекста активации. Входной параметр: Flags = 0 ProcessorArchitecture = Wow32 CultureFallBacks = ru-RU;ru;en-US;en ManifestPath = C:\ew\PIX_u.EXE AssemblyDirectory = C:\ew\ Application Config File = ----------------- ИНФОРМАЦИЯ: анализируется файл манифеста C:\ew\PIX_u.EXE. ИНФОРМАЦИЯ: удостоверение определения манифеста: Microsoft.Windows.Shell.shell32,processorArchitecture="*",type="win32",version="5.1.0.0" ИНФОРМАЦИЯ: ссылка: Microsoft.Windows.Common-Controls,language="*",processorArchitecture="*",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.0.0" Ошибка: строка 1: синтаксическая ошибка XML. ИНФОРМАЦИЯ: не удалось создать контекст активации. Создание контекста активации завершено. ================= Начато создание контекста активации. Входной параметр: Flags = 0 ProcessorArchitecture = Wow32 CultureFallBacks = ru-RU;ru;en-US;en ManifestPath = C:\ew\PIX.EXE AssemblyDirectory = C:\ew\ Application Config File = ----------------- ИНФОРМАЦИЯ: анализируется файл манифеста C:\ew\PIX.EXE. ИНФОРМАЦИЯ: удостоверение определения манифеста: Microsoft.Windows.Shell.shell32,processorArchitecture="*",type="win32",version="5.1.0.0" ИНФОРМАЦИЯ: ссылка: Microsoft.Windows.Common-Controls,language="*",processorArchitecture="*",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.0.0" ИНФОРМАЦИЯ: выполняется разрешение ссылки Microsoft.Windows.Common-Controls,language="*",processorArchitecture="*",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.0.0". ИНФОРМАЦИЯ: выполняется разрешение ссылки для ProcessorArchitecture WOW64. ИНФОРМАЦИЯ: выполняется разрешение ссылки для культуры ru-RU. ИНФОРМАЦИЯ: выполняется применение политики связывания. ИНФОРМАЦИЯ: не удалось найти политику издателя. ИНФОРМАЦИЯ: не удалось найти перенаправление политики связывания. ИНФОРМАЦИЯ: начинается проверка сборки. ИНФОРМАЦИЯ: не удалось найти сборку в WinSxS. ИНФОРМАЦИЯ: попытка проверки манифеста на C:\Windows\assembly\GAC_32\Microsoft.Windows.Common-Controls\6.0.0.0_ru-RU_6595b64144ccf1df\Microsoft.Windows.Common-Controls.DLL. ИНФОРМАЦИЯ: не удалось найти манифест для культуры ru-RU. ИНФОРМАЦИЯ: проверка сборки завершена. ИНФОРМАЦИЯ: выполняется разрешение ссылки для культуры ru. ИНФОРМАЦИЯ: выполняется применение политики связывания. ИНФОРМАЦИЯ: не удалось найти политику издателя. ИНФОРМАЦИЯ: не удалось найти перенаправление политики связывания. ИНФОРМАЦИЯ: начинается проверка сборки. ИНФОРМАЦИЯ: не удалось найти сборку в WinSxS. ИНФОРМАЦИЯ: попытка проверки манифеста на C:\Windows\assembly\GAC_32\Microsoft.Windows.Common-Controls\6.0.0.0_ru_6595b64144ccf1df\Microsoft.Windows.Common-Controls.DLL. ИНФОРМАЦИЯ: не удалось найти манифест для культуры ru. ИНФОРМАЦИЯ: проверка сборки завершена. ИНФОРМАЦИЯ: выполняется разрешение ссылки для культуры en-US. ИНФОРМАЦИЯ: выполняется применение политики связывания. ИНФОРМАЦИЯ: не удалось найти политику издателя. ИНФОРМАЦИЯ: не удалось найти перенаправление политики связывания. ИНФОРМАЦИЯ: начинается проверка сборки. ИНФОРМАЦИЯ: не удалось найти сборку в WinSxS. ИНФОРМАЦИЯ: попытка проверки манифеста на C:\Windows\assembly\GAC_32\Microsoft.Windows.Common-Controls\6.0.0.0_en-US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.DLL. ИНФОРМАЦИЯ: не удалось найти манифест для культуры en-US. ИНФОРМАЦИЯ: проверка сборки завершена. ИНФОРМАЦИЯ: выполняется разрешение ссылки для культуры en. ИНФОРМАЦИЯ: выполняется применение политики связывания. ИНФОРМАЦИЯ: не удалось найти политику издателя. ИНФОРМАЦИЯ: не удалось найти перенаправление политики связывания. ИНФОРМАЦИЯ: начинается проверка сборки. ИНФОРМАЦИЯ: не удалось найти сборку в WinSxS. ИНФОРМАЦИЯ: попытка проверки манифеста на C:\Windows\assembly\GAC_32\Microsoft.Windows.Common-Controls\6.0.0.0_en_6595b64144ccf1df\Microsoft.Windows.Common-Controls.DLL. ИНФОРМАЦИЯ: не удалось найти манифест для культуры en. ИНФОРМАЦИЯ: проверка сборки завершена. ИНФОРМАЦИЯ: выполняется разрешение ссылки для культуры Neutral. ИНФОРМАЦИЯ: выполняется применение политики связывания. ИНФОРМАЦИЯ: не удалось найти политику издателя. ИНФОРМАЦИЯ: не удалось найти перенаправление политики связывания. ИНФОРМАЦИЯ: начинается проверка сборки. ИНФОРМАЦИЯ: не удалось найти сборку в WinSxS. ИНФОРМАЦИЯ: попытка проверки манифеста на C:\Windows\assembly\GAC_32\Microsoft.Windows.Common-Controls\6.0.0.0__6595b64144ccf1df\Microsoft.Windows.Common-Controls.DLL. ИНФОРМАЦИЯ: не удалось найти манифест для культуры Neutral. ИНФОРМАЦИЯ: проверка сборки завершена. ИНФОРМАЦИЯ: выполняется разрешение ссылки для ProcessorArchitecture x86. ИНФОРМАЦИЯ: выполняется разрешение ссылки для культуры ru-RU. ИНФОРМАЦИЯ: выполняется применение политики связывания. ИНФОРМАЦИЯ: не удалось найти политику издателя. ИНФОРМАЦИЯ: не удалось найти перенаправление политики связывания. ИНФОРМАЦИЯ: начинается проверка сборки. ИНФОРМАЦИЯ: не удалось найти сборку в WinSxS. ИНФОРМАЦИЯ: попытка проверки манифеста на C:\Windows\assembly\GAC_32\Microsoft.Windows.Common-Controls\6.0.0.0_ru-RU_6595b64144ccf1df\Microsoft.Windows.Common-Controls.DLL. ИНФОРМАЦИЯ: не удалось найти манифест для культуры ru-RU. ИНФОРМАЦИЯ: проверка сборки завершена. ИНФОРМАЦИЯ: выполняется разрешение ссылки для культуры ru. ИНФОРМАЦИЯ: выполняется применение политики связывания. ИНФОРМАЦИЯ: не удалось найти политику издателя. ИНФОРМАЦИЯ: не удалось найти перенаправление политики связывания. ИНФОРМАЦИЯ: начинается проверка сборки. ИНФОРМАЦИЯ: не удалось найти сборку в WinSxS. ИНФОРМАЦИЯ: попытка проверки манифеста на C:\Windows\assembly\GAC_32\Microsoft.Windows.Common-Controls\6.0.0.0_ru_6595b64144ccf1df\Microsoft.Windows.Common-Controls.DLL. ИНФОРМАЦИЯ: не удалось найти манифест для культуры ru. ИНФОРМАЦИЯ: проверка сборки завершена. ИНФОРМАЦИЯ: выполняется разрешение ссылки для культуры en-US. ИНФОРМАЦИЯ: выполняется применение политики связывания. ИНФОРМАЦИЯ: не удалось найти политику издателя. ИНФОРМАЦИЯ: не удалось найти перенаправление политики связывания. ИНФОРМАЦИЯ: начинается проверка сборки. ИНФОРМАЦИЯ: не удалось найти сборку в WinSxS. ИНФОРМАЦИЯ: попытка проверки манифеста на C:\Windows\assembly\GAC_32\Microsoft.Windows.Common-Controls\6.0.0.0_en-US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.DLL. ИНФОРМАЦИЯ: не удалось найти манифест для культуры en-US. ИНФОРМАЦИЯ: проверка сборки завершена. ИНФОРМАЦИЯ: выполняется разрешение ссылки для культуры en. ИНФОРМАЦИЯ: выполняется применение политики связывания. ИНФОРМАЦИЯ: не удалось найти политику издателя. ИНФОРМАЦИЯ: не удалось найти перенаправление политики связывания. ИНФОРМАЦИЯ: начинается проверка сборки. ИНФОРМАЦИЯ: не удалось найти сборку в WinSxS. ИНФОРМАЦИЯ: попытка проверки манифеста на C:\Windows\assembly\GAC_32\Microsoft.Windows.Common-Controls\6.0.0.0_en_6595b64144ccf1df\Microsoft.Windows.Common-Controls.DLL. ИНФОРМАЦИЯ: не удалось найти манифест для культуры en. ИНФОРМАЦИЯ: проверка сборки завершена. ИНФОРМАЦИЯ: выполняется разрешение ссылки для культуры Neutral. ИНФОРМАЦИЯ: выполняется применение политики связывания. ИНФОРМАЦИЯ: политика автоматического обслуживания перенаправила версию сборки. ИНФОРМАЦИЯ: удостоверение сборки после применения политики: Microsoft.Windows.Common-Controls,processorArchitecture="x86",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.7601.17514" ИНФОРМАЦИЯ: начинается проверка сборки. ИНФОРМАЦИЯ: попытка проверки манифеста на C:\Windows\WinSxS\manifests\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2.manifest. ИНФОРМАЦИЯ: манифест обнаружен на C:\Windows\WinSxS\manifests\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2.manifest. ИНФОРМАЦИЯ: проверка сборки завершена. ИНФОРМАЦИЯ: выполняется разрешение ссылки Microsoft.Windows.Common-Controls.mui,language="*",processorArchitecture="x86",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.7601.17514". ИНФОРМАЦИЯ: выполняется разрешение ссылки для ProcessorArchitecture WOW64. ИНФОРМАЦИЯ: выполняется разрешение ссылки для культуры ru-RU. ИНФОРМАЦИЯ: выполняется применение политики связывания. ИНФОРМАЦИЯ: не удалось найти политику издателя. ИНФОРМАЦИЯ: не удалось найти перенаправление политики связывания. ИНФОРМАЦИЯ: начинается проверка сборки. ИНФОРМАЦИЯ: не удалось найти сборку в WinSxS. ИНФОРМАЦИЯ: попытка проверки манифеста на C:\Windows\assembly\GAC_32\Microsoft.Windows.Common-Controls.mui\6.0.7601.17514_ru-RU_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL. ИНФОРМАЦИЯ: не удалось найти манифест для культуры ru-RU. ИНФОРМАЦИЯ: проверка сборки завершена. ИНФОРМАЦИЯ: выполняется разрешение ссылки для культуры ru. ИНФОРМАЦИЯ: выполняется применение политики связывания. ИНФОРМАЦИЯ: не удалось найти политику издателя. ИНФОРМАЦИЯ: не удалось найти перенаправление политики связывания. ИНФОРМАЦИЯ: начинается проверка сборки. ИНФОРМАЦИЯ: не удалось найти сборку в WinSxS. ИНФОРМАЦИЯ: попытка проверки манифеста на C:\Windows\assembly\GAC_32\Microsoft.Windows.Common-Controls.mui\6.0.7601.17514_ru_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL. ИНФОРМАЦИЯ: не удалось найти манифест для культуры ru. ИНФОРМАЦИЯ: проверка сборки завершена. ИНФОРМАЦИЯ: выполняется разрешение ссылки для культуры en-US. ИНФОРМАЦИЯ: выполняется применение политики связывания. ИНФОРМАЦИЯ: не удалось найти политику издателя. ИНФОРМАЦИЯ: не удалось найти перенаправление пол | Сообщение посчитали полезным: dosprog |
|
Создано: 17 мая 2019 19:43 · Личное сообщение · #13 |
|
Создано: 17 мая 2019 20:16 · Личное сообщение · #14 Sxstrace говорит что в памяти это не так. Ошибки SideBySide профилируются sxstrace (https://blogs.msdn.microsoft.com/junfeng/2006/04/14/diagnosing-sidebyside-failures/). Если хочешь можешь конечно копаться в этом, выяснить что конкретно и почему и как это работает вообще с аспром наверху, кто виноват камас, аспр итд, лично меня эта задача не привлекает. Это для любителей шашечек, а мы едем или надо шашечки? Ща подойдет клекр с моторами и визорами расскажет про шашечки. Берешь нормальный манифест перешиваешь его вместо этого гавна и получаешь рабочую программу с поддержкой тем. | Сообщение посчитали полезным: difexacaw |
|
Создано: 17 мая 2019 20:18 · Поправил: difexacaw · Личное сообщение · #15 dosprog CreateProcess() -> CSRSS -> STATUS_SXS_CANT_GEN_ACTCTX -> ERROR_SXS_CANT_GEN_ACTCTX. Да, косяк с манифестом. Это может быть из за слоя протектора, тк csr читает из памяти процесса(те есчо до запуска потоков). ps: посылать дисковые IOCTL из динамических буферов не есть хорошо, хоть там и запрос на профайл, но если это авер обнаружит, то забракует апп. ----- vx | Сообщение посчитали полезным: Alchemistry, dosprog |
|
Создано: 17 мая 2019 20:25 · Личное сообщение · #16 |
|
Создано: 17 мая 2019 20:29 · Личное сообщение · #17 |
|
Создано: 17 мая 2019 21:04 · Личное сообщение · #18 Что-то ерунда получается: ================= Начато создание контекста активации. Входной параметр: Flags = 0 ProcessorArchitecture = Wow32 CultureFallBacks = ru-RU;ru;en-US;en ManifestPath = D:\2\PIX_u.EXE AssemblyDirectory = D:\2\ Application Config File = ----------------- ИНФОРМАЦИЯ: анализируется файл манифеста D:\2\PIX_u.EXE. ИНФОРМАЦИЯ: удостоверение определения манифеста: (null) ИНФОРМАЦИЯ: ссылка: Microsoft.Windows.Common-Controls,language="*",processorArchitecture="*",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.0.0" Ошибка: строка 21: синтаксическая ошибка XML. ИНФОРМАЦИЯ: не удалось создать контекст активации. Создание контекста активации завершено. --------------------------------------------------------------- |
|
Создано: 17 мая 2019 21:10 · Личное сообщение · #19 |
|
Создано: 17 мая 2019 23:18 · Личное сообщение · #20 |
|
Создано: 11 июня 2019 21:56 · Личное сообщение · #21 |
|
Создано: 11 июня 2019 22:34 · Личное сообщение · #22 |
|
Создано: 13 июня 2019 00:51 · Поправил: difexacaw · Личное сообщение · #23 |
|
Создано: 08 июля 2019 18:16 · Поправил: Dr0p · Личное сообщение · #24 Форум глючит, не открываются разделы, поэтому прошу тут. У меня проблема следующая. Обычно все протекторы нормально и стабильно эмулятся в юм, я использую гибридную эмуляцию(dye). На одном из апп им накрытым возникает нестабильность, я потратил где то месяц на отладку - всё бестолку. Падает внутрях XED или из него возвращаются ошибки. Причём очень странным образом - если сохранить дизасм структуру(она локальна на стеке потока, переменная) и при возвращении ошибки повторно с этой структурой вызвать ксед, то ошибки нет. Чудеса просто, учитывая что память при этом не изменяется. Я пересобрал сам ксед на последнюю версию, при этом без импорта(используется только 6 простейших функций работы с памятью). Это ничего не дало, всё тот же анстаб. Я попытался обернуть ксед в exclusive-RWL блокировку, тоже бестолку. Далее я попробовал снять трассу, так как сам ксед дизасмить кседом не имеет смысла, то использовал тормозную машинную(TF). Не понятным образом трасса рвётся на обычном потоке инструкций(не передающих управление) и управление улетает хз куда. Между потоками при этом явного обмена нет - они контексты друг друга не трогают, контексты изолированы. На днях я закончил инжект(что бы крутить потомки), аналогичного типа анстаб возникает на примере крякми(Patrick", axprotect), вот только с кседом всё впорядке в этом случае, а анстаб в системном загрузчике. Вот сам инжектор(может кому нужно), загрузка сразу после загрузки kernel32/kernelbase, те до запуска любого юзер кода(dll, tls). Отлажено, работает стабильно, ну кроме этой проблемы, но она врядле с самим инжектом связана. Когда загрузчик открывает файл для проецирования, возникает ошибка STATUS_SHARING_VIOLATION. При каждом запуске и именно на либе из крякми. Если после возврата из сервиса ошибки под отладчиком его перезапустить, то ошибки нет как и в случае выше, память без изменений. Фишка в том, что потоки визора между собой никак не синхронизируются, так как никакие общие ресурсы не используют, они друг от друга крутятся независимо. Одно событие лишь синхронно - выделение поточного блока(tls) при запуске нового треда. Два анстаба и в двух случаях память без изменений, а перезапуск работает без ошибки. Как такое может быть я хз, у меня уже варианты поиска нестабильности почти исчерпаны. Может какая то фишка есть в ядре или может в планировщике, или может какой то кэш процессорный ? Как вообще искать откуда идёт нестабильность в этом случае ? Чуть не забыл, такое поведение на варе. Может ли она быть причиной ? de89_08.07.2019_EXELAB.rU.tgz - Ijr.7z |
|
Создано: 13 июля 2019 05:06 · Личное сообщение · #25 |
|
Создано: 13 июля 2019 13:23 · Поправил: mak · Личное сообщение · #26 Patrick интересный крякми, внутри есть солюшн, ссылки зеркальные .. Dr0p пишет: Далее я попробовал снять трассу, так как сам ксед дизасмить кседом не имеет смысла, то использовал тормозную машинную(TF). Не понятным образом трасса рвётся на обычном потоке инструкций(не передающих управление) и управление улетает хз куда. Между потоками при этом явного обмена нет - они контексты друг друга не трогают, контексты изолированы. Может дело в оперативке или ресурсах твоей ВМки?! У меня были подобные ошибки когда было мало ресурсов, может сам файл реально открыт в другом процессе. Code:
Где у тебя проект лежит в VMWare, не в расшаренной папке? ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube |
|
Создано: 13 июля 2019 22:15 · Личное сообщение · #27 mak Ошибка возникает независимо от пути(расположения) папки. Я заметил что есть некоторая зависимость от запущенного км-дбг, у меня это сиська, через него я смотрю дебаг вывод. Если он запущен, то ошибки возникают многократно чаще. Я пробовал выгрузить отладчик и снять все возможные моды ядра(rku/gmer), всё равно ошибка возникает, но менее часто. При запуске копии апп(когда предыдущая работает) - ошибка возникает в 100% запусков. При этом два процесса и по одному потоку. Ошибка возникает в нтлдр при попытке резолвить импорт, его либу антидебаг.длл При прямом запуске ошибка не возникает. Точнее врядле возникает, иначе загрузчик выводит сообщение про ошибку загрузки. По этой причине я не смотрел открывает ли апп файл, судя по всему он это делает, но при прямом запуске проблемы нет. Я по максимому удалил всё из визора, даже адресный транслятор(теперь для обработки индирект ветвлений заменяется опкод на push [EA]). Всё равно ошибка. Можно посмотреть открывается ли файл не из визора, а просто захватить сервисный вызов. Но врядле это что то даст - так или иначе поведение апп отличается, при прямом запуске ошибки нет. Сам этот патрик" накрыт судя по тектовым строкам неким приватным axprotect. Я не нашёл как его получить. В общем разница между прямым запуском апп и под дий - относительное время. Он снимает тайминг через все возможные апи. Но это не обьясняет ошибку, счётчики можно пофиксить(что бы контролировать GetTickCount() нужен адресный декодер). Я не помню точно, но какой то билд работал, но при этом не было запуска нэйтива. Короче я не понимаю как такое может быть. Есчо есть нюанс - патрик работает только на XP, я не смотрел почему, но на старших версиях он не заводится, иначе можно было бы посмотреть возникает там ошибка или нет. ----- vx |
|
Создано: 18 июля 2019 20:01 · Личное сообщение · #28 По патрику я с проблемой разобрался, это специфический баг апп. Впрочем такой не один с ним, пришлось 4-ре либы ребазить(указать базу загрузки), в противном случае апп валится с ошибками, так как база - fixed. Лень перезаливать картинки С аспр я пока не разбирался. Откопал есчо два семпла, какой то тулз для захвата видео - faststone", после снятия лога я тупо передал управление на нужный адрес и оно работает теперь, это вообще не защита. Смотрел есчо эмулятор железок - realpicsimulator". Судя по die оно накрыто армой. Но почему то раньше она так себя не вела, мб это вмп, весьма похоже(его морф). С этим семплом не то что проблема, он по системной части сложный. Два процесса друг друга дебажут и манипулируют контекстами. Тупо на EP: jmp $ и из другого процесса getctx/cmp/setctx. ----- vx |
|
Создано: 18 июля 2019 21:17 · Личное сообщение · #29 difexacaw пишет: Два процесса друг друга дебажут и манипулируют контекстами. Тупо на EP: jmp $ и из другого процесса getctx/cmp/setctx. Это точно армадилла. Вроде DebugBlocker называется опция защиты. Возможно, там и наномиты прикручены ----- Research For Food | Сообщение посчитали полезным: difexacaw |
|
Создано: 19 июля 2019 19:20 · Личное сообщение · #30 daFix Блокировка отладчика в таком случае реализуется подключением второго как клон процесса. Так как отладочный порт один, то нельзя прицепить олли, а если это сделать принудительно(отключить отладчик), то процесс перестанет получать дебаг события. Но это никак не связано с обработкой контекстов, так что это не проблема. Вся защита рассчитана на запуск под отладчиком, фишка в том, что я использую отладчик только что бы смотреть память, это можно сделать иначе Проблема с аспром^. ----- vx |
eXeL@B —› Крэки, обсуждения —› Реверс AsProtect |