Сейчас на форуме: (+8 невидимых) |
eXeL@B —› Основной форум —› Vmprotect. Хитрая защита от отладки. |
<< . 1 . 2 . 3 . 4 . 5 . |
Посл.ответ | Сообщение |
|
Создано: 24 мая 2017 20:14 · Поправил: Vamit · Личное сообщение · #1 При реверсе одной проги встретил хитрую защиту от отладки: она не позволяет работать проге под дебагером, после F9 терминация, приаттачиться к работающей то же нельзя - сразу терминация. Приложение накрыто последним Vmprotect, все функции защиты также под протектором, основные виртуализованы, остальные обфусцированы, а всего их более 200шт. Терминирует именно защита, а не вмпрот. В TLS сидят 2 каллбака защиты, первый из них есть в листинге. Дебаг работает только до первого каллбака, тут можно снять дамп проги и девиртуализовать вмпрот. А суть задачи такова: прога посылает запрос на сервер, в котором одним из куков является состояние защиты (32 бита), проэмулировать мне его не удалось и сервак не отвечает. Прошу любые идеи как победить, или идентифицировать защиту, она явно не самописная, и прилинкована к проге из какой-то либы. Вот листинг нескольких функций ядра защиты, вытащенных из под Vmprotect: Code:
----- Everything is relative... |
|
Создано: 20 июня 2017 00:40 · Поправил: srm60171 · Личное сообщение · #2 difexacaw, вы усложняете. Мы говорим про конкретную реализацию VMP, там нет такого (в обсуждаемом случае, по крайней мере). Vamit, в начале инициализации ВМ есть PUSH (VM_PIC ^ VM_PIC_ENCODER) вполне возможно, что есть еще копии этого кода. Попробуйте поискать саму константу. Я точно встречал случаи когда начальная ветка инициализации вм дублировалась для того чтобы сделать "уникальный" адрес для call из мутированого кода |
|
Создано: 20 июня 2017 00:52 · Личное сообщение · #3 srm60171 Я про общий случай говорю, иначе вопрос отследить передачу управления смысла не имел бы - процедурное ветвление оставит адрес вызова. Тут видимо иное - не процедурное ветвление. Если бы это был обычный компиляторный код, то в стеке остаётся цепочка процедурных меток(SFC). Но для мусорного кода - мутации, всякие виртуализации стек содержит треш после ветвления. Восстановить откуда было передано управление только по факту получения управления невозможно, без спец средств. ----- vx |
|
Создано: 20 июня 2017 02:30 · Личное сообщение · #4 difexacaw пишет: Яндекс заблочен в Украине, просьба заливать на мировой ресурс | Сообщение посчитали полезным: sendersu |
|
Создано: 20 июня 2017 10:42 · Поправил: Vamit · Личное сообщение · #5 srm60171 пишет: А разве у виртуализированной функи не может быть несколько разных входов в ВМ? Может, но все они будут из защищенных вмпротом фунок. difexacaw пишет: Перед передачей управления контекст может быть намеренно уничтожен, что бы нельзя было узнать откуда произошло ветвление. Может, но не весь, jmp останется. srm60171 пишет: Попробуйте поискать саму константу. Бесполезно, она будет уникальна для данного вызова. difexacaw пишет: Если бы это был обычный компиляторный код, то в стеке остаётся цепочка процедурных меток(SFC). Причем тут стек, мы говорим про jmp, а они в стек не пишутся, внутри вмпрота call практически отсутствует. Немного теории, чтобы не возникало таких вопросов: Любая функция до защиты протом имеет своё уникальное тело по конкретному адресу - адрес функции, прот не может предвидеть все случаи вызова/использования этого адреса в программе, поэтому при любом типе защиты он съедает все тело функции, а в начальный адрес функции записывает jmp на свою реализацию тела. Этот jmp реально может никогда не исполняться, поэтому на него не будет ссылок в дизассемблерах, и он чаще всего интерпретируется ими не как код, а как данные. Но он всегда будет и найдя его мы находим родное место для тела защищенной функции. Вызов из защищенного вмпротом кода другой защищенной функции я называю пакетным вызовом. Существует 2 типа пакетных вызовов обычных функций пользовательского кода (а всего их 6 типов, но это уже вызовы АПИ функций и вызовы функций самого прота через его SDK) для виртуализованного и мутированного кода. 1а. Вызов из виртуализованного кода другой виртуализованной функции выполняется без выхода из вм, здесь выполняется только смена ленты пикода - пакетный адрес (может быть в пределах одной вм или переход в новую вм). Найти адрес вызываемой функции в этом контексте невозможно, для его нахождения необходимо декомпилировать все виртуализованные функи программы и идентифицировать нужную среди них по пакетному адресу, т.к. он уникален и соответствует реальному адресу функции. 1в. Вызов из виртуализованного кода другой мутированной функции выполняется с выходом из вм на переходник и с него на мутированный код или сразу на мутированный код. Реальный адрес вызываемой функции в этой цепочке также отсутствует, но его можно найти как jmp на мутированный код. 2а. Вызов из мутированного кода виртуализованной функции будет зависеть от опций виртуализации. Если функция виртуализована с антидампом, то вызов выполняется на переходник (новый вход в вм) а после него на точку начала виртуализованного тела функции (после блока антидампа). Если виртуализация без антидампа то вызов идет на переходник (новый вход в вм) и с него на виртуализованный код или сразу на виртуализованный код. Нахождение реального адреса функции в любой опции здесь идентично п.1а. 2в. Вызов из мутированного кода мутированной функции выполняется выполняется через переходник или сразу на мутированный код. Поиск реального адреса функции идентичен п.1в. Переходников на конкретную точку входа в мутированную или виртуализованную функцию может быть несколько, скорее всего они принадлежат не телу вызываемой функции, а являются частью вызывающей функции. Если вернуться к предыдущему моему посту, то все 7 неопознанных вызовов я идентифицировал, а адрес 0xEA4A9D является не началом функции, а промежуточный входом в вм, поэтому тело реальной функции идентифицировать по нему невозможно и т.к. у меня девиртуализованы все функи защиты и этой точки в них не обнаружено и по характерным признакам самого восстановленного кода с этой точки можно сказать, что это кусок функции тела самого вмпрота. ----- Everything is relative... | Сообщение посчитали полезным: v00doo |
|
Создано: 20 июня 2017 19:09 · Личное сообщение · #6 |
|
Создано: 20 июня 2017 20:24 · Поправил: gggeorggge · Личное сообщение · #7 |
|
Создано: 20 июня 2017 22:54 · Личное сообщение · #8 difexacaw пишет: Где останется, IA архитектура не обратима. После ветвления невозможно узнать его источник. Бред не пишите. В коде функции останется, а бред только от тебя, всё что сожрано вмпротом возможно восстановить на своем родном месте, если не знаешь структуру прота, то не лезь со своими советами. gggeorggge пишет: А я уж подумал, что все... Да он там во многие функции проги вставлен. Всю защиту я декомпильнул и то что нужно нашел... Можно обойтись без дебага, аттач к работающей проге, снятие нужных данных и раскодировка их. ----- Everything is relative... |
|
Создано: 21 июня 2017 06:12 · Личное сообщение · #9 |
|
Создано: 21 июня 2017 11:29 · Поправил: gggeorggge · Личное сообщение · #10 |
|
Создано: 21 июня 2017 14:00 · Личное сообщение · #11 gggeorggge пишет: Как вы обошли вызов tls при аттаче? Да никак не обходил. Я не знаю всю механику аттача, и выполняется tls при аттаче или нет - мне неизвестно. Есть у меня какая-то Олькина сборка под WinXP со стронгом в kernel mode, которая нормально цепляется ко всем прогам. Посмотрел данные защиты в стат памяти, статус норм - ничего не сработало, что нужно взял и раскодировал. Но исполнять код после аттача уже нельзя, сразу следует RtlExitUserThread... ----- Everything is relative... |
|
Создано: 22 июня 2017 15:49 · Личное сообщение · #12 |
|
Создано: 22 июня 2017 17:33 · Личное сообщение · #13 |
|
Создано: 11 июля 2017 09:18 · Личное сообщение · #14 Запустил в ollydbg эту программу без каких-то дополнительных средств после изучения системы защиты. Отключил tls3 (он вызывается при создании каждого потока) установкой reason в 3 и остановил пару потоков, в которых был антидебаг. А в чем смысл такой мощной защиты от антидебага? Реализован какой-то уникальный алгоритм? |
|
Создано: 11 июля 2017 11:17 · Личное сообщение · #15 |
|
Создано: 11 июля 2017 11:45 · Личное сообщение · #16 |
|
Создано: 11 июля 2017 15:34 · Личное сообщение · #17 gggeorggge пишет: Реализован какой-то уникальный алгоритм? В принципе любой алгоритм взаимодействия сервер-клиент является уникальным (авторизация, сертификаты, трансфер данных, если он реализован не через системные АПИ). А смысл чтобы "грязными руками" не дебажили алгоритмы. Вчера вышла новая версия этой проги, там вообще извращение: сам образ без вмпротовской упаковки, но вмпротовский протект образа включен, так же все интересные функи виртуализованы, импорт в корне отсутствует - очень похоже, что весь его засунули в эту защиту. Теперь дабаг далее первого вмпротовского тлс не идет. ----- Everything is relative... |
|
Создано: 11 июля 2017 17:39 · Личное сообщение · #18 |
|
Создано: 25 июля 2017 08:01 · Поправил: gggeorggge · Личное сообщение · #19 |
|
Создано: 25 июля 2017 09:38 · Личное сообщение · #20 |
|
Создано: 25 июля 2017 13:49 · Личное сообщение · #21 |
|
Создано: 26 июля 2017 16:13 · Поправил: bartolomeo · Личное сообщение · #22 |
|
Создано: 21 ноября 2017 10:28 · Поправил: Bronco · Личное сообщение · #23 перечитал, полезно, феньк Vamit пишет: Теперь дабаг далее первого вмпротовского тлс не идет. фичи все старые, но защита решила хуки апишек по своему обходить, частично на сисколы ушла. из новенького, но вроде это не антитрик, юзают сискол NtProtectVirtualMemory, проверяют_меняют атрибуты своих секций, их пока с релоками 3. + в х64 появился EXCEPTION_SINGLE_STEP // вот соскучились. изменилось црц, меньше 2000 byte не парсят, контрольные суммы вроде привязаны к дельтам для служебных задач, длинно как то всё стало. . ----- Чтобы юзер в нэте не делал,его всё равно жалко.. |
|
Создано: 21 ноября 2017 11:07 · Личное сообщение · #24 |
|
Создано: 21 ноября 2017 17:50 · Поправил: Bronco · Личное сообщение · #25 Bronco пишет: вроде это не антитрик да как бы нет самое оно, подкинули в моём случае NtProtectVirtualMemory юзают 3 раза подряд: Code:
после вызов апи CloseHandle (0xDEADC0DE), после проверок имён эксе типа дбг. сингел_ степ на простом NOP ещё такты стали юзать перед входом_выходом вм ----- Чтобы юзер в нэте не делал,его всё равно жалко.. |
|
Создано: 21 ноября 2017 20:47 · Личное сообщение · #26 Bronco пишет: CloseHandle (0xDEADC0DE) Если 0xDEADC0DE это параметр, то апи вернёт сингл степ If the application is running under a debugger, the function will throw an exception if it receives either a handle value that is not valid or a pseudo-handle value. ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube | Сообщение посчитали полезным: Bronco |
|
Создано: 21 ноября 2017 21:04 · Поправил: Bronco · Личное сообщение · #27 |
|
Создано: 22 ноября 2017 22:07 · Личное сообщение · #28 bartolomeo https://www.metaquotes.net/ru/metatrader5 Качайте и пробуйте. | Сообщение посчитали полезным: bartolomeo |
<< . 1 . 2 . 3 . 4 . 5 . |
eXeL@B —› Основной форум —› Vmprotect. Хитрая защита от отладки. |