Защита программного обеспечения. Часть 2
В прошлый раз мы остановились на программах с ограниченным сроком действия. Продолжим.
Третий способ - для Интернет-программ. С моей точки зрения он наиболее коварен. Во время работы программы можно запрашивать время и дату у так называемых time-серверов. Этим самым Вы не только защитите часы от перевода времени, но и сделаете доброе дело - подкорректируете работу пользователя по атомным часам:-).
Четвертый способ направлен против тех пользователей, которым не лень раз в месяц (к примеру) деинсталлировать программу и, инсталлировав ее снова, запустить на новый триальный срок.
Данные о днях использования можно хранить в системном реестре и не удалять их оттуда при деинсталляции. Альтернативой этому может быть создание неприметного файла в каталоге Windows, который будет выполнять собой роль счетчика и флага окончания trial-срока программы.
Пятый способ защиты при использовании счетчика запусков основан на храненни данных о количестве запусков. Опять же может использоваться реестр, файл и т.п.
Естественно, если взломщик увидит что-либо подобное "YourProgramRunsLeft=0", он уже будет знать, где копать. Поэтому эти строки (ключи в реестре) и их значения рекомендуется криптовать тем же банальным XOR'ом наряду со ВСЕМИ остальными строками (ключами в реестре), так или иначе относящимися к Вашей программе.
Шестой способ при использовании счетчика заключается в изменении даты времени какого-нибудь файла. Например, при истечении одного дня изменить дату файла readme.txt с 01.01.2000 на 01.01.1999 и т.д.
Методы взлома без модификации кода и защита от них
Очень действенный метод, который применяется в тех случаях, когда программа упакована, а распаковка не представляется возможной или удобной. В таком случае пишется утилита, которая запускает нужный файл и после его распаковки производит патч памяти (memorypatch).
Несмотря на кажущуюся сложность, защититься от взлома с использованием MemoryPatch'а довольно легко, а способов существует несколько:
1. Для написания патча нужно знать, где и что менять. Чтобы этому помешать, крайне актуально применение самомодифицирующегося кода. При снятии дампа самомодифицирующейся программы будет получен весьма неприятный результат.
2. Самовосстанавливающаяся программа, которая будет постоянно восстанавливать содержимое критических мест в памяти программы к их исходному значению в случае замены.
Кроме всего этого, модификация программы в памяти без внесения каких-либо изменений в ее код (физически) весьма интересна с правовой точки зрения. В данном случае обвинить человека, написавшего MemoryPatch, во взломе программы крайне сложно, если возможно вообще - так что, господа программеры, лучше защищайте свои программы.
Общие рекомендации по защите
1. Никогда не используйте название функций вроде "RegistrationFailed". У более-менее опытного взломщика уйдет не более 20 секунд на взлом программы. Или же, например, можно поместить в функцию с подобным названием немного кода из другой функции, чтобы при отключении "RegistrationFailed" программа выдавала неправильные результаты.
2. Избегайте простых nag-экранов или сообщений вроде "Your registration number is invalid". Простой nag-screen в виде MessageBoxA легко ловится и отключается. NAG-экран необходимо создавать в runtime или же от него отказаться.
3. Попробуйте асимметричные алгоритмы шифрования. Это точно отпугнет взломщика-новичка, а продвинутого заставит попотеть (и тоже отказаться в особых случаях;-))))).
4. Не спешите с выводом сообщений, что программа была взломана. Пусть она поработает день или два, прежде чем испортить взломщику настроение.
5. Используйте перекрестный подсчет контрольной суммы, например, между exe и dll файлом Вашей программы.
6. Пусть Ваша программа каждый раз вызывает одну из множества копий одной функции.
7. Помучайте взломщика вызовом множества промежуточных функций и шифрованием всего, что только возможно.
8. Пишите программы без реального кода некоторых функций, который пользователь получит лишь после регистрации.
9. Чаще выпускайте updates. Как же будет приятно узнать, что crack для версии 1.96 не подходит для версии 1.97 =).
10. Используйте криптостойкие криптоалгоритмы с большой длиной ключа. На размере этой программы это сильно не скажется, взлом программы сильно затруднит.
11. При генерации серийного номера используйте алгоритм подлиннее (этак килобайт на 10) арифметических действий. Это приведет в бешенство любого, кто попытается написать кейген, и поможет от bruteforce-атаки.
12. Не полагайтесь на существующие упаковщики/протекторы. Ничего особенного они не представляют и для продвинутого взломщика особой помехи не составят.
13. Почаще меняете код защиты в различных версиях. Тогда cracks с поиском кода (code search) не смогут убирать старую защиту в новой версии. Пример: программа The Bat!, которую уже на протяжении многих версий "кормят" универсальным codesearch-кряком и кейгеном для версии 1.35.
14. Заставьте взломщика поломать голову. Что он подумает, увидев кучу NOPов в вашей программе? Правильно - Self Modifying Code, чем сделает большую ошибку и проведет несколько часов, пытаясь найти несуществующий код, предназначенный для этих NOPов (к опытным взломщикам это не относится).
Вот вроде и закончились общие советы по защите программ. Если у Вас возникнут вопросы, напишите их на rotting@theds.com и Вам обязательно ответят.
В следующий раз я приведу примеры различного защитного кода на Assembler'е и Delphi.
"If it runs, it can be defeated" +ORC
"If it exists, it must be defeated" +Rotting Corpse
At your (protection) service, Олег Сквернюк
Третий способ - для Интернет-программ. С моей точки зрения он наиболее коварен. Во время работы программы можно запрашивать время и дату у так называемых time-серверов. Этим самым Вы не только защитите часы от перевода времени, но и сделаете доброе дело - подкорректируете работу пользователя по атомным часам:-).
Четвертый способ направлен против тех пользователей, которым не лень раз в месяц (к примеру) деинсталлировать программу и, инсталлировав ее снова, запустить на новый триальный срок.
Данные о днях использования можно хранить в системном реестре и не удалять их оттуда при деинсталляции. Альтернативой этому может быть создание неприметного файла в каталоге Windows, который будет выполнять собой роль счетчика и флага окончания trial-срока программы.
Пятый способ защиты при использовании счетчика запусков основан на храненни данных о количестве запусков. Опять же может использоваться реестр, файл и т.п.
Естественно, если взломщик увидит что-либо подобное "YourProgramRunsLeft=0", он уже будет знать, где копать. Поэтому эти строки (ключи в реестре) и их значения рекомендуется криптовать тем же банальным XOR'ом наряду со ВСЕМИ остальными строками (ключами в реестре), так или иначе относящимися к Вашей программе.
Шестой способ при использовании счетчика заключается в изменении даты времени какого-нибудь файла. Например, при истечении одного дня изменить дату файла readme.txt с 01.01.2000 на 01.01.1999 и т.д.
Методы взлома без модификации кода и защита от них
Очень действенный метод, который применяется в тех случаях, когда программа упакована, а распаковка не представляется возможной или удобной. В таком случае пишется утилита, которая запускает нужный файл и после его распаковки производит патч памяти (memorypatch).
Несмотря на кажущуюся сложность, защититься от взлома с использованием MemoryPatch'а довольно легко, а способов существует несколько:
1. Для написания патча нужно знать, где и что менять. Чтобы этому помешать, крайне актуально применение самомодифицирующегося кода. При снятии дампа самомодифицирующейся программы будет получен весьма неприятный результат.
2. Самовосстанавливающаяся программа, которая будет постоянно восстанавливать содержимое критических мест в памяти программы к их исходному значению в случае замены.
Кроме всего этого, модификация программы в памяти без внесения каких-либо изменений в ее код (физически) весьма интересна с правовой точки зрения. В данном случае обвинить человека, написавшего MemoryPatch, во взломе программы крайне сложно, если возможно вообще - так что, господа программеры, лучше защищайте свои программы.
Общие рекомендации по защите
1. Никогда не используйте название функций вроде "RegistrationFailed". У более-менее опытного взломщика уйдет не более 20 секунд на взлом программы. Или же, например, можно поместить в функцию с подобным названием немного кода из другой функции, чтобы при отключении "RegistrationFailed" программа выдавала неправильные результаты.
2. Избегайте простых nag-экранов или сообщений вроде "Your registration number is invalid". Простой nag-screen в виде MessageBoxA легко ловится и отключается. NAG-экран необходимо создавать в runtime или же от него отказаться.
3. Попробуйте асимметричные алгоритмы шифрования. Это точно отпугнет взломщика-новичка, а продвинутого заставит попотеть (и тоже отказаться в особых случаях;-))))).
4. Не спешите с выводом сообщений, что программа была взломана. Пусть она поработает день или два, прежде чем испортить взломщику настроение.
5. Используйте перекрестный подсчет контрольной суммы, например, между exe и dll файлом Вашей программы.
6. Пусть Ваша программа каждый раз вызывает одну из множества копий одной функции.
7. Помучайте взломщика вызовом множества промежуточных функций и шифрованием всего, что только возможно.
8. Пишите программы без реального кода некоторых функций, который пользователь получит лишь после регистрации.
9. Чаще выпускайте updates. Как же будет приятно узнать, что crack для версии 1.96 не подходит для версии 1.97 =).
10. Используйте криптостойкие криптоалгоритмы с большой длиной ключа. На размере этой программы это сильно не скажется, взлом программы сильно затруднит.
11. При генерации серийного номера используйте алгоритм подлиннее (этак килобайт на 10) арифметических действий. Это приведет в бешенство любого, кто попытается написать кейген, и поможет от bruteforce-атаки.
12. Не полагайтесь на существующие упаковщики/протекторы. Ничего особенного они не представляют и для продвинутого взломщика особой помехи не составят.
13. Почаще меняете код защиты в различных версиях. Тогда cracks с поиском кода (code search) не смогут убирать старую защиту в новой версии. Пример: программа The Bat!, которую уже на протяжении многих версий "кормят" универсальным codesearch-кряком и кейгеном для версии 1.35.
14. Заставьте взломщика поломать голову. Что он подумает, увидев кучу NOPов в вашей программе? Правильно - Self Modifying Code, чем сделает большую ошибку и проведет несколько часов, пытаясь найти несуществующий код, предназначенный для этих NOPов (к опытным взломщикам это не относится).
Вот вроде и закончились общие советы по защите программ. Если у Вас возникнут вопросы, напишите их на rotting@theds.com и Вам обязательно ответят.
В следующий раз я приведу примеры различного защитного кода на Assembler'е и Delphi.
"If it runs, it can be defeated" +ORC
"If it exists, it must be defeated" +Rotting Corpse
At your (protection) service, Олег Сквернюк
Компьютерная газета. Статья была опубликована в номере 51 за 2000 год в рубрике soft :: безопасность
