romik пишет:Если защищаемое приложение не работает ни под "оффлайн-", ни под "онлайн-" профайлерами, получится ли навесить защиту на основе prc-файла, полученого на этапе предварительного анализа кода?
Здравствуйте,
Мы работаем над ускорением работы профайлера, и рассчитываю, что в течение июля вышлем вам новую версию.
Отвечая на ваш вопрос, могу лишь предложить вручную отредактировать prc-файл. Если вы проведете статическое профилирование и сохраните prc-файл, то получится довольно простой по структуре (хоть и объемный) xml-документ. Он состоит из описаний модулей, каждый из которых разбит на функции, каждая из которых разбита на "базовые блоки". Атрибуты защиты приписываются каждому базовому блоку. После статического профилирования профайлер отмечает базовые блоки атрибутом ProtectionType="Х", где X - битовая маска для типов защиты.
Если ProtectionType="4" - то профайлер пометил блок как пригодный к RIP_CODE, если ProtectionType="0" - то блок к RIP_CODE не пригоден. Для защиты на сервере псевдокодом нужен тип ProtectionType="2". В принципе, вы можете автозаменой в любом текстовом редакторе заменить ProtectionType="4" например на ProtectionType="2", тогда все что выбрал статический профайлер для RIP_CODE будет накрыто псевдокодом на сервере. Вы можете в любой функции у любого базового блока выставить ProtectionType="2" и тогда этот базовый блок будет накрыт псевдкодом. Если у функции у всех базовых блоков стоит "2", то вся функция будет защищена. Обратите внимание, что защитить псевдокодом можно абсолютно любой базовый блок любой функции, а вот защитить RIP_CODE можно лишь те блоки, где профайлер выставил "4".
Динамический профайлер расставит все эти признаки автоматически по результатам профилирования.
Мы ведем работы, что все это можно было проще и быстрее делать из GUI-интерфейса.
Обращаю ваше внимание, что формат PRC-файла не фиксирован, не документирован и может измениться в будущих версиях. Информация актуальна лишь на текущий момент.
С уважением,
Степин Андрей