Столкнулся с тем во время открытия файла который необходимо защитить, программа выдает сообщение:
найдено 32 не пархных маркеров. Причем все функции которые необходимо защитить перечисленны в окне “процедуры для защиты” правда три из них имеют имена VMProtectMarker1,VMProtectMarker2,VMProtectMarker3
Это вообще нормально?
Непарные маркеры это ненормально. Могут возникать в том числе и из-за оптимизации кода: http://www.vmpsoft.com/forumhttps://forum.vmpsoft.com/viewtopic.php?f=4&t=216
Поменял тип оптимизации с Maximum speed to Minimal Size - сообщение о не парных паркерах пропало, но все равно некоторые маркеры не имеют нормального имени, а называются VMProtectMarker1,VMProtectMarker2,VMProtectMarker3. А вот в режиме оптимизации Default все нормально.
В общем в чем искать причину? 
но все равно некоторые маркеры не имеют нормального имени, а называются VMProtectMarker1,VMProtectMarker2,VMProtectMarker3
Присылайте пример такого файла.
Присылайте пример такого файла.
Выслал вам файл на info@..
Непарный маркер возникает из-за оптимизации:
004035A0 7463 jz 00403605
004035A2 8B442414 mov eax, [esp+14]
004035A6 50 push eax
004035A7 FFD6 call esi
004035A9 55 push ebp
004035AA FFD6 call esi
004035AC FF15E4804000 call dword ptr [004080E4] -> VMProtectSDK32.VMProtectEnd
004035B2 8BC7 mov eax, edi
004035B4 5F pop edi
004035B5 5E pop esi
004035B6 5D pop ebp
004035B7 5B pop ebx
004035B8 83C408 add esp, 08
004035BB C3 ret
...
-------------- UnpairedVMProtectEnd1 ----------------------
00403657 FF15E4804000 call dword ptr [004080E4] -> VMProtectSDK32.VMProtectEnd
0040365D 8BC7 mov eax, edi
0040365F 5F pop edi
00403660 5E pop esi
00403661 5D pop ebp
00403662 5B pop ebx
00403663 83C408 add esp, 08
00403666 C3 ret
Компилятор развел код на 2 ветки в результате получились 2 VMProtectEnd, второй из которых был признан непарным, т.к. ему не хватает парного VMProtectBegin.
Чтобы отбить желание у оптимизатора разводить окончание функции на 2 ветки (если окончание маркера стоит в конце функции), то для x32 кода можно предложить использовать вот такой маркер окончания блока:
#define VMProtectEnd2() \
__asm {nop} \
VMProtectEnd();
Для x64 решение пока не найдено.
Спасибо за разъяснение.
В общем на данном этапе решением будет отключат оптимизацию т.к нужно поддержка и х64 кода.
А что насчет неправильных имен секций? Это не критично?
А что насчет неправильных имен секций? Это не критично?
С названием маркера ситуация следующая:
0040347B 68E4A04000 push 0040A0E4 -> ANSI "CTestCoreIface::CTestCoreIface"
00403480 C70788844000 mov dword ptr [edi], 00408488 -> ANSI "p6@"
00403486 895F04 mov [edi+04], ebx
00403489 895F08 mov [edi+08], ebx
0040348C 895F0C mov [edi+0C], ebx
0040348F 895F10 mov [edi+10], ebx
00403492 895F14 mov [edi+14], ebx
00403495 895F18 mov [edi+18], ebx
00403498 895F1C mov [edi+1C], ebx
0040349B FF15E8804000 call dword ptr [004080E8] <- VMProtectMarker1
VMProtect начинает дизассемблировать код с call dword ptr [004080E8] вверх на дистанцию 20 байт для поиска аргумента для VMProtectBegin. В вашем случае он просто не добегает до push 0040A0E4, т.к. там получается 32 байта. В следующей версии мы увеличим дистанцию для этого алгоритма.
А когда ориентировочно планирует обновленная версия с иправлением имен секций?
И еще вопрос:
Вы наверное проводили тестирование проиводительности. Насколько мутированный код устпутает в производительности реальному оптимизированному коду?
А когда ориентировочно планирует обновленная версия с иправлением имен секций?
Буквально сегодня состоялся релиз 2.05, в котором эта проблема исправлена.
Вы наверное проводили тестирование проиводительности. Насколько мутированный код устпутает в производительности реальному оптимизированному коду?
Ориентировочно скорость кода после мутации падает в 10-100 раз.
Буквально сегодня состоялся релиз 2.05, в котором эта проблема исправлена.
Cпасибо все ок.
Еще один вопрос. В настройках проекта есть поле VMExecutorCount=1. Если я использую только мутацию - можно ли сбросить его в 0, чтобы никакого дополнительного кода в exe-шник не прописавалось?
В настройках проекта есть поле VMExecutorCount=1. Если я использую только мутацию - можно ли сбросить его в 0, чтобы никакого дополнительного кода в exe-шник не прописавалось?
Если в проект не включен код, для которого нужна виртуализация, то исполнители ВМ не встраиваются независимо от значения VMExecutorCount. Поэтому нет никакой необходимости обнулять VMExecutorCount на уровне проекта.