Здравствуйте.
Есть вопросы по маркерам.
Среда разработки - C++ Builder.
1. В документации указано что не допускается их вложенность.
Есть некоторая процедура, в протекторе на неё установлена опция привязки к ключу SenseLock. Внутри процедуры есть место с циклом из большого количества проходов. На этом цикле потеря быстродействия при виртуализации критическая. Если я оберну этот участок кода в маркеры VMProtectBegin(НАЗВАНИЕ_МАРКЕРА); VMProtectEnd; и установлю на этот участок мутацию - будет ли нормально работать такая конструкция и будет ли виртуализирован и привязан к ключу весь код за пределами этих маркеров.

2. Если я добавляю в исходный код маркеры, есть ли возможность выставить где-то опцию, чтобы проект компилировался так, как будто маркеров нет вообще? Т.е., допустим, при создании другой версии программы используется другой протектор и условная компиляция и я бы не хотел, чтобы, в код приложения компилировался отладочный код vmprotect, как это сделать с наименьшими изменениями кода? Оборачивать каждый маркер в #ifdef vmprot ... #endif ?

Да, и немного из другой области - а VMProtectLicense.ini используется в VMProtector SE ? Если да, то где его описание почитать - в хелпе мало уделено внимания SE-версии протектора.

Простите за 2 поста подряд. Попробовал по первому вопросу - протектор определяет такие маркеры как непарные. Вопрос снят. Второй в силе.

По первому вопросу. Когда добавлял маркеры, написал VMProtectEnd без завершающих скобок (), потому протектор не находил пару для VMProtectStart. А при подобной ситуации на самом деле протектор пишет

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

Из-за того, что один и тотже код вы хотите обработать по-разному.
Со вложенными маркерами немного другая ситуация. Вложенность определяется сразу на этапе анализа файла:

В таком варианте протектор вам скажет, что VMProtectBegin('1') и второй VMProtectEnd непарные и в проект вы сможете включить только VMProtectMarker "2".
Чтобы решить проблему с критическим циклом внутри завиртуализированной процедуры, то тут есть 2 варианта:
1. Вынести цикл в отдельную процедуру
2. Разбить все тело процедуры на несколько маркеров:

2. Я думаю так будет нагляднее:

3. VMProtectLicense.ini не используется в SE.

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

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