Защита ПО. Мифы и реальность
Защита ПО. Мифы и реальность
Обычно, покупая нужное ПО, никто из нас даже не задумывается о таком важном процессе, как его регистрация. А зачем? В любой подборке программ, которые можно найти на торговых точках, к каждой программе присутствует crack, keygen или просто регистрационный номер. Вбиваем этот номер, наслаждаемся функциональностью программы и тем самым лишаем автора ПО средств к существованию.
Как бы часто ни появлялись новые программы или их новые версии, в Интернете уже на следующий день можно найти "лекарство" от регистрации. И поэтому цель этой статьи — помочь авторам Shareware добавить головной боли тем людям, которые будут ломать их программы.
Часть 1. Мифы
Миф 1. Зачем писать свою защиту, если уже есть множество готовых? К множеству готовых защит вроде Asprotect, Armadillo, PE-Guard, Xtreme protector существует множество утилит, автоматизирующих процесс их снятия с вашего детища. И в результате их применения ваша программа остается буквально "голой".
Миф 2. У меня очень крутая защита, я сам ее писал. Вы в этом уверены? Даже если вы написали очень крутой алгоритм привязки к машине конечного пользователя вашей программы или применили асимметричное шифрование при генерации ключа, такие места в вашей программе, как проверка введенной регистрации или статуса программы, могут сводиться к следующему алгоритму:
...ПРОЦЕДУРА ПРОВЕРКИ РЕГИСТРАЦИИ
...РЕЗУЛЬТАТ процедуры=1?
...ЕСЛИ да — программа зарегистрирована, ИНАЧЕ — не зарегистрирована
Это и есть типичная ошибка многих — усложнить функцию (-ии) защиты до максимума, но забыть замаскировать результаты на выходе функции. Взлом программы с подобной схемой проверки регистрации займет у более-менее опытного крэкера времени не больше, чем нужно для того, чтобы выкурить одну сигарету.
Также довольно часто в коде защиты встречается такой код:
...ПРОЦЕДУРА ГЕНЕРАЦИИ КЛЮЧА
...ПОЛУЧЕННЫЙ ключ=ВВЕДЕННЫЙ ключ?
В данном случае регистрационный ключ можно просто взять из памяти PC, запустив программу под отладчиком.
Миф 3. У меня собственный упаковщик/протектор для своей программы. От него будет польза только в том случае, если вы используете нестандартный криптоалгоритм для шифровки, будете использовать "порчу" и восстановление таблицы импорта, примените новые антиотладочные приемы.
Примером более-менее стойкой защиты можно было бы назвать Armadillo. Навесная защита использует принцип отладчика-трейсера. Т.е. программа расшифровывается не полностью, и как только выполнение доходит до нерасшифрованного участка, возникает исключение-ошибка, которая перехватывается распаковщиком. После чего следует расшифровка этого участка, его выполнение и т.д. Но, как и на все навесные защиты, к нему тоже появилась утилита для автоматической распаковки.
Миф 4. Моя программа стоит копейки, никто ее ломать не будет. Ошибаетесь. Если уж так получилось, что ваша программа имеет определенную популярность, то и крэки к ней будут выходить своевременно.
Миф 5. Я пользуюсь черным списком пиратских ключей (key blacklist). Не только вы его используете. Процедура регистрации популярной программы The Bat не менялась уже очень давно. Добавлялись только пиратские ключи в blacklist, что и привело к появлению патча, который убирает проверку ключа и позволяет вводить даже те, которые есть в blacklist'e.
Можно привести еще множество подобных убеждений авторов, но это заняло бы слишком много времени:).
Часть 2. Общие советы по защите
1. Старайтесь не держать в открытом виде данные, имеющие отношение к процедуре регистрации программы. Шифруйте строки вроде Wrong serial number или Registration succesful. Даже обычная XOR-шифровка скроет от некоторых пытливых глаз эти строки в коде программы.
2. Не концентрируйте всю процедуру регистрации в одном месте. Гораздо более правильным будет разбросать ее по программе, тем самым затрудняя ее исследование.
3. Старайтесь не использовать мгновенного вывода результата регистрации программы. После ввода рег-данных сохраните их, а проверяйте при запуске программы или в процессе ее работы.
4. Не делайте возврат значений из процедуры проверки регистрации однозначным (например: 0 или 1)...
5. Попробуйте зашифровать код участков программы, недоступных в незарегистрированной версии, при помощи проверки регистрационных данных. При правильном вводе ключа он будет использоваться для получения определенного значения, которое будет являться ключом для расшифровки участка кода. Таким образом без правильного ключа незарегистрированные опции останутся недоступны.
6. Не храните введенные регистрационные данные в открытом виде и в доступных местах. Обязательно шифруйте их, сохраняйте их в коде программы, вшифровывайте их в файлы операционный системы.
7. Примените проверку контрольной суммы (CRC) определенных процедур регистрации для проверки на изменение кода этих процедур.
8. Если вы используете навесные защиты с собственным API для использования в коде программы — не бойтесь добавить немного своего кода для дополнительных проверок.
9. Реализуйте процедуры самодиагностики кода программы и незаметной отправки результатов к себе (например, на ящик электронной почты). При грамотном применении это позволит вам всегда быть в курсе того, какой участок защиты вашей программы наименее стойкий против взлома.
10. Не называйте функции регистрации (особенно если они находятся в DLL-файле) именами вроде GetRegistra-tionStatus или SetRegistered. При дизассемблировании это будет лишней подсказкой крэкеру, где начать "копать" процедуру регистрации.
11. Используйте самомодифицирующийся код или напишите виртуальную машину для нужд процедуры регистрации. В определенных случаях при правильном применении это заставит некоторых крэкеров даже отказаться от идеи взлома вашей программы.
12. Используйте нестандартные приемы "обламывания" работающего отладчика, вроде вызова и обработки исключения, перезаписи управляющих регистров и т.д.
13. Постарайтесь найти замену стандартным API для работы с файлами/реестром при чтении/сохранении регистрационных данных. Хорошей альтернативой будет использование Ring0 (высшего уровня привилегий) и использующихся на нем функций для реализации чтения/сохранения данных.
14. Если вы пишете навесную защиту для своих программ, то хорошим подспорьем будут материалы по поли- и метаморфизму с www. wasm.ru. К слову, упаковщик-протектор Asprotect от Алексея Солодовникова использует модифицированный полиморфный код, позаимствованный у компьютерного вируса.
Продолжение следует.
Олег Сквернюк
Обычно, покупая нужное ПО, никто из нас даже не задумывается о таком важном процессе, как его регистрация. А зачем? В любой подборке программ, которые можно найти на торговых точках, к каждой программе присутствует crack, keygen или просто регистрационный номер. Вбиваем этот номер, наслаждаемся функциональностью программы и тем самым лишаем автора ПО средств к существованию.
Как бы часто ни появлялись новые программы или их новые версии, в Интернете уже на следующий день можно найти "лекарство" от регистрации. И поэтому цель этой статьи — помочь авторам Shareware добавить головной боли тем людям, которые будут ломать их программы.
Часть 1. Мифы
Миф 1. Зачем писать свою защиту, если уже есть множество готовых? К множеству готовых защит вроде Asprotect, Armadillo, PE-Guard, Xtreme protector существует множество утилит, автоматизирующих процесс их снятия с вашего детища. И в результате их применения ваша программа остается буквально "голой".
Миф 2. У меня очень крутая защита, я сам ее писал. Вы в этом уверены? Даже если вы написали очень крутой алгоритм привязки к машине конечного пользователя вашей программы или применили асимметричное шифрование при генерации ключа, такие места в вашей программе, как проверка введенной регистрации или статуса программы, могут сводиться к следующему алгоритму:
...ПРОЦЕДУРА ПРОВЕРКИ РЕГИСТРАЦИИ
...РЕЗУЛЬТАТ процедуры=1?
...ЕСЛИ да — программа зарегистрирована, ИНАЧЕ — не зарегистрирована
Это и есть типичная ошибка многих — усложнить функцию (-ии) защиты до максимума, но забыть замаскировать результаты на выходе функции. Взлом программы с подобной схемой проверки регистрации займет у более-менее опытного крэкера времени не больше, чем нужно для того, чтобы выкурить одну сигарету.
Также довольно часто в коде защиты встречается такой код:
...ПРОЦЕДУРА ГЕНЕРАЦИИ КЛЮЧА
...ПОЛУЧЕННЫЙ ключ=ВВЕДЕННЫЙ ключ?
В данном случае регистрационный ключ можно просто взять из памяти PC, запустив программу под отладчиком.
Миф 3. У меня собственный упаковщик/протектор для своей программы. От него будет польза только в том случае, если вы используете нестандартный криптоалгоритм для шифровки, будете использовать "порчу" и восстановление таблицы импорта, примените новые антиотладочные приемы.
Примером более-менее стойкой защиты можно было бы назвать Armadillo. Навесная защита использует принцип отладчика-трейсера. Т.е. программа расшифровывается не полностью, и как только выполнение доходит до нерасшифрованного участка, возникает исключение-ошибка, которая перехватывается распаковщиком. После чего следует расшифровка этого участка, его выполнение и т.д. Но, как и на все навесные защиты, к нему тоже появилась утилита для автоматической распаковки.
Миф 4. Моя программа стоит копейки, никто ее ломать не будет. Ошибаетесь. Если уж так получилось, что ваша программа имеет определенную популярность, то и крэки к ней будут выходить своевременно.
Миф 5. Я пользуюсь черным списком пиратских ключей (key blacklist). Не только вы его используете. Процедура регистрации популярной программы The Bat не менялась уже очень давно. Добавлялись только пиратские ключи в blacklist, что и привело к появлению патча, который убирает проверку ключа и позволяет вводить даже те, которые есть в blacklist'e.
Можно привести еще множество подобных убеждений авторов, но это заняло бы слишком много времени:).
Часть 2. Общие советы по защите
1. Старайтесь не держать в открытом виде данные, имеющие отношение к процедуре регистрации программы. Шифруйте строки вроде Wrong serial number или Registration succesful. Даже обычная XOR-шифровка скроет от некоторых пытливых глаз эти строки в коде программы.
2. Не концентрируйте всю процедуру регистрации в одном месте. Гораздо более правильным будет разбросать ее по программе, тем самым затрудняя ее исследование.
3. Старайтесь не использовать мгновенного вывода результата регистрации программы. После ввода рег-данных сохраните их, а проверяйте при запуске программы или в процессе ее работы.
4. Не делайте возврат значений из процедуры проверки регистрации однозначным (например: 0 или 1)...
5. Попробуйте зашифровать код участков программы, недоступных в незарегистрированной версии, при помощи проверки регистрационных данных. При правильном вводе ключа он будет использоваться для получения определенного значения, которое будет являться ключом для расшифровки участка кода. Таким образом без правильного ключа незарегистрированные опции останутся недоступны.
6. Не храните введенные регистрационные данные в открытом виде и в доступных местах. Обязательно шифруйте их, сохраняйте их в коде программы, вшифровывайте их в файлы операционный системы.
7. Примените проверку контрольной суммы (CRC) определенных процедур регистрации для проверки на изменение кода этих процедур.
8. Если вы используете навесные защиты с собственным API для использования в коде программы — не бойтесь добавить немного своего кода для дополнительных проверок.
9. Реализуйте процедуры самодиагностики кода программы и незаметной отправки результатов к себе (например, на ящик электронной почты). При грамотном применении это позволит вам всегда быть в курсе того, какой участок защиты вашей программы наименее стойкий против взлома.
10. Не называйте функции регистрации (особенно если они находятся в DLL-файле) именами вроде GetRegistra-tionStatus или SetRegistered. При дизассемблировании это будет лишней подсказкой крэкеру, где начать "копать" процедуру регистрации.
11. Используйте самомодифицирующийся код или напишите виртуальную машину для нужд процедуры регистрации. В определенных случаях при правильном применении это заставит некоторых крэкеров даже отказаться от идеи взлома вашей программы.
12. Используйте нестандартные приемы "обламывания" работающего отладчика, вроде вызова и обработки исключения, перезаписи управляющих регистров и т.д.
13. Постарайтесь найти замену стандартным API для работы с файлами/реестром при чтении/сохранении регистрационных данных. Хорошей альтернативой будет использование Ring0 (высшего уровня привилегий) и использующихся на нем функций для реализации чтения/сохранения данных.
14. Если вы пишете навесную защиту для своих программ, то хорошим подспорьем будут материалы по поли- и метаморфизму с www. wasm.ru. К слову, упаковщик-протектор Asprotect от Алексея Солодовникова использует модифицированный полиморфный код, позаимствованный у компьютерного вируса.
Продолжение следует.
Олег Сквернюк
Компьютерная газета. Статья была опубликована в номере 20 за 2003 год в рубрике soft :: безопасность
