Задача: сделать защиту программы (dll) путем шифрования участков кода. Экспериментируем в visual studio 2008.
Метод решения:
1. После компиляции участки кода из исполняемого файла (шифруемых процедур, которые прописаны как static) копируются в отдельные файлики, а их место затирается дребеденью.
2. После поставки программы заказчику ему пересылаются ключи (зашифрованные файлики), которые при исполнении программа берет с диска, расшифровывает, добавляет сама в себя и исполняется дальше.

Проблема. Все описанное прекрасно работает на x64, но при попытке переноса методы в x32 возникает проблема с тем, что содержимое static процедур в памяти при загрузке dll отличается от того, как они выглядят в самом файле dll на диске. Причем при каждой новой загрузке содержимое в памяти отличается от содержимого на диске в некоторых байтах .
Байты одни и те же. Т.е. содержимое основной массы байтов сохраняется, а небольшой массы байтов при загрузке меняется.

Варианты решения проблемы:
1. Для каждой шифруемой процедуры делать маску с байтами, содержимое которых при шифровке-расшифровке менять не нужно. — Это основной рабочий вариант, который я сейчас пытаюсь реализовать.
2. Может быть в настройках visual studio есть какие-то параметры, которые делают код процедур dll-ки неизменяющимся при загрузке в память?

Здравствуйте, Barm, Вы писал

Какой же гиммор вы создаете заказчикам и себе

B>Задача: сделать защиту программы (dll) путем шифрования участков кода. Экспериментируем в visual studio 2008.
B>Метод решения:
B>1. После компиляции участки кода из исполняемого файла (шифруемых процедур, которые прописаны как static) копируются в отдельные файлики, а их место затирается дребеденью.
B>2. После поставки программы заказчику ему пересылаются ключи (зашифрованные файлики), которые при исполнении программа берет с диска, расшифровывает, добавляет сама в себя и исполняется дальше.
B>Проблема. Все описанное прекрасно работает на x64, но при попытке переноса методы в x32 возникает проблема с тем, что содержимое static процедур в памяти при загрузке dll отличается от того, как они выглядят в самом файле dll на диске. Причем при каждой новой загрузке содержимое в памяти отличается от содержимого на диске в некоторых байтах .
B>Байты одни и те же. Т.е. содержимое основной массы байтов сохраняется, а небольшой массы байтов при загрузке меняется.
Дык это наверное указатели на функции в других длл и/или rebase фиксапы, которые лоадером резолвятся. Это просто можно и нужно учесть при шифровании — вся инфа про эту "небольшую массу байтов" имеется в PE заголовках.

Здравствуйте, Barm, Вы писали:

B>2. Может быть в настройках visual studio есть какие-то параметры, которые делают код процедур dll-ки неизменяющимся при загрузке в память?

Попробуй выключить ASLR в настройках проекта.

Но вообще, в тращициях данного форума, попинаю
IMHO, ерундой занимаетесь, если уж так нужно, просто возьмите готовй протектор.

Здравствуйте, ononim, Вы писали:

B>>Задача: сделать защиту программы (dll) путем шифрования участков кода. Экспериментируем в visual studio 2008.
B>>Метод решения:
B>>1. После компиляции участки кода из исполняемого файла (шифруемых процедур, которые прописаны как static) копируются в отдельные файлики, а их место затирается дребеденью.
B>>2. После поставки программы заказчику ему пересылаются ключи (зашифрованные файлики), которые при исполнении программа берет с диска, расшифровывает, добавляет сама в себя и исполняется дальше.
B>>Проблема. Все описанное прекрасно работает на x64, но при попытке переноса методы в x32 возникает проблема с тем, что содержимое static процедур в памяти при загрузке dll отличается от того, как они выглядят в самом файле dll на диске. Причем при каждой новой загрузке содержимое в памяти отличается от содержимого на диске в некоторых байтах .
B>>Байты одни и те же. Т.е. содержимое основной массы байтов сохраняется, а небольшой массы байтов при загрузке меняется.
O>Дык это наверное указатели на функции в других длл и/или rebase фиксапы, которые лоадером резолвятся. Это просто можно и нужно учесть при шифровании — вся инфа про эту "небольшую массу байтов" имеется в PE заголовках.

Интересно, что при компиляции под winx64 код процедуры в dll файле полностью соответствует тому, что в памяти (изменяемых байтов нет).
Причину наличия изменяемых байтов в win32 и неналичия оных в win64 искать не хочется. Пытаюсь тупо учесть их наличие и критические участки кода не трогать. Неделя мучений уже прошла. Если получиться — отпишусь.

B>Интересно, что при компиляции под winx64 код процедуры в dll файле полностью соответствует тому, что в памяти (изменяемых байтов нет).
Потому что в win64 нету инструкции call ptr_64, а есть только call [rip + delta_32], так что в x64 компилятор вынужден ложить указатели на external функции куданить в данные. А 32хбитный компилятор может и так и прямым адресом из инструкции.

B>Причину наличия изменяемых байтов в win32 и неналичия оных в win64 искать не хочется. Пытаюсь тупо учесть их наличие и критические участки кода не трогать. Неделя мучений уже прошла. Если получиться — отпишусь.
Советую как следует изучить матчасть прежде чем делать такие проекты. Там еще много подводных граблей.

Здравствуйте, bnk, Вы писали:

bnk>Здравствуйте, Barm, Вы писали:

B>>2. Может быть в настройках visual studio есть какие-то параметры, которые делают код процедур dll-ки неизменяющимся при загрузке в память?

bnk>Попробуй выключить ASLR в настройках проекта.
Уже пробовал. Не помогает.

bnk>Но вообще, в тращициях данного форума, попинаю
bnk>IMHO, ерундой занимаетесь, если уж так нужно, просто возьмите готовый протектор.

Угу. Готовые протекторы имеют готовые методики взлома.
Мне нужен протектор:
1. Закачивающий ключи на клиента при оплате.
2. Привязка ключей к железу клиента.
3. Возможность простой перепривязки программы с одного рабочего места на другое (включая win64 и win32).

Программа планируется дешевой, трата ручного времени на привязку каждого клиента исключена.
Максимум, что делается вручную — забивается e-mail клиента в базу данных "оплачено".

Денег априори на службу поддержки-установки нет. .

Здравствуйте, ononim, Вы писали:

B>>Интересно, что при компиляции под winx64 код процедуры в dll файле полностью соответствует тому, что в памяти (изменяемых байтов нет).
O>Потому что в win64 нету инструкции call ptr_64, а есть только call [rip + delta_32], так что в x64 компилятор вынужден ложить указатели на external функции куданить в данные. А 32хбитный компилятор может и так и прямым адресом из инструкции.

B>>Причину наличия изменяемых байтов в win32 и неналичия оных в win64 искать не хочется. Пытаюсь тупо учесть их наличие и критические участки кода не трогать. Неделя мучений уже прошла. Если получиться — отпишусь.
O>Советую как следует изучить матчасть прежде чем делать такие проекты. Там еще много подводных граблей.

Писал прогу около полутора лет. Писал сразу под win64. Рабочий экземпляр уже есть для x64. Граблей уже было море.

Осталось перенести на win32. И тут произошел этот затык. Можно делать защиту, шифруя при исполнении данные, но:
1. Мне опять все переделывать.
2. Шифровка данных приводит к торможению проги. Код один раз расшифровал и он быстры данные перелопачивает.

Хотя можно бонусом небольшую шифровку данных делать (шифруя ключом от сервера (имея данные по клиенту), а расшифровываешь ключом с данными об оборудовании, собранном на клиенте).

Здравствуйте, Barm, Вы писали:

bnk>>Но вообще, в тращициях данного форума, попинаю
bnk>>IMHO, ерундой занимаетесь, если уж так нужно, просто возьмите готовый протектор.

B>Угу. Готовые протекторы имеют готовые методики взлома.

Ты сможешь лучше, чем сделано в VmProtect?


B>Мне нужен протектор:
B>1. Закачивающий ключи на клиента при оплате.

VmProtect (+vmpKit )

B>2. Привязка ключей к железу клиента.

VmProtect

B>3. Возможность простой перепривязки программы с одного рабочего места на другое (включая win64 и win32).

VmProtect

B>Программа планируется дешевой, трата ручного времени на привязку каждого клиента исключена.
B>Максимум, что делается вручную — забивается e-mail клиента в базу данных "оплачено".

VmProtect

B>Денег априори на службу поддержки-установки нет. .

VmProtect

M>VmProtect
Или Themida WinLicense. Рекомендую рассмотреть как альтернативу.

Здравствуйте, b0r3d0m, Вы писали:

M>>VmProtect
B>Или Themida WinLicense. Рекомендую рассмотреть как альтернативу.

почему не Denuvo? Очень хорошая защита

wl.>почему не Denuvo? Очень хорошая защита
Да просто лично использовал WinLicense, вот и посоветовал.

Здравствуйте, Barm, Вы писали:


B>Задача: сделать защиту программы (dll) путем шифрования участков кода.
Ух. Это привет из… 1999 года?

B>Метод решения:
B>1. После компиляции участки кода из исполняемого файла (шифруемых процедур, которые прописаны как static) копируются в отдельные файлики, а их место затирается дребеденью.
Почему не просто зашифровать на месте, зачем файлы? Или зашифровать dll, если уж хочется совсем не давать код для demo?

B>Байты одни и те же. Т.е. содержимое основной массы байтов сохраняется, а небольшой массы байтов при загрузке меняется.
За полтора года "проекта" про релоки не слышали?


B>2. Может быть в настройках visual studio есть какие-то параметры, которые делают код процедур dll-ки неизменяющимся при загрузке в память?
В gcc есть -fPIC.

Здравствуйте, wl., Вы писали:

wl.>почему не Denuvo? Очень хорошая защита
Это в виде шутки? Ее ж заломали недавно. Да и ценник у нее кусючий.

Здравствуйте, pva, Вы писали:

pva>Это в виде шутки? Ее ж заломали недавно. Да и ценник у нее кусючий.
а vmprotect взломали, случаем не в курсе?

X>а vmprotect взломали, случаем не в курсе?
Всех ломают.

Здравствуйте, b0r3d0m, Вы писали:

B>Всех ломают.
да, отднажды, лет через 200 — возможно. но меня интересует сейчас.

X>да, отднажды, лет через 200 — возможно. но меня интересует сейчас.
На unpack.cn и прочих подобных ресурсах постоянно выкладывают анпакеры для всех популярных протекторов, включая VMProtect и WinLicense. В паблик, разумеется, обычно попадают анпакеры для предпоследних версий данных протекторов.

Здравствуйте, b0r3d0m, Вы писали:

B>На unpack.cn
похоже мертв.

X>похоже мертв.
https://tuts4you.com/ тогда глянь.