Очень бы не пригодился встроенный механизм замены в экзешнике сивольных имен RTTI на случайно сгенерированные…
При изменении имен в RTTI нужно как минимум поддержать это изменение на уровне ресурсов (если речь идет о Delphi), т.е. полностью разбирать структуру DFM и при замене имен придется делать еще и ребилд ресурсов. В любом случае поиск самой RTTI не в ран тайме ИМХО очень нетривиальная задача 
)
Я имел в виду следующее. Список символьных имен можно извлечь из исходников (у разработчика они всегда под рукой, имена сторонних компонентов, подключаемых в виде DCU и т.п. можно не обрабатывать), а в экзешнике менять эти имена на случайно сгенерированные, но той же длины. В этом случае ребилд ресурсов делать не придется.
По крайней мере у меня такой подход работает.
Список символьных имен можно извлечь из исходников
VMProtect не работает с исходниками самой программы, т.е. получать этот список придется на этапе дизассемблирования, а это (как я уже говорил) очень нетривиальная задача.
Еще одно пожелание:
после закрытия проекта (в меню Файл выбираем Закрыть) не освобождается дескриптор файла-исходника, что иногда вызывает неудобства (невозможно перекомпилировать проект, так как компилятор не может перезаписать экзешник).
Исправьте пожалуйста:)
невозможно перекомпилировать проект, так как компилятор не может перезаписать экзешник
Какая у вас версия VMProtect? Проверил на 1.54 все ОК.
1.54…
Не воспроизводится 
(
Проблема скорее всего связана с долгим закрытием файлов в 1.54 (ошибка будет исправлена в 1.55)
По поводу изменения символьных имён - это возможно будет реализовать с помощью скрипта (в версии 1.55 у TPEFile появятся методы чтения и записи данных в файл).
Поддержка процессора ARM
Поддержка процессора ARM
У виртуальной машины есть один недостаток - очень низкая скорость работы пикода по сравнению с нативом. Пока быстродействие самих процессоров ARM не очень велико - заниматься виртуализацией кода для ARM не перспективно.
Тогда, может быть, Вы рассмотрите возможность поддержки ELF в будущих версиях программы? Там все работает быстро, точнее, “как обычно”
p.s. Я имею некоторый опыт работы на платформах с процессорами ARM, мне думается, что не все так плохо.
Тогда, может быть, Вы рассмотрите возможность поддержки ELF в будущих версиях программы?
Вы думаете на системах, которые пропагандируют OpenSource, будет восстребован проект по защите программ от анализа и взлома? ) Возможно в далеком будущем такая возможность появится, но сейчас много направлений работы и для Win32.
Об этом я судить не рискну - затем что не знаком с содержанием пропаганды. Могу сказать лишь за себя - компания, которую я представляю, готова заплатить за такой продукт. Однако, его нет.
Ясно, спасибо
Об этом я судить не рискну - затем что не знаком с содержанием пропаганды.
Дык всё очень просто - ELF поддерживается только на *nix системах, для которых в настоящее время очень мало коммерческого ПО (по сравнению с той же Windows).
Могу сказать лишь за себя - компания, которую я представляю, готова заплатить за такой продукт. Однако, его нет.
Если Ваша компания действительно заинтересована в инструменте по защите ELF файлов, то мы можем обсудить возможность этой разработки.
В версии 1.70.3 и выше есть ошибка.
Берем стандартный notepad.exe от Windows XP.
Накладываем на него защиту на стартовую процедуру используя водяные знаки, ставим максимальную.
Защиту от дебагинга и виртуализации не пользуем, число виртуальных машин 1.
Делаем удаление настраиваемых элементов и перемещаем ресурсы в конец. Главное это водяной знак.
Накладываем защиту и при запуске программы получаем:
File corrupted!. This program has been manipulated and maybe
it’s infected by a Virus or cracked. This file won’t work anymore.
Если мы убираем Включить в компиляцию водяной знак, то программа потом запускается.
Еще если оставить Водяные знаки, а убрать Защиту памяти, то программа потом тоже запускается.
Но Защита памяти и Водяные знаки приводят к данной ошибке.
Какая версия подразумевается под “и выше”?
1.70.6
Ок. Будет исправлено в 1.71