Пожелания и вопросы

[jx]

Из переписки:

> Скажите, есть ли в вашем протекторе следующие функции:
> * обнаружение программ-мониторов (RegMon, FileMon);

Нет. А зачем? )

Как зачем? Некоторая секретная информация (trial, защита от отката, ключи и т.п.) может хранится в реестре или в файлах. К тому же, под правами юзера версия BIOS'а (для привязки к железу) может тоже читаться из реестра и т.д.

> * шифрование всего файла (не упаковка!);
> * Шифруются ли ресурсы?

Нет. А зачем это делать если после старта программы это все будет
расшифровываться и расшифрованный файл можно сдампить?

Хотя бы для того, чтобы в защищённом файле не было видно строк и функций в открытом виде. Ведь сжатие может и не сработать (файл может быть не сжимаемым либо я могу захотеть его отключить) или не скрыть всей информации.
А чтобы сдампить, кстати, нужно сначала пройти защиты анти-дамп и анти-дебаг. Это всё доп. работа (для кого-то нерешаемая). А так можно взять Hiew/WinHex и ничего даже дампить не нужно.

Кстати, анти-дамперские технологии вы же используете какие-то?

> * антипатчинг (защита от изменения файла)?

Да - защита памяти.

Память - это понятно. А сам файл? Я, например, могу спокойно заменить stub, может даже ресурсы (опять же, в варианте без сжатия) и т.д. Могу даже "защитить" какой-нибудь анти-VMProtect'овой прогой

> * При защите приложения для Delphi (а в частности API-маркерами) и
> использования в нём функций дефишровки данных нужно таскать с собой
> VMProtectSDK32.dll ?

Нет.

А как же тогда? DCU-модуля вроже тоже нет.

> * Если в программе произойдёт исключение, адрес ошибки будет показан
> тот же, что и в незащищённой проге?

Если исключение произойдет в завиртуализированном.промутированном
коде, то покажется новый адрес исключения, а не оригинальный.

А если мой код находится после завиртуализированного/промутированного кода?

[Admin]

Как зачем? Некоторая секретная информация (trial, защита от отката, ключи и т.п.) может хранится в реестре или в файлах. К тому же, под правами юзера версия BIOS'а (для привязки к железу) может тоже читаться из реестра и т.д.

Добавить проверку на RegMon, FileMon это не проблема. Вопрос - что вы хотите этим добиться? Если вы хотите прятать триальные метки в реестре/файловой системе, то определить какие АПИ вы вызываете и с какими параметрами - можно и без перечисленных инструментов.

Хотя бы для того, чтобы в защищённом файле не было видно строк и функций в открытом виде.

А кто вам запрещает завиртуализировать критичные для анализа/взлома участки вашего кода/данных?

Ведь сжатие может и не сработать (файл может быть не сжимаемым либо я могу захотеть его отключить) или не скрыть всей информации. А чтобы сдампить, кстати, нужно сначала пройти защиты анти-дамп и анти-дебаг. Это всё доп. работа (для кого-то нерешаемая). А так можно взять Hiew/WinHex и ничего даже дампить не нужно.

Упаковка - это только дополнительные барьер против "быстрого" патча файла. Её совершенно нельзя рассматривать как вариант сокрытия ваших данных от посторонних глаз, т.к. при старте программы все секции программы автоматически распаковываются и для снятия дампа совершенно необязательно обходить антиотладку и антидамп, т.к. IDA/Hiew/WinHex сожрет его и в таком виде )

Память - это понятно. А сам файл? Я, например, могу спокойно заменить stub, может даже ресурсы (опять же, в варианте без сжатия) и т.д. Могу даже "защитить" какой-нибудь анти-VMProtect'овой прогой Smile

Начнем с того, что:
1. Любые изменения файла автоматически приводят к изменению образа файла в памяти (есть конечно пути обхода этого - но это отдельная тема)
2. Для доступа к файлу вам понадобится вызовы нескольких АПИ, результат которых может быть перехвачен.
3. Со stub и ресурсами так и не понял - защита памяти не позволит вам это сделать уже сейчас.

Цитата:
> * При защите приложения для Delphi (а в частности API-маркерами) и
> использования в нём функций дефишровки данных нужно таскать с собой
> VMProtectSDK32.dll ?

Нет.
А как же тогда? DCU-модуля вроже тоже нет.

Вы спросили - "нужно таскать с собой VMProtectSDK32.dll ?" я ответил - "Нет (не нужно)". Зачем вам после этого понадобился DCU я не понял.

А если мой код находится после завиртуализированного/промутированного кода?

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

[jx]

Добавить проверку на RegMon, FileMon это не проблема. Вопрос - что вы хотите этим добиться? Если вы хотите прятать триальные метки в реестре/файловой системе, то определить какие АПИ вы вызываете и с какими параметрами - можно и без перечисленных инструментов.

Я не спорю, но через RegMon/FileMon это сделать проще всего (даже для того, кто не разбирается в тонкостях крякинга). А наша с вами задача - максимально усложнить этот процесс.

А кто вам запрещает завиртуализировать критичные для анализа/взлома участки вашего кода/данных?

Критичные - никто. А если я не хочу вообще показывать что-либо посторонним глазам? К тому же, если крякер сможет локализовать критичный участок, то он уже будет знать с чем ему работать. А значит, какая-то часть его работы уже сделана. Криптование всего файла ещё более усложнит этот процесс.

1. Любые изменения файла автоматически приводят к изменению образа файла в памяти (есть конечно пути обхода этого - но это отдельная тема)

Кто этой отдельной темой владеет, то сможет. К тому же, если вы используете CRC, то есть методы, позволяющие подогнать CRC к нужному значению, исправив пару байт.

2. Для доступа к файлу вам понадобится вызовы нескольких АПИ, результат которых может быть перехвачен.

Ну и пёс с ними, пускай перехватывают. Лишний гемор для крякера
К тому же, повторюсь, наверняка можно приделать к проге какой-нибудь блок, который будет нейтрализировать работу протектра.

Вы спросили - "нужно таскать с собой VMProtectSDK32.dll ?" я ответил - "Нет (не нужно)". Зачем вам после этого понадобился DCU я не понял.

Т.е. протектор "вшивает" эту DLL-ку в прогу после защиты?

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

Реальный - это понятно. Но он может не совпадать с адресом в незащищённой проге?

[jx]

Кстати, вот ещё один довод в пользу антипатча.
Если программа может сама менять свой код, то защиту памяти уже использовать будет нельзя. Тогда что остаётся? Ничего. Надежда только на антипатч.

[Admin]

Я не спорю, но через RegMon/FileMon это сделать проще всего (даже для того, кто не разбирается в тонкостях крякинга). А наша с вами задача - максимально усложнить этот процесс.

Хранение/получение "секретных" данных из реестра это само по себе ненадежно. Какой смысл "поддерживать" одни ненадежные методы другими методами, которые в сумме "продержаться" максимум 10 минут после запуска вашей программы? )
Подытожу:
1. Если вы собираетесь хранить триальные метки в реестре, то через полчаса после выхода вашего триала будет написан триал ресет, который превратит вашу программу в вечный триал.
2. Если вы собираетесь получать из реестра дату BIOS, то в качестве более надежной привязки к железу я бы порекомендовал использовать электронные ключи. Все остальное CPUID+MAC+BIOS - это не больше чем шаманство и при грамотном подходе все это обходится.

Критичные - никто. А если я не хочу вообще показывать что-либо посторонним глазам? К тому же, если крякер сможет локализовать критичный участок, то он уже будет знать с чем ему работать. А значит, какая-то часть его работы уже сделана. Криптование всего файла ещё более усложнит этот процесс.

Ну хорошо - вот у вас на диске лежит полностью покриптованный файл. Вопрос - в какой момент он будет раскриптовываться чтобы начать работать?

Кто этой отдельной темой владеет, то сможет. К тому же, если вы используете CRC, то есть методы, позволяющие подогнать CRC к нужному значению, исправив пару байт.

Поверьте - проверка файла на диске в общем случае ничего не дает, т.к.:
1. При вызове API, открывающих файл, вам могут подсунуть все что угодно в том числе и девственно чистый файл - и вы даже про это не узнаете )
2. Подгонку CRC файла как раз легче сделать нежели подгонку CRC памяти, т.к. при "невалидной" памяти (в результате подгонки CRC) ваша программа как минимум будет работать неправильно.
3. А те кто в теме вообще не будут заморачиваться с CRC файла - они сразу напишут так называемый лоадер, который будет патчить уже память процесса на лету.

Ну и пёс с ними, пускай перехватывают. Лишний гемор для крякера Smile

При разработке защиты никогда не нужно недооценивать противника. Все методы, которые вы предлагаете обходятся крякером любого уровня.

К тому же, повторюсь, наверняка можно приделать к проге какой-нибудь блок, который будет нейтрализировать работу протектра.

Я бы вам все-таки порекомендовал ознакомиться с описанием технологий, используемых в VMProtect. В частности - виртуализация. Я думаю у вас сразу пропадет множество вопросов и пожеланий по "усилению" защиты )

Т.е. протектор "вшивает" эту DLL-ку в прогу после защиты?

В процессе защиты протектор заменяет все вызовы ДЛЛ на свои внутренние вызовы, которые "зашиваются" прямо в защищаемую программу, поэтому никаких дополнительных модулей защищенной программе не требуется.

Реальный - это понятно. Но он может не совпадать с адресом в незащищённой проге?

Кто он? Я уже совершенно запутался про какие адреса вы спрашиваете, если вам уже все понятно и про защищенный и про незащищенный код.

[jx]

Хранение/получение "секретных" данных из реестра это само по себе ненадежно. Какой смысл "поддерживать" одни ненадежные методы другими методами, которые в сумме "продержаться" максимум 10 минут после запуска вашей программы? )
Подытожу:
1. Если вы собираетесь хранить триальные метки в реестре, то через полчаса после выхода вашего триала будет написан триал ресет, который превратит вашу программу в вечный триал.
2. Если вы собираетесь получать из реестра дату BIOS, то в качестве более надежной привязки к железу я бы порекомендовал использовать электронные ключи. Все остальное CPUID+MAC+BIOS - это не больше чем шаманство и при грамотном подходе все это обходится.

Не все такие крутые крякеры, что через 10 минут или полчаса напишут триал-ресет. А вот взять в руки FileMon и определить где собака зарыта может почти каждый, кто знает, что это за утилита.
Можно обращаться к интернету, можно - к датам различных файлов (рабочих, системных). Это, конечно, надёждее будет. Посоветуйте ещё что-нибудь, если не сложно. Но почему бы и реестр до кучи не задействовать?
Электронные ключи - слишком дорогое удовольствие. MAC, согласен, обходится легко, с BIOS'ом сложнее (если это не реестр), а вот CPUID обойти вряд ли получится.

Вообще, если рассуждать "это можно сломать вот так, это вот эдак, тут антиотладка не спасёт, антидамп тоже", то получается, что смысл есть только в виртуальных машинах, а всё остальное - сотресание воздуха. Очень много начинающих крякеров, ещё больше вообще не специалистов в этой области, которые хотят сломать прогу "для себя". А если ломают не сами, а заказывают кому-то, то с увеличением сложности взлома увеличивается и цена. И в какой-то момент выгоднее становится купить лицензию, чем заказать кряк
В теме про общие рекомендации вы писали: надо хранить результат проверки ключа в динамической переменной. Конечно, это лучше, чем в статической, но точно так же можно сделать дамп памяти и найти переменную-указатель на этот адрес, верно? Но это сложнее, это дополнительная работа! И здесь так же.

Ну хорошо - вот у вас на диске лежит полностью покриптованный файл. Вопрос - в какой момент он будет раскриптовываться чтобы начать работать?

Ну это уже вам виднее. Наверное, после первоначальных процедур (проверки дамперов, отладчиков, VMWare и т.д). Перед распаковкой, наверное.
Кстати, проверку VMWare тоже ведь обмануть можно, а она есть!

1. При вызове API, открывающих файл, вам могут подсунуть все что угодно в том числе и девственно чистый файл - и вы даже про это не узнаете )

Можно сделать вообще всё, что угодно. В сети лежат ломанные протекторы: и VMProtect, и WinLicense, и другие. Что с того?

При разработке защиты никогда не нужно недооценивать противника. Все методы, которые вы предлагаете обходятся крякером любого уровня.

Ну не знаю...

Я бы вам все-таки порекомендовал ознакомиться с описанием технологий, используемых в VMProtect. В частности - виртуализация. Я думаю у вас сразу пропадет множество вопросов и пожеланий по "усилению" защиты )

Хорошо. Где можно об этом почитать?

Кто он? Я уже совершенно запутался про какие адреса вы спрашиваете, если вам уже все понятно и про защищенный и про незащищенный код.

Допустим, моя прога защищена VMP. Произошло исключение, на экране появился адрес ошибки. Могу я этот адрес передать среде разработке и найти место ошибки? В каких случаях да, в каких - нет?

По поводу антипатча. Что делать проге, которая может сама менять свой код? Защиту памяти уже использовать будет нельзя?

[Admin]

Можно обращаться к интернету, можно - к датам различных файлов (рабочих, системных). Это, конечно, надёждее будет. Посоветуйте ещё что-нибудь, если не сложно. Но почему бы и реестр до кучи не задействовать?

Если вы планируете таким образом сделать триал, то на стороне клиента вообще ничего хранить нельзя, т.к. все что попало на компьютер пользователя может быть удалено тем же самым пользователем. Посмотрите в сторону ограничения функционала (например в незарегистрированной версии нельзя сделать сохранение файла или в программе, работающей с БД нельзя добавить больше N записей), либо если вы пишете графический редактор - накладывайте поверх картинки водяные знаки. Проявите фантазию - это будет гораздо надежней чем использовать изъезженную тему с триальными метками + бесконечные игры на перегонки с триал ресетами )
Если уж очень хочется использовать триальные метки - посмотрите в сторону NTFS потоков.

Электронные ключи - слишком дорогое удовольствие. MAC, согласен, обходится легко, с BIOS'ом сложнее (если это не реестр), а вот CPUID обойти вряд ли получится.

Если вы производите софт стоимостью от 1000$, то электронный ключ это оптимальный вариант. Для программ 20-50$ привязка к HWID это зло )

Ну это уже вам виднее. Наверное, после первоначальных процедур (проверки дамперов, отладчиков, VMWare и т.д). Перед распаковкой, наверное.

Ну а теперь мы запускаем программу и когда появляется главное окно программы - дампим память на диск. Затем полученный дамп отправляем в IDA на изучение. Чем ваш подход отличается от обычной распаковки если в результате в памяти мы имеем полностью распакованную/декриптованную программу?

Можно сделать вообще всё, что угодно. В сети лежат ломанные протекторы: и VMProtect, и WinLicense, и другие. Что с того?

"Неломаемых программ не существует" - с этим никто не спорит )

Хорошо. Где можно об этом почитать? Smile

В справке VMProtect

Допустим, моя прога защищена VMP. Произошло исключение, на экране появился адрес ошибки. Могу я этот адрес передать среде разработке и найти место ошибки? В каких случаях да, в каких - нет?

Я вам уже говорил, поторю еще раз:
1. Если ошибка произошла в завиртуализированном/промутированном коде, то адрес ошибки будет ДРУГИМ, чем в незащищенной программе.
2. Если ошибка произошла в НЕзавиртуализированном/промутированном коде, то адрес ошибки будет ТАКИМ ЖЕ как в незащищенной программе.

По поводу антипатча. Что делать проге, которая может сама менять свой код? Защиту памяти уже использовать будет нельзя?

Да - нельзя.

[jx]

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

А если я хочу выдавать ключ на определённый срок (на год, например)?

Если уж очень хочется использовать триальные метки - посмотрите в сторону NTFS потоков.

Тоже думаю об этом. Кстати, а FileMon'ом обращение к ним нельзя будет обнаружить?

Если вы производите софт стоимостью от 1000$, то электронный ключ это оптимальный вариант. Для программ 20-50$ привязка к HWID это зло )

А что тогда "добро" для программ за $25-$100 ?
И зачем тогда это (HWID) реализовано у вас?

Чем ваш подход отличается от обычной распаковки если в результате в памяти мы имеем полностью распакованную/декриптованную программу?

Тем, что эта программа в открытом виде хотя бы не лежит на самой-самой поверхности.

Я вам уже говорил, поторю еще раз:
1. Если ошибка произошла в завиртуализированном/промутированном коде, то адрес ошибки будет ДРУГИМ, чем в незащищенной программе.
2. Если ошибка произошла в НЕзавиртуализированном/промутированном коде, то адрес ошибки будет ТАКИМ ЖЕ как в незащищенной программе.

По п.2 - это будет даже в том случае, если перед НЕзащищённом кодом (в котором произошла ошибка) лежит защищённый? Т.е. защищённый код не будет "сдвигать" лежащий после него незащищённый код вперёд (размер инструкций после защиты же будет изменён)?

По поводу антипатча. Что делать проге, которая может сама менять свой код? Защиту памяти уже использовать будет нельзя?

Да - нельзя.

А что тогда можно будет сделать в этом случае для защиты? Антипатча же нет.

И ещё вопрос возник: планируете ли вы добавить возможность изменять "сложность" виртуализация/мутирования (как в Themida), чтобы можно было корректировать соотношение скорость/защищённость?

[Admin]

А если я хочу выдавать ключ на определённый срок (на год, например)?

Это решается обычными серийными номерами с ограничением по времени.

Тоже думаю об этом. Кстати, а FileMon'ом обращение к ним нельзя будет обнаружить?

Никогда не задавался этим вопросом - надо проверять )

А что тогда "добро" для программ за $25-$100 ? Smile

Вот как пример - тотже VMProtect (который к слову стоит намного больше чем 100$) не привязывается к HWID и его можно установить на любой компьютер без замены серийника.

И зачем тогда это (HWID) реализовано у вас?

Пользователи хотят видеть эту фичу )

Тем, что эта программа в открытом виде хотя бы не лежит на самой-самой поверхности.

Упакуйте программу - результат будет тотже самый.

По п.2 - это будет даже в том случае, если перед НЕзащищённом кодом (в котором произошла ошибка) лежит защищённый? Т.е. защищённый код не будет "сдвигать" лежащий после него незащищённый код вперёд (размер инструкций после защиты же будет изменён)?

Защищенный код никогда не сдвигает незащищенный код куда-либо. Это очень трудно сделать даже если бы очень хотелось )

А что тогда можно будет сделать в этом случае для защиты? Антипатча же нет.

Почему нет антипатча - "Защита памяти" это он и есть. В любом случае вы можете проверять целостность кодовых секций программы с помощью VMProtectIsValidImageCRC и в зависимости от полученного результата самостоятельно решать что делать дальше.

И ещё вопрос возник: планируете ли вы добавить возможность изменять "сложность" виртуализация/мутирования (как в Themida), чтобы можно было корректировать соотношение скорость/защищённость?

Уровень защищенности исземеняется с помощью типов компиляции - мутация/виртуализация/ультра, дополнительно для виртуализации/мутации можно включать/отключать индивидуальные опции защиты.

[jx]

Вот как пример - тотже VMProtect (который к слову стоит намного больше чем 100$) не привязывается к HWID и его можно установить на любой компьютер без замены серийника.

Вот именно. Скинулись с друзьями на 3-х, купили 1 версию и установили на 3 компа . А саппорт от имени одного из них.

Упакуйте программу - результат будет тотже самый.

А если она не упаковывается (разговор пошёл по второму кругу)? )))))

Почему нет антипатча - "Защита памяти" это он и есть. В любом случае вы можете проверять целостность кодовых секций программы с помощью VMProtectIsValidImageCRC и в зависимости от полученного результата самостоятельно решать что делать дальше.

Если мой код изменяет сам себя, то защиту памяти использовать будет нельзя (как и VMProtectIsValidImageCRC). И в этом случае нет механизмов защиты проги от патча. Так ведь?

Уровень защищенности исземеняется с помощью типов компиляции - мутация/виртуализация/ультра, дополнительно для виртуализации/мутации можно включать/отключать индивидуальные опции защиты.

Подскажите, где эти опции отображаются (я их сам не нашёл)? Если это Опции/Компиляция, то это же совсем другое. Мутация может быть простая, а может сложная с кучей мусора. То же самое и с виртуализацией.

Ещё вопрос: зачем нужны имена для маркеров?

[Admin]

А если она не упаковывается (разговор пошёл по второму кругу)? Smile)))))

Согласен, что вы задаете вопросы по кругу. Предлагаю остановиться и еще раз прочитать все мои ответы )

Если мой код изменяет сам себя, то защиту памяти использовать будет нельзя (как и VMProtectIsValidImageCRC). И в этом случае нет механизмов защиты проги от патча. Так ведь?

Если вы сами модифицируете код своей программы, то контроль целостности берете тоже на себя. Других вариантов я не вижу.

Подскажите, где эти опции отображаются (я их сам не нашёл)? Если это Опции/Компиляция, то это же совсем другое. Мутация может быть простая, а может сложная с кучей мусора. То же самое и с виртуализацией.

Мутация сейчас и так идет с кучей мусора. Виртуализация с кучей мусора - это ультра.

Ещё вопрос: зачем нужны имена для маркеров?

Чтобы их можно было легко находить в проекте.

[Admin]

P.S. Проверка CRC файла на диске будет добавлена в 2.04