VMProtect Software » Forum

Каким образом можно зашифровать ресурсы программы от любопытных глаз? Например, PE Explorer 1.99 R6 успешно открывает их в защищенном exe.

Вас интересует скрытие ресурсов в файле или в памяти после запуска программы?

в файле

Упаковка файла (без использовании опции "Перемещать ресурсы в конец файла") упаковывает в том числе и содержимое ресурсов, но структура дерева ресурсов при этом остается оригинальной.

Admin wrote:Упаковка файла (без использовании опции "Перемещать ресурсы в конец файла") упаковывает в том числе и содержимое ресурсов, но структура дерева ресурсов при этом остается оригинальной.

Можно ли сделать так, чтобы ресурсы запаковывались с дополнительным шифрованием, т.е. в последствии не могли быть распакованы с помощью таких специализированных программ, как PE Explorer?

Немного теории:
PE Explorer ничего не распаковывает, а просматривает содержимое ресурсов в файле. Если вы выбираете упаковку защищенного файла, то все ресурсы (за исключением иконок, минифеста и т.п.) остаются незапакованными, а все остальное пакуется и в файле остается ТОЛЬКО дерево ресурсов, при этом содержимое самих ресурсов физически отсутствует. После запуска программы (после отработки кода VMProtect) все ресурсы распаковываются на свои места. Вот только после этого можно сдампить образ программы в отдельный файл и увидеть в нем все содержимое ресурсов с помощью PE Explorer и подобных инструментов.

Теперь практика:
В настоящее время VMprotect не имеет возможности зашифровать ресурсы так, чтобы они дешифровались в момент обращения к ним, поэтому есть 2 варианта, которые вы можете реализовать сами:
1. Вы сами можете зашифровать содержимое ресурсов перед упаковкой, а затем в своей программа их расшифровывать перед использованием.
2. Если подойти к задаче более универсально, то дешифровку ресурсов на лету можно сделать с помощью перехвата всех API, которые вызывает программа при работе с ресурсами. Таким образом после отработки оригинальной API, которая вернет указатель на ресурс останется дешифровать его в отдельную память и вернуть указатель на неё вызывающему коду.

Каким образом можно зашифровать ресурсы программы от любопытных глаз?

Батенька, да ва параноик на 100%.
Чем больше читаю этот форум - тем больше удивляюсь таким программерам как вы. Нет чтобы подумать головой и использовать собственные механизмы защиты своей же программы, прятать то что хочется прятать, а Вы надеетесь что кто то, что то, сделает за вас. Как по мне VMProtect нужно использовать чтобы сбить с толку любопытных кодокопателей - и только, а не как панацею от всех возможных бед которые связаны с защитой.

Cyber wrote: Нет чтобы подумать головой и использовать собственные механизмы защиты своей же программы, прятать то что хочется прятать, а Вы надеетесь что кто то, что то, сделает за вас.

Ну почему же - хотелка вполне нормальная. Взять теже дельфовые DFM-ки. После прогона их через DeDe можно найти в коде обработчики событий формы и быстрее найти код, который нужно поломать. Делать это самому ессно не хочется и пользователь ждет такую фичу от протектора. Вобщем вполне рабочий процесс )

"Защита ресурсов" запланирована в версии 2.08 (будет доступна для EXE файлов в Ultimate версии). В результате использования этой опции все данные ресурсов (за исключением иконок, манифеста и т.п.) будут полностью обрабатываться внутри модуля защиты и не будут видны даже при снятии дампа с работающей программы.

Только теперь не работает:
EnumResourceNames(NULL, "FILES", (ENUMRESNAMEPROC)EnumResNameProc, (LONG_PTR)this);


file0 FILES "file0.bin"
file1 FILES "file1.bin"
file2 FILES "file2.bin"

EnumResNameProc ни разу не вызывается

EnumResourceNames не поддерживается.

Есть планы на поддержку EnumResourceNames? Или лучше так: какие функции поддерживаются?

Пoддержка EnumResourceNames - это палка о двух концах. С одного конца её используете вы, а с другого - крякер ) Т.е. с помощью инжекта собственной DLL крякер сможет определить все ресурсы, которые у вас защищены и в конечном итогде их достать в раскриптованном виде. Единственный вариант более менее "секурной" реализации - это перехватывать EnumResourceNames на уровне IAT модуля, а не на уровне перехвата API в kernel32, но в этом случае будут некоторые ограничения (например нельзя будет использовать EnumResourceNames как результат от GetProcAddress(...,'EnumResourceNames'), а также при вызове из других модулей).

Я так и подумал. Есть ещё вариант более менее "секурной" реализации: VMProtectEnumResourceNames

VMProtectEnumResourceNames как раз ничем не будет отличаться от перехвата EnumResourceNames на уровне IAT.