Не удается отпрофилировать приложение. Можно ли при защитить?

Если защищаемое приложение не работает ни под "оффлайн-", ни под "онлайн-" профайлерами, получится ли навесить защиту на основе prc-файла, полученого на этапе предварительного анализа кода?

Re: Не удается отпрофилировать приложение. Можно ли при защитить?

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-файла не фиксирован, не документирован и может измениться в будущих версиях. Информация актуальна лишь на текущий момент.

С уважением,
Степин Андрей

Re: Не удается отпрофилировать приложение. Можно ли при защитить?

AndreyStepin
В последних версиях профайлера вместо блока 4 стали блоки 6. Их тоже менять на 2, или 6 тоже подходит для онлайн обработки сервером?
И ещё скажите на сколько продуктивно будет обработка только собственных процедур и модулей, не затрагиваю при этом стандартные процедуры и функции языка. Я имею ввиду при ручном проставлении.

Re: Не удается отпрофилировать приложение. Можно ли при защитить?

Блоки с параметром 6 - универсальные (4+2) и подходят как для обработки псевдокодом, так и сервером Guardant Online. Фактически, для Guardant Online типы 6 и 2 - идентичны.

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

Re: Не удается отпрофилировать приложение. Можно ли при защитить?

AndreyStepin
Собственных модулей как правило в проекте не много, их вполне можно выделять вручную целиком, в моём случае даже с медленными блоками что не вызывает особых замедлений работы программы. В этом случае пользоваться функцией "Запустить сессию профелирования" я так понимаю нет необходимости? Не будет ли слишком явно какие процедуры надо разбирать хакеру при анализе программы?

Re: Не удается отпрофилировать приложение. Можно ли при защитить?

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

Проблемы с хакером тут не будет, учитывая во что превращается процедура после защиты. Дело в том, что хакеру в любом случае надо не процедуры разбирать - а раскручивать всю логику работы псевдокода - что является колоссально сложной задачей. А если у вас используется Guardant API то оно автоматически прилинкуется к вашему коду и накроется единым экземпляром псевдокода вместе с ним, что осложняет задачу до максимума.