Русский / Russian English / Английский

Сейчас на форуме: _MBK_ (+2 невидимых)
 · Начало · Статистика · Регистрация · Поиск · ПРАВИЛА ФОРУМА · Язык · RSS ·

 eXeL@B —› Основной форум —› Vmprotect. Хитрая защита от отладки.
<< . 1 . 2 . 3 . 4 . 5 .
Посл.ответ Сообщение


Ранг: 331.1 (мудрец)
Статус: Участник

Создано: 24 мая 2017 20:14 · Поправил: Vamit New!
Цитата · Личное сообщение · #1

При реверсе одной проги встретил хитрую защиту от отладки: она не позволяет работать проге под дебагером, после F9 терминация, приаттачиться к работающей то же нельзя - сразу терминация. Приложение накрыто последним Vmprotect, все функции защиты также под протектором, основные виртуализованы, остальные обфусцированы, а всего их более 200шт. Терминирует именно защита, а не вмпрот. В TLS сидят 2 каллбака защиты, первый из них есть в листинге. Дебаг работает только до первого каллбака, тут можно снять дамп проги и девиртуализовать вмпрот. А суть задачи такова: прога посылает запрос на сервер, в котором одним из куков является состояние защиты (32 бита), проэмулировать мне его не удалось и сервак не отвечает.
Прошу любые идеи как победить, или идентифицировать защиту, она явно не самописная, и прилинкована к проге из какой-то либы.
Вот листинг нескольких функций ядра защиты, вытащенных из под Vmprotect:
Code:
  1. .text:004894F0 sub_4894F0      proc near
  2. .text:004894F0                 dec     esp
  3. .text:004894F1                 mov     edx, ecx
  4. .text:004894F3                 mov     eax, 0Ah
  5. .text:004894F8                 syscall
  6. .text:004894FA                 retn
  7. .text:004894FA sub_4894F0      endp
  8.  
  9. .text:004894FB sub_4894FB      proc near
  10. .text:004894FB arg_0           = dword ptr  4
  11. .text:004894FB
  12. .text:004894FB                 push    0
  13. .text:004894FD                 push    4
  14. .text:004894FF                 push    [esp+8+arg_0]
  15. .text:00489503                 push    7
  16. .text:00489505                 push    0FFFFFFFFh
  17. .text:00489507                 mov     eax, 9Ah
  18. .text:0048950C                 push    0
  19. .text:0048950E                 call    sub_489522
  20. .text:00489513                 add     esp, 18h
  21. .text:00489516                 retn
  22. .text:00489516 sub_4894FB      endp
  23.  
  24. .text:00489517 sub_489517      proc near
  25. .text:00489517                 dec     esp
  26. .text:00489518                 mov     edx, ecx
  27. .text:0048951A                 mov     eax, 16h
  28. .text:0048951F                 syscall
  29. .text:00489521                 retn
  30. .text:00489521 sub_489517      endp
  31.  
  32. .text:00489522 sub_489522      proc near
  33. .text:00489522                 mov     edx, esp
  34. .text:00489524                 sysenter
  35. .text:00489526                 retn
  36. .text:00489526 sub_489522      endp
  37.  
  38. .text:00489527 sub_489527      proc near
  39. .text:00489527                 push    0
  40. .text:00489529                 push    0
  41. .text:0048952B                 push    11h
  42. .text:0048952D                 push    0FFFFFFFEh
  43. .text:0048952F                 push    0
  44. .text:00489531                 mov     eax, 0E5h
  45. .text:00489536                 call    sub_489522
  46. .text:0048953B                 add     esp, 14h
  47. .text:0048953E                 retn
  48. .text:0048953E sub_489527      endp
  49.  
  50. .text:0048953F sub_48953F      proc near
  51. .text:0048953F                 mov     eax, offset sub_489517
  52. .text:00489544                 cmp     dword ptr [eax], 0B8D18B4Ch
  53. .text:0048954A                 jnz     short locret_489587
  54. .text:0048954C                 add     eax, 4
  55. .text:0048954F                 cmp     dword ptr [eax], 16h
  56. .text:00489552                 jnz     short locret_489587
  57. .text:00489554                 mov     eax, offset sub_4894F0
  58. .text:00489559                 cmp     dword ptr [eax], 0B8D18B4Ch
  59. .text:0048955F                 jnz     short locret_489587
  60. .text:00489561                 add     eax, 4
  61. .text:00489564                 cmp     dword ptr [eax], 0Ah
  62. .text:00489567                 jnz     short locret_489587
  63. .text:00489569                 mov     eax, offset sub_489522
  64. .text:0048956E                 cmp     dword ptr [eax], 340FD48Bh
  65. .text:00489574                 jnz     short locret_489587
  66. .text:00489576                 mov     eax, offset sub_489595
  67. .text:0048957B                 cmp     dword ptr [eax], 99C32DCDh
  68. .text:00489581                 jnz     short locret_489587
  69. .text:00489583                 mov     ax, 0
  70. .text:00489587 locret_489587:
  71. .text:00489587                 retn
  72. .text:00489587 sub_48953F      endp
  73.  
  74. .text:00489595 sub_489595      proc near
  75. .text:00489595                 int     2Dh
  76. .text:00489597                 retn
  77. .text:00489597 sub_489595      endp
  78.  
  79. .text:0048A845 sub_48A845      proc near
  80. .text:0048A845 arg_4           = byte ptr  8
  81. .text:0048A845
  82. .text:0048A845                 cmp     dword_C45424, 0
  83. .text:0048A84C                 jnz     short loc_48A854
  84. .text:0048A84E loc_48A84E:
  85. .text:0048A84E                 mov     edx, esp
  86. .text:0048A850 loc_48A850:
  87. .text:0048A850                 sysenter
  88. .text:0048A852                 jmp     short locret_48A85A
  89. .text:0048A854 loc_48A854:
  90. .text:0048A854                 lea     edx, [esp+arg_4]
  91. .text:0048A858                 int     2Eh
  92. .text:0048A85A locret_48A85A:
  93. .text:0048A85A                 retn
  94. .text:0048A85A sub_48A845      endp
  95.  
  96. .text:0048A877 sub_48A877      proc near
  97. .text:0048A877                 mov     eax, offset loc_48A850
  98. .text:0048A87C                 cmp     word ptr [eax], 340Fh
  99. .text:0048A881                 jnz     short locret_48A89E
  100. .text:0048A883                 mov     eax, offset loc_48A854
  101. .text:0048A888                 cmp     dword ptr [eax], 824548Dh
  102. .text:0048A88E                 jnz     short locret_48A89E
  103. .text:0048A890                 add     eax, 4
  104. .text:0048A893                 cmp     word ptr [eax], 2ECDh
  105. .text:0048A898                 jnz     short locret_48A89E
  106. .text:0048A89A                 mov     ax, 0
  107. .text:0048A89E locret_48A89E:
  108. .text:0048A89E                 retn
  109. .text:0048A89E sub_48A877      endp
  110.  
  111.  
  112. .text:0062C6F0 TlsCallback_1   proc near
  113. .text:0062C6F0 Reason          = dword ptr  0Ch
  114. .text:0062C6F0
  115. .text:0062C6F0                 push    ebp
  116. .text:0062C6F1                 mov     ebp, esp
  117. .text:0062C6F3                 and     esp, 0FFFFFFF8h
  118. .text:0062C6F6                 cmp     [ebp+Reason], 1
  119. .text:0062C6FA                 push    ebx
  120. .text:0062C6FB                 push    esi
  121. .text:0062C6FC                 push    edi
  122. .text:0062C6FD                 jz      short loc_62C708
  123. .text:0062C6FF                 pop     edi
  124. .text:0062C700                 pop     esi
  125. .text:0062C701                 pop     ebx
  126. .text:0062C702                 mov     esp, ebp
  127. .text:0062C704                 pop     ebp
  128. .text:0062C705                 retn    0Ch
  129. .text:0062C708 loc_62C708:
  130. .text:0062C708                 push    offset TlsCallback_2
  131. .text:0062C70D                 call    ?????                  ;packet call
  132. .text:0062C712                 add     esp, 4
  133. .text:0062C715                 test    eax, eax
  134. .text:0062C717                 jnz     short loc_62C71E
  135. .text:0062C719                 call    ?????                  ;packet call
  136. .text:0062C71E loc_62C71E:
  137. .text:0062C71E                 push    ebx
  138. .text:0062C71F                 xor     eax, eax
  139. .text:0062C721                 lea     edi, [ebp+4]
  140. .text:0062C724                 cdq
  141. .text:0062C725                 add     edi, 8
  142. .text:0062C728                 mov     ecx, 100h
  143. .text:0062C72D                 rep stosd
  144. .text:0062C72F                 mov     edi, dword_C93D70
  145. .text:0062C735                 mov     ecx, edi
  146. .text:0062C737                 mov     ebx, dword_C93D74
  147. .text:0062C73D                 mov     esi, dword_C93D78
  148. .text:0062C743                 mov     edx, dword_C93D7C
  149. .text:0062C749                 mov     dword_C93D74, edx
  150. .text:0062C74F                 mov     eax, ebx
  151. .text:0062C751                 shld    eax, ecx, 17h
  152. .text:0062C755                 shl     ecx, 17h
  153. .text:0062C758                 xor     edi, ecx
  154. .text:0062C75A                 xor     ebx, eax
  155. .text:0062C75C                 mov     dword_C93D70, esi
  156. .text:0062C762                 mov     eax, esi
  157. .text:0062C764                 mov     ecx, edx
  158. .text:0062C766                 shrd    eax, ecx, 9
  159. .text:0062C76A                 shr     ecx, 9
  160. .text:0062C76D                 xor     ecx, ebx
  161. .text:0062C76F                 xor     eax, edi
  162. .text:0062C771                 shrd    eax, ecx, 11h
  163. .text:0062C775                 shr     ecx, 11h
  164. .text:0062C778                 xor     eax, esi
  165. .text:0062C77A                 push    0
  166. .text:0062C77C                 xor     eax, edi
  167. .text:0062C77E                 xor     ecx, edx
  168. .text:0062C780                 xor     ecx, ebx
  169. .text:0062C782                 sub     edx, edx
  170. .text:0062C784                 mov     dword_C93D78, eax
  171. .text:0062C789                 mov     dword_C93D7C, ecx
  172. .text:0062C78F                 add     eax, esi
  173. .text:0062C791                 mov     ecx, 0FFFh
  174. .text:0062C796                 div     ecx
  175. .text:0062C798                 mov     dword ptr [edx+1], 18BBB819h
  176. .text:0062C79F                 mov     ecx, offset unk_C93CB0
  177. .text:0062C7A4                 call    ?????                  ;packet call (constructor)
  178. .text:0062C7A9                 pop     edi
  179. .text:0062C7AA                 pop     esi
  180. .text:0062C7AB                 pop     ebx
  181. .text:0062C7AC                 mov     esp, ebp
  182. .text:0062C7AE                 pop     ebp
  183. .text:0062C7AF                 retn    0Ch
  184. .text:0062C7AF TlsCallback_1   endp




Ранг: 12.2 (новичок)
Статус: Участник

Создано: 20 июня 2017 00:40 · Поправил: srm60171 New!
Цитата · Личное сообщение · #2

difexacaw, вы усложняете. Мы говорим про конкретную реализацию VMP, там нет такого (в обсуждаемом случае, по крайней мере).

Vamit, в начале инициализации ВМ есть PUSH (VM_PIC ^ VM_PIC_ENCODER)
вполне возможно, что есть еще копии этого кода. Попробуйте поискать саму константу.

Я точно встречал случаи когда начальная ветка инициализации вм дублировалась для того чтобы сделать "уникальный" адрес для call из мутированого кода




Ранг: 331.5 (мудрец)
Статус: Участник

Создано: 20 июня 2017 00:52 New!
Цитата · Личное сообщение · #3

srm60171

Я про общий случай говорю, иначе вопрос отследить передачу управления смысла не имел бы - процедурное ветвление оставит адрес вызова. Тут видимо иное - не процедурное ветвление. Если бы это был обычный компиляторный код, то в стеке остаётся цепочка процедурных меток(SFC). Но для мусорного кода - мутации, всякие виртуализации стек содержит треш после ветвления. Восстановить откуда было передано управление только по факту получения управления невозможно, без спец средств.




Ранг: 62.3 (постоянный)
Статус: Участник

Создано: 20 июня 2017 02:30 New!
Цитата · Личное сообщение · #4

difexacaw пишет:
Яндекс заблочен в Украине, просьба заливать на мировой ресурс

--> Link <--

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



Ранг: 331.1 (мудрец)
Статус: Участник

Создано: 20 июня 2017 10:42 · Поправил: Vamit New!
Цитата · Личное сообщение · #5

srm60171 пишет:
А разве у виртуализированной функи не может быть несколько разных входов в ВМ?

Может, но все они будут из защищенных вмпротом фунок.
difexacaw пишет:
Перед передачей управления контекст может быть намеренно уничтожен, что бы нельзя было узнать откуда произошло ветвление.

Может, но не весь, jmp останется.
srm60171 пишет:
Попробуйте поискать саму константу.

Бесполезно, она будет уникальна для данного вызова.
difexacaw пишет:
Если бы это был обычный компиляторный код, то в стеке остаётся цепочка процедурных меток(SFC).

Причем тут стек, мы говорим про jmp, а они в стек не пишутся, внутри вмпрота call практически отсутствует.

Немного теории, чтобы не возникало таких вопросов:
Любая функция до защиты протом имеет своё уникальное тело по конкретному адресу - адрес функции, прот не может предвидеть все случаи вызова/использования этого адреса в программе, поэтому при любом типе защиты он съедает все тело функции, а в начальный адрес функции записывает jmp на свою реализацию тела. Этот jmp реально может никогда не исполняться, поэтому на него не будет ссылок в дизассемблерах, и он чаще всего интерпретируется ими не как код, а как данные. Но он всегда будет и найдя его мы находим родное место для тела защищенной функции.

Вызов из защищенного вмпротом кода другой защищенной функции я называю пакетным вызовом.
Существует 2 типа пакетных вызовов обычных функций пользовательского кода (а всего их 6 типов, но это уже вызовы АПИ функций и вызовы функций самого прота через его SDK) для виртуализованного и мутированного кода.
1а. Вызов из виртуализованного кода другой виртуализованной функции выполняется без выхода из вм, здесь выполняется только смена ленты пикода - пакетный адрес (может быть в пределах одной вм или переход в новую вм).
Найти адрес вызываемой функции в этом контексте невозможно, для его нахождения необходимо декомпилировать все виртуализованные функи программы и идентифицировать нужную среди них по пакетному адресу, т.к. он уникален и соответствует реальному адресу функции.
1в. Вызов из виртуализованного кода другой мутированной функции выполняется с выходом из вм на переходник и с него на мутированный код или сразу на мутированный код. Реальный адрес вызываемой функции в этой цепочке также отсутствует, но его можно найти как jmp на мутированный код.
2а. Вызов из мутированного кода виртуализованной функции будет зависеть от опций виртуализации. Если функция виртуализована с антидампом, то вызов выполняется на переходник (новый вход в вм) а после него на точку начала виртуализованного тела функции (после блока антидампа). Если виртуализация без антидампа то вызов идет на переходник (новый вход в вм) и с него на виртуализованный код или сразу на виртуализованный код. Нахождение реального адреса функции в любой опции здесь идентично п.1а.
2в. Вызов из мутированного кода мутированной функции выполняется выполняется через переходник или сразу на мутированный код. Поиск реального адреса функции идентичен п.1в.

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

Если вернуться к предыдущему моему посту, то все 7 неопознанных вызовов я идентифицировал, а адрес 0xEA4A9D является не началом функции, а промежуточный входом в вм, поэтому тело реальной функции идентифицировать по нему невозможно и т.к. у меня девиртуализованы все функи защиты и этой точки в них не обнаружено и по характерным признакам самого восстановленного кода с этой точки можно сказать, что это кусок функции тела самого вмпрота.

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



Ранг: 331.5 (мудрец)
Статус: Участник

Создано: 20 июня 2017 19:09 New!
Цитата · Личное сообщение · #6

Vamit

> Может, но не весь, jmp останется.

Где останется, IA архитектура не обратима. После ветвления невозможно узнать его источник. Бред не пишите.

Дальнейший текст как обычно - поток мыслей тс.



Ранг: 18.4 (новичок)
Статус: Участник

Создано: 20 июня 2017 20:24 · Поправил: gggeorggge New!
Цитата · Личное сообщение · #7

анти дебаг продолжается и после завершения tls3. А я уж подумал, что все...




Ранг: 331.1 (мудрец)
Статус: Участник

Создано: 20 июня 2017 22:54 New!
Цитата · Личное сообщение · #8

difexacaw пишет:
Где останется, IA архитектура не обратима. После ветвления невозможно узнать его источник. Бред не пишите.

В коде функции останется, а бред только от тебя, всё что сожрано вмпротом возможно восстановить на своем родном месте, если не знаешь структуру прота, то не лезь со своими советами.

gggeorggge пишет:
А я уж подумал, что все...

Да он там во многие функции проги вставлен. Всю защиту я декомпильнул и то что нужно нашел... Можно обойтись без дебага, аттач к работающей проге, снятие нужных данных и раскодировка их.



Ранг: 50.0 (постоянный)
Статус: Участник

Создано: 21 июня 2017 06:12 New!
Цитата · Личное сообщение · #9

difexacaw пишет:
После ветвления невозможно узнать его источник.

А как же last branch msr's?



Ранг: 18.4 (новичок)
Статус: Участник

Создано: 21 июня 2017 11:29 · Поправил: gggeorggge New!
Цитата · Личное сообщение · #10

Vamit пишет:
Да он там во многие функции проги вставлен. Всю защиту я декомпильнул и то что нужно нашел... Можно обойтись без дебага, аттач к работающей проге, снятие нужных данных и раскодировка их.

Как вы обошли вызов tls при аттаче?




Ранг: 331.1 (мудрец)
Статус: Участник

Создано: 21 июня 2017 14:00 New!
Цитата · Личное сообщение · #11

gggeorggge пишет:
Как вы обошли вызов tls при аттаче?

Да никак не обходил. Я не знаю всю механику аттача, и выполняется tls при аттаче или нет - мне неизвестно.
Есть у меня какая-то Олькина сборка под WinXP со стронгом в kernel mode, которая нормально цепляется ко всем прогам. Посмотрел данные защиты в стат памяти, статус норм - ничего не сработало, что нужно взял и раскодировал. Но исполнять код после аттача уже нельзя, сразу следует RtlExitUserThread...




Ранг: 331.1 (мудрец)
Статус: Участник

Создано: 22 июня 2017 15:49 New!
Цитата · Личное сообщение · #12

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



Ранг: 35.4 (посетитель)
Статус: Участник

Создано: 22 июня 2017 17:33 New!
Цитата · Личное сообщение · #13

А если просто ядро заранее запатчить в бинарнике, чтобы функция скрытия потоков попросту не работала при каждом включении ОС?



Ранг: 18.4 (новичок)
Статус: Участник

Создано: 11 июля 2017 09:18 New!
Цитата · Личное сообщение · #14

Запустил в ollydbg эту программу без каких-то дополнительных средств после изучения системы защиты.
Отключил tls3 (он вызывается при создании каждого потока) установкой reason в 3 и остановил пару потоков, в которых был антидебаг.
А в чем смысл такой мощной защиты от антидебага? Реализован какой-то уникальный алгоритм?




Ранг: 756.3 (! !)
Статус: Участник
Student

Создано: 11 июля 2017 11:17 New!
Цитата · Личное сообщение · #15

Vamit в какой проге был применён данный вид защиты?



Ранг: 170.5 (ветеран)
Статус: Участник

Создано: 11 июля 2017 11:45 New!
Цитата · Личное сообщение · #16

В --> этом посте <-- линк на программу




Ранг: 331.1 (мудрец)
Статус: Участник

Создано: 11 июля 2017 15:34 New!
Цитата · Личное сообщение · #17

gggeorggge пишет:
Реализован какой-то уникальный алгоритм?

В принципе любой алгоритм взаимодействия сервер-клиент является уникальным (авторизация, сертификаты, трансфер данных, если он реализован не через системные АПИ). А смысл чтобы "грязными руками" не дебажили алгоритмы.
Вчера вышла новая версия этой проги, там вообще извращение: сам образ без вмпротовской упаковки, но вмпротовский протект образа включен, так же все интересные функи виртуализованы, импорт в корне отсутствует - очень похоже, что весь его засунули в эту защиту. Теперь дабаг далее первого вмпротовского тлс не идет.



Ранг: 18.4 (новичок)
Статус: Участник

Создано: 11 июля 2017 17:39 New!
Цитата · Личное сообщение · #18

Vamit пишет:
Теперь дабаг далее первого вмпротовского тлс не идет.

Интересно посмотреть. Пойду скачаю.



Ранг: 18.4 (новичок)
Статус: Участник

Создано: 25 июля 2017 08:01 · Поправил: gggeorggge New!
Цитата · Личное сообщение · #19

Vamit пишет:
Теперь дабаг далее первого вмпротовского тлс не идет.

Скачал последнюю версию. Без проблем остановился на тлс3 (0x0061d760)




Ранг: 331.1 (мудрец)
Статус: Участник

Создано: 25 июля 2017 09:38 New!
Цитата · Личное сообщение · #20

gggeorggge пишет:
Без проблем остановился на тлс3

Ну инструменты и системы у нас разные, а от них многое зависит. А что там с импортом, не смотрел?



Ранг: 18.4 (новичок)
Статус: Участник

Создано: 25 июля 2017 13:49 New!
Цитата · Личное сообщение · #21

Vamit пишет:
А что там с импортом, не смотрел?

Не смотрел, мне это не очень интересно.



Ранг: 41.3 (посетитель)
Статус: Участник

Создано: 26 июля 2017 16:13 · Поправил: bartolomeo New!
Цитата · Личное сообщение · #22

VOLKOFF пишет:
В --> этом посте <-- линк на программу


Яндекс пишет:
"Ничего не найдено
Возможно, владелец удалил файлы или закрыл к ним доступ.
А может быть, вам досталась ссылка с опечаткой."

Обновите ссылку или скиньте в личку - если не затруднит.




Ранг: 310.0 (мудрец)
Статус: Участник
Advisor

Создано: 21 ноября 2017 10:28 · Поправил: Bronco New!
Цитата · Личное сообщение · #23

перечитал, полезно, феньк
Vamit пишет:
Теперь дабаг далее первого вмпротовского тлс не идет.

фичи все старые, но защита решила хуки апишек по своему обходить, частично на сисколы ушла.
из новенького, но вроде это не антитрик, юзают сискол NtProtectVirtualMemory, проверяют_меняют атрибуты своих секций, их пока с релоками 3.
+ в х64 появился EXCEPTION_SINGLE_STEP // вот соскучились.
изменилось црц, меньше 2000 byte не парсят, контрольные суммы вроде привязаны к дельтам для служебных задач, длинно как то всё стало.
.



Ранг: 315.1 (мудрец)
Статус: Модератор
CrackLab

Создано: 21 ноября 2017 11:07 New!
Цитата · Личное сообщение · #24

Bronco пишет:
NtProtectVirtualMemory

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




Ранг: 310.0 (мудрец)
Статус: Участник
Advisor

Создано: 21 ноября 2017 17:50 · Поправил: Bronco New!
Цитата · Личное сообщение · #25

Bronco пишет:
вроде это не антитрик

да как бы нет самое оно, подкинули --> инфы <--
в моём случае NtProtectVirtualMemory юзают 3 раза подряд:
Code:
  1. //1.NtProtectVirtualMemory rdx = pointer for va addr section(14A116000) r8 = pointer for raw size (2A75AB) r9 = 40 r10 = 50
  2. //2.NtProtectVirtualMemory rdx = pointer for va addr section(14A110000) r8 = pointer for raw size (5E76) r9 = 4 r10 = 50
  3. //3.NtProtectVirtualMemory rdx = pointer for va addr section(14A146000) r8 = pointer for raw size (5B58) r9 = 40 r10 = 50

после вызов апи CloseHandle (0xDEADC0DE), после проверок имён эксе типа дбг. сингел_ степ на простом NOP
ещё такты стали юзать перед входом_выходом вм




Ранг: 672.3 (! !)
Статус: Участник
CyberMonk

Создано: 21 ноября 2017 20:47 New!
Цитата · Личное сообщение · #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.

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



Ранг: 310.0 (мудрец)
Статус: Участник
Advisor

Создано: 21 ноября 2017 21:04 · Поправил: Bronco New!
Цитата · Личное сообщение · #27

mak пишет:
то апи вернёт сингл степ

в итоге в связке это стелс бряк?
а там же палевА...))) полюбасу чекают железячки из структуры для диспатчера



Ранг: 3.4 (гость)
Статус: Участник

Создано: 22 ноября 2017 22:07 New!
Цитата · Личное сообщение · #28

bartolomeo
https://www.metaquotes.net/ru/metatrader5
Качайте и пробуйте.

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

<< . 1 . 2 . 3 . 4 . 5 .
 eXeL@B —› Основной форум —› Vmprotect. Хитрая защита от отладки.

Видеокурс ВЗЛОМ