Приветствую!
Года 3 назад приобрел протектор+WLM под винду, в целом - доволен.
Сейчас заинтересовался версией протектора под Linux.
Попробовал демо-версию - все работает, за исключением пары нюансов.
Дистрибутив - Ubuntu 16.04 LTS под VirtualBox, gcc 5.4.0
1. Наблюдал на рабочем столе 2 иконки приложения.
Необработанный файл - одна иконка, обработанный - две.
Повторилось после обработки еще одной сборки, и больше не проявлялось. Так и не понял, что это было.
Может, ограничение демо-версии? =)
2. В одном месте обработанный проект падал (на винде - все ок).
Простая функция с 3-мя вложенными if, падало при наличии VMProtectBeginUltra("..."), даже без защищаемого кода.
Пришлось сделать рефакторинг и вынести защищаемый код в ином виде, падать перестало.
Видимо, у линуксовой версии пользователей все же существенно меньше, и еще не все юзкейсы отработаны.
3. Поддерживается ли режим тестирования с файлом VMProtectLicense.ini, находящимся рядом с исполняемым файлом?
В целом все работает, система активации тоже.
Но есть вопросы по степени защиты линуксовой версии от взлома.
В силу того, что защита основана на асимметричном шифровании - в исполняемый файл зашивается публичный ключ, с помощью которого из серийника извлекается вся нужная информация. То есть, теоретически, для взлома достаточно найти способ заменить в исполняемом файле публичный ключ на свой, и дальше генерить серийники на своей ключевой паре.
То есть, ключевой вопрос - насколько просто будет найти публичный ключ? А с учетом того, что у нас - linux с открытым исходным кодом, задача взломщика может быть существенно упрощена. А результат взлома (в виде полученных знаний об организации кода и т.п.) затем может использоваться для взлома также и виндовой версии.
Что могут сказать разработчики успокоения ради?
Спасибо!
Linux demo
Re: Linux demo
У демо нет таких ограничений.Может, ограничение демо-версии? =)
Нужен тестовый проект, на котором воспроизводится данная проблема.2. В одном месте обработанный проект падал (на винде - все ок).
Да.3. Поддерживается ли режим тестирования с файлом VMProtectLicense.ini, находящимся рядом с исполняемым файлом?
Вы говорите про наш публичный ключ? Если да, то он хранится точно также как и в виндовой версии в зашифрованном виде. Причем здесь сам Linux с открытым исходным кодом я так и не понял.То есть, ключевой вопрос - насколько просто будет найти публичный ключ? А с учетом того, что у нас - linux с открытым исходным кодом, задача взломщика может быть существенно упрощена. А результат взлома (в виде полученных знаний об организации кода и т.п.) затем может использоваться для взлома также и виндовой версии.
Re: Linux demo
А какие еще есть варианты в случае, если сделать тестовый проект не представляется возможным?Нужен тестовый проект, на котором воспроизводится данная проблема.
Структура исходного проекта достаточно сложная, и воспроизвести проблему на абстрактном тестовом примере не удается.
На Ubuntu 16.04 (GCC 5.4.0) все обошлось небольшим рефакторингом в одном месте.
А вот на Astra SE 1.6 (GCC 6.3.0) подобных проблем гораздо больше.
Если не использовать VMProtectBegin...() - все работает.
А если использовать - то падает в неожиданных местах. Например, при завершении работы приложения, вызывается деструктор некоторого объекта, и после его вызова падаем. Никакой защиты в этом месте нет. Возможно, защита какого-то кода в конструкторе или ином месте повлияла на то, что в деструкторе падаем?
И проявляется это как-то странно.
Например, есть 10 защищенных участков кода. Падаем. Комментируем 3, генерим исполняемый файл - не падаем. Разрешаем одно из 3-х - падаем. Снова комментируем - падаем (совсем недавно в этой конфигурации не падали).
Возможно, есть какой-то расширенный список рекомендаций по организации защищенного кода?
Re: Linux demo
Попробуйте для GCC добавить параметр "no-red-zone". Если проблемы не исчезнут, то нужно будет разбиться более детально.
Re: Linux demo
Добавление флага "-mno-red-zone" ничего не дало.Admin wrote:Попробуйте для GCC добавить параметр "no-red-zone". Если проблемы не исчезнут, то нужно будет разбиться более детально.
Зато после удаление флагов "-static-libgcc -static-libstdc++" самые странные падения прекратились.