Вопрос по маркерам

[Bjlaq]

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

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

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

[Bjlaq]

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

[Bjlaq]

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

Code: Select all

[Ошибка] VMProtectMarker "xxx".00424Bxx: Адрес используется процедурой "__fastcall xxx(System::TObject *)"

[Admin]

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

Code: Select all

[Ошибка] VMProtectMarker "xxx".00424Bxx: Адрес используется процедурой "__fastcall xxx(System::TObject *)"

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

Code: Select all

VMProtectBegin('1');
...
VMProtectBegin('2');
...
VMProtectEnd;
...
VMProtectEnd;

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

Code: Select all

begin
VMProtectVirtualizationBegin('start');
...
VMProtectEnd;
VMProtectMutationBegin('cycle');
...
// тело цикла
...
VMProtectEnd;
VMProtectVirtualizationBegin('end');
...
VMProtectEnd;
end;

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

Оборачивать каждый маркер в #ifdef vmprot ... #endif ?

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

[Bjlaq]

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

Code: Select all

VMNoProtectBegin('NotProt');
...
VMNoProtectEnd;

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