2.2.4 Угрозы программному обеспечению. Защита по. Методы исследования по. Противодействие взлому программного обеспечения.
Основные угрозы ПО - незаконное копирование и взлом программ с целью использования отдельных фрагментов и алгоритмов. Необходимость защиты ПО обусловдено рядом проблем, среди которых можно выделить:
Незаконное использование алгоритмов, являющихся интеллектуальной собственностью автора.
Незаконное использование ПО (кража и копирование)
Незаконная модификация ПО с целью внедрения вредоносных программ
Незаконное распространение и сбыт ПО (пиратство)
Существующие системы защиты ПО можно классифицировать по признакам:
Метод установки
Использование механической защиты
Принцип функционирования
Системы защиты ПО по методу установки делятся на:
Системы установки на скомпилированные модули ПО
Системы, встраиваемые в исходный код ПО до компилирования
Комбинированные
Язык низкого уровня (Assembler) обращается непосредственно к интерфейсам. Язык верхнего уровня (Basic, Pascal) – обращается непосредственно к командам, но не показывает к каким ячейкам памяти и т.д. он обращается. Компиляция – перевод из исходного кода программы в машинный язык.
Скриптовые языки не компилируются, но там есть интерпретатор (который построчно выполняет команды)
Системы первого типа наиболее удобны для производителя ПО, так как можно легко защитить любое готовое и оттестированное ПО. Стойкость таких систем достаточно низка. Системы второго типа неудобны для производителя ПО, поскольку возникает необходимость обучить персонал работы с программным интерфейсом (API) системы защиты с вытекающими отсюда денежными и временными затратами. Кроме того, усложняется процесс тестирования ПО и снижается его надёжность. Наиболее эффективными являются комбинированные системы защиты.
По используемым механизмам СЗ можно классифицировать на:
Системы, использующие сложные логические механизмы.
Системы, использующие шифрование защищаемого ПО.
Комбинированные системы.
Системы первого типа используют различные методы и приёмы, ориентированные на затруднение дизассемблирования, отладки и анализа системы защиты и защищаемого ПО. Этот тип СЗ наименее стоек к атакам.
Более стойкими являются системы второго типа. Для деактивизации таких защит необходимо определение ключа для шифрования ПО.
Самими стойкими к атакам являются комбинированные системы.
Для защиты ПО используются ряд методов, такие как:
Алгоритмы запутывания – используются хаотические переходы в разные части кода, внедрение ложных процедур (пустышек), холостые циклы, искажение реальных параметров процедур ПО, разброс участков кода по разным областям памяти.
Алгоритмы мутации – создаются таблицы соответствия операндов – синонимов и замена их друг на друга при каждом запуске программы по определённой схеме или случайным образом, случайные изменения структуры программ.
Алгоритмы компрессии данных – программа упаковывается, а затем распаковывается по мере выполнения.
Алгоритмы шифрации данных – программа зашифровывается, а затем расшифровывается по мере выполнения.
Вычисление сложных математических выражений в процессе обработки механизмов защиты – элементы логики защиты зависит от результата вычисления значения какой либо формулы или группы формул.
Методы затруднения дизассемблирования - используются различные приёмы для предотвращения дизассемблирования в пакетном режиме.
Методы затруднения отладки – используются различные приёмы, направленные на усложнение отладки программ.
Эмуляция процессоров и операционных систем – создаётся виртуальный процесс и/или операционная система (не обязательно реально существующая) и программа переводчик из системы команд IBM в систему команд созданного процессора и/или ОС. После такого перевода ПО может выполняться только при помощи эмулятора. Это резко затрудняет исследование алгоритма ПО.
Нестандартные методы работы с аппаратным обеспечением – модули системы защиты обращаются к аппаратуре ЭВМ, минуя процедуры ОС, и используют малоизвестные или недокументированные её возможности.
По принципу функционирования СЗ можно подразделить на:
упаковщики/шифраторы;
СЗ от несанкционированного копирования (НСК);
СЗ от несанкционированного доступа (НСД).
Упаковщики/шифраторы
Изначально основной целью упаковщиков/шифраторов являлось уменьшение объёма исполняемого модуля на диске без ущерба для функциональности программы. Позднее на первый план вышла цель – защита ПО от анализа его алгоритмов и его несанкционированной модификации.
Положительные стороны:
В рамках периода безопасного использования данной системы обеспечивает высокий уровень защиты ПО от анализа его алгоритма
Методы упаковки/шифрации намного увеличивают стойкость СЗ других типов.
Отрицательные стороны:
Практически все применяемые методы замедляют выполнение кода ПО
Упаковка/Шифрование кода ПО вызывают затруднения при обновлении и исправлении ошибок.
Возможно повышение аппаратно-программных требований ПО
В чистом виде данные системы не применимы для авторизации использования ПО.
Эти системы применимы лишь к продуктам небольшого объёма (до 1 Мегабайта).
Данный класс систем уязвим, так как в конечном итоге программный код распаковывается/расшифровывается для выполнения.
Обладают небольшим сроком безопасного использования (см пункт 4)
Упаковка/шифрация вступает в конфликт с современными антивирусными системами, запрещающим самомодифицирующийся код.
СЗ от НСК осуществляют привязку ПО к дистрибутивному носителю. Данный вид защиты основан на глубоком изучении работы контроллеров накопителей, их физических показателей, нестандартных режимов разбивки, чтения/записи и т.п. При этом на физическом уровне создаётся дистрибутивный носитель, обладающий неповторимыми свойствами (обычно это достигается нестандартной разметкой носителя информации и/или записью на него дополнительной информации, пароля или метки) На программном уровне создаётся модуль, настроенный на идентификацию и аутентификацию носителя по его уникальным свойствам. При этом возможно применение приёмов, используемых упаковщиками/шифраторами.
Плюсы:
Затруднение нелегального копирования и распространения ПО;
Защита прав пользователя на приобретённое ПО.
Минусы:
Большая трудоёмкость реализации СЗ;
Замедление продаж из-за необходимости физической передачи дистрибутивного носителя информации;
Повышение системных требований из-за защиты;
Снижение отказоустойчивости ПО;
Несовместимость защиты и аппаратуры пользователя;
На время работы ПО занимается накопитель;
Угроза кражи защищённого носителя.
СЗ от НСД осуществляют предварительную или периодическую идентификацию пользователя ПО или его компьютерной системы путём запроса дополнительной информации. К системам данного типа можно отнести:
Система парольной защиты ПО.
Системы “привязки” ПО к компьютеру пользователя.
Системы с ключевыми дисками.
Программно-аппаратные системы с электронными ключами.
Системы парольной защиты – этот класс СЗПО на данный момент самый распространённый. Основной принцип работы заключается в идентификации и аутентификации пользователя ПО путём запроса дополнительных данных. Это могут название фильма и Ф.И.О. пользователя и его пароль либо только пароль/регистрационный код.
Слабым звеном является блок проверки правильности введённого пароля/кода, потому что он является составной частью программы.
Также для всех систем парольной защиты существует угроза перехвата пароля при его вводе авторизованного пользователя. Кроме того в большинстве СЗПО эта функция используется всего один раз - обычно при регистрации или установки ПО, затем система защиты просто отключается. Это создаёт реальную угрозу НСД при незаконном копировании ПО.
Плюсы:
Надёжная защита от злоумышленника непрофессионала.
Минимальные неудобства для пользователя.
Возможность передачи пароля/кода по сети.
Отсутствие конфликтов с системным и прикладным ПО и аппаратным обеспечением.
Простота реализации и применения
Низкая стоимости.
Минусы:
Низкая стойкость большинства систем защиты данного типа.
Пользователю необходимо запоминать пароль/код.
Система привязки ПО - при установке ПО на ПК пользователя осуществляет поиск уникальных признаков компьютерной системы либо они устанавливаются самой системой защиты. После этого модуль защиты в самом ПО настраивается на поиск и идентификацию данных признаков, по которым в дальнейшем определяется – авторизовано или неавторизованно использование ПО.
Плюсы:
Не требуется добавочных аппаратных средств для работы защиты;
Затруднение НСД к скопированному ПО;
Простота применения;
Невидимость СЗПО для пользователя.
Минусы:
Ложные срабатывание СЗПО при любых изменениях параметров ПК.
Низкая стойкость при доступе злоумышленника к ПК пользователя.
Возможность конфликтов с системным ПО.
СЗПО с электронными ключами в последнее время обретает всё большую популярность. Под программно-аппаратными средствами защиты в данном случае понимаются средства, основанные на использовании электронных ключей.
Электронный ключ – аппаратная часть системы защиты, представляющая собой плату с микросхемами памяти и в некоторых случаях микропроцессором, помещённую в корпус и предназначенную для установки в один из стандартных портов ПК (COM, USB, LPT, PCMCIA) или слот расширения материнской платы.
Электронные ключи по архитектуре можно разделить на:
Ключи с памятью (без микропроцессора)
Ключи с микропроцессором (и памятью)
Наименее стойкими являются системы первого типа. Наиболее стойкими – второго типа. Такие комплексы содержат в аппаратной части не только ключ расшифрования но и блоки шифрования/расшифрования данных. Таким образом при работе защиты в ключ поступают блоки зашифрованных данные, а принимаются расшифрованные данные.
Плюсы:
Значительное затруднение нелегального распространения и использования ПО.
Избавление производителя ПО от разработки собственной системы защиты.
Высокая автоматизация процесса защиты ПО.
Наличие API-системы для более глубокой защиты.
Возможность лёгкого создания демо-версий.
Достаточно большой выбор таких систем на рынке.
Минусы:
Затруднение разработки и отладки ПО из-за ограничений со стороны СЗ.
Дополнительные затраты на приобретение СЗ и обучение персонала.
Замедление продаж из-за необходимости физической передачи аппаратной части.
Повышение системных требований из-за защиты.
Снижение отказоустойчивости ПО.
Несовместимость систем защиты и системного или прикладного ПО пользователя.
Несовместимость защиты и аппаратуры пользователя.
Ограничение из-за несовместимости электронных ключей различных фирм.
Снижение расширяемости компьютерной системы.
Затруднение или невозможность использования защитного ПО в КПК и ноутбуках.
Наличие у аппаратной части веса и размеров
Угроза кражи аппаратного ключа.
Защита информационных процессов в компилируемых системах
Средства защиты ПО с ключевыми дисками.
В настоящий момент этот тип систем защиты мало распространён, ввиду его морального устаревания. СЗПО этого типа во многом аналогичны системам с электронными ключами, но здесь критическая информация хранится на специальном, ключевом, носителе. Так же много общего есть и с системами защиты от копирования, так как используются те же методы работы с ключевым носителем.
Основной угрозой для таких СЗПО является перехват считывания критической информации, а так же незаконное копирование ключевого носителя.
Положительные стороны:
Значительное затруднение нелегального распространения и использования ПО;
Избавление производителя ПО от разработки собственной системы защиты;
Высокая автоматизация процесса защиты ПО;
Возможность легкого создания демо-версий;
Отрицательные стороны:
Затруднение разработки и отладки ПО из-за ограничений со стороны СЗ;
Дополнительные затраты на приобретение системы защиты и обучение персонала;
Замедление продаж из-за необходимости физической передачи носителя;
Повышение системных требований из-за защиты;
Снижение отказоустойчивости ПО;
Несовместимость систем защиты и системного или прикладного ПО пользователя;
Несовместимость защиты и аппаратуры пользователя;
Снижение расширяемости компьютерной системы;
Затруднения или невозможность использования защищенного ПО в переносных и блокнотных ПК;
Угроза кражи ключевого носителя
Существуют следующие показатели применимости ПО:
Технические. Соответствие СЗПО функциональным требованиям производителя ПО и требованиям по стойкости, системные требования ПО и системные требования СЗПО, объём ПО и объём СЗПО, функциональная направленность ПО, наличие и тип СЗ у аналогов ПО - конкурентов.
Экономические. Соотношение потерь от пиратства и общего объёма прибыли, соотношение потерь от пиратства и стоимости СЗПО и её внедрения, соотношение стоимости ПО и стоимости СЗПО, соответствие стоимости СЗПО и её внедрения поставленным целям.
Организационные. Распространённость и популярность ПО, условия распространения и использования ПО, уникальность ПО, наличие угроз, вероятность превращения пользователя в злоумышленника, роль документации и поддержки при использовании ПО.
Критерии оценки:
Защита как таковая. Затруднение нелегального копирования, затруднение нелегального доступа, защита от мониторинга, отсутствие логических брешей и ошибок в реализации системы.
Стойкость к исследованию/взлому. Применение стандартных механизмов, новые/нестандартные механизмы
Отказоустойчивость (надёжность). Вероятность отказа защиты (НСД), время наработки на отказ, вероятность отказа программы защиты (крах), время наработки на отказ, частота ложных срабатываний.
Независимость от конкретных реализаций ОС. Использование недокументированных возможностей, "вирусных" технологий и "дыр" ОС
Совместимость. Отсутствие конфликтов с системным ПО, отсутствие конфликтов с прикладным ПО, отсутствие конфликтов с существующим АО, максимальная совместимость с будущим АО и ПО.
Неудобства для конечного пользователя ПО. Необходимость и сложность дополнительной настройки системы защиты, доступность документации, доступность информации об обновлении модулей системы защиты из-за ошибок/несовместимости/нестойкости, доступность сервисных пакетов, безопасность сетевой передачи пароля/ключа, задержка из-за физической передачи пароля/ключа, нарушения прав потребителя.
Побочные эффекты. Перегрузка траффика, отказ в обслуживании, замедление работы защищаемого ПО, замедление работы ОС, захват системных ресурсов, перегрузка ОЗУ, нарушение стабильности ОС.
Стоимость. Стоимость/эффективность, стоимость/цена защищаемого ПО, стоимость/ликвидированные убытки.
Доброкачественность. Правдивая реклама, доступность результатов независимой экспертизы, доступность информации о побочных эффектах, полная информация о СЗ для конечного пользователя.
Современный взломщик имеет в своем арсенале набор разнообразных утилит для взлома. Их можно подразделить на несколько категорий:
Отладчики. Позволяют прерывать выполнение программы при достижении заранее заданных условий, производить пошаговое выполнение программы, изменять содержимое памяти и регистров и т.п. Наиболее популярным, удобным и мощным является отладчик SoftICE, который при достаточно примитивном интерфейсе обладает приличными возможностями и весьма стабильно работает.
Дизассемблеры. Производят дизассемблирование программы для дальнейшего изучения полученного кода. Один из наиболее мощных и популярных - IDA. От дизассемблера достаточно легко защититься - зашифровать или заархивировать программу. Тогда дизассемблируется только архиватор или кодировщик. Однако тот-же IDA имеет мощный встроенный скриптовой язык, позволяющий производить расшифровку программы
Средства мониторинга. Это набор утилит, отслеживающих операции с файлами, реестром, портами и сетью.
Средства пассивного анализа программы. Показывают разную информацию о программе - извлекают ресурсы, показывают связи, используемые библиотеки. Классический пример - утилита DEPENDS.EXE из комплекта Visual Studio. Она показывает, какие библиотеки используются программой и какие функции импортируются.
Прочие утилиты. Их великое множество (можно найти на диске типа "Все для хакера", причем в изобилии). Это разнообразные редакторы, анализаторы.
Основы построения защиты
Ввод регистрационного кода. Ввод пароля или регистрационного номера является ответственным делом - взломщик постарается отловить адрес памяти, в который будет записан пароль. Затем на обращение по этому адресу ставится точка останова (команда BPM в SoftICE), что позволяет поймать начало процедуры проверки регистрационного кода.
При срабатывании этой точки останова взломщик попадат в анализатор введенного значения и либо делат генератор регистрационных ключей, либо ломает процедуру проверки.
Рассмотрим несколько решений, которые могут затруднить взлом на этом этапе:
Старайтесь как можно меньше применять стандартные функции (особенно API-шные) и компоненты VCL. Современные дизассемблеры умеют распознавать стандартные процедуры высокоуровневых языков, а API - вообще отдельный разговор - SoftICE обладает изумительной возможностью - загружать символьные имена для любых указанных библиотек - отладка резко упрощается, т.к. мы видим имена вызываемых функций и можем ставить точки останова на вызов функций по их имени.
Применяйте нестандартный способ ввода пароля. Наипростейший путь - написать свой визуальный компонент для ввода регистрационного кода. Он конечно должен будет обрабатывать события от клавиатуры, но момент считывания кода нельзя поймать избитыми методами. Это уже что-то, но есть второй способ взлома, основанный на поиске введенного кода в памяти. Для этого в SoftICE есть удобная команда "S стартовый адрес L длина 'образец'" , которая позволяет найти введенное значение в памяти.
Не храните введенный код в одном месте. Если введенный код или регистрационный номер хранить в одном месте, то достаточно легко установить точку останова на зону памяти, в которой замещен введенный код.
Не храните введенный код открытым текстом. Итак, что же следует сделать. Для начала необходимо завести в программе 5-10 переменных типа STRING и после ввода кода переписать введенное значение в них. Делать это лучше всего не в одном месте, а распределить по программе. Таким образом, поиск даст кучу адресов, по которым будет находиться введенный код.
Ни в коем случае не анализируйте код сразу после его ввода. Чем дальше ввод кода от его анализа, тем лучше. Самое разумное - после ввода кода поблагодарить пользователя за сотрудничество и сообщить, что со временем будет выполнена регистрация программы. А анализ кода произвести, например, через 1-2 минуты в совершенно другом месте программы.
Не проверяйте код только в одном месте и не пишите для проверки функцию. Достаточно найти и отключить эту проверку, и защита взломана. Если проверок несколько, они разные и распределены по программе, то взлом затрудняется.
Не проверяйте пароль одним алгоритмом. Рекомендуется разработать 2-3 алгоритма проверки, например 1-2 цифры должны делиться на 3, а 3-7 наложенные по какому-либо алгоритму на имя пользователя должны дать в сумме 4. Эти две проверки осуществляем в различных местах с достаточно большим временным разносом - взломав первый метод хакер не будет догадываться о существовании еще нескольких, которые проявятся со временем.
Ни в коем случае не предпринимайте никаких действий после проверки. В большинстве программ некая процедура проверяет код и при несовпадении предпринимает активные действия, которые буквально кричат "вот она где защита !!". Наилучший шаг - выждать день-два (или хотя бы минут 15). Причем все действия по проверке следует как можно дальше отнести от выдачи сообщений и прочих действий, предпринимаемых при обнаружении неправильного кода.
Отвлекающие маневры. Кроме реальных функций проверки кода очень неплохо сделать пару бутафорских - они будут вызываться после ввода кода, проводить активные манипуляции с введенным значением, выдавать сообщения о некорректности введенного кода ... - т.е. отвлекать внимание от реальной проверки.
Не храните результатов проверки в переменной и не используйте ее для явного ограничения функций незарегистрированной программы.
Не храните результатов проверки на диске или в реестре.
Ничего не проверяйте сразу при запуске приложения или сразу после считывания сохраненного имени или кода. Помните, что считывание кода и его ввод в окне регистрации идентичны по мерам защиты - дублирование в разных областях памяти, шифрование.
Не определяйте дату и время стандартными способом !! Придумайте что-нибудь оригинальное.
Не стоит хранить что-либо секретное в файлах или реестре. Работа с файлами или реестром может быть детально запротоколирована и проанализирована, и все тайное станет явным.
Не храните ничего важного открытым текстом, особенно сообщения типа "Это незарегистрированная версия ...", "Введенный пароль не верен ...". Они для хакера - как для быка красная тряпка, и действительно - находим такое сообщение, ставим точку останова на обращение к участку памяти с этим сообщением и получаем возможность поймать момент выдачи этого сообщения.
Общие советы по защите программ
CRC - контрольные суммы. Любой файл, строку или блок данных можно защитить контрольной суммой, которую затем можно рассчитать и сравнить с эталоном. При сравнении с эталоном конечно следует весть осторожно - см. первые 11 советов. Итак, совет 12. Защищайте программы и данные контрольными суммами. Это поможет не только от взлома, но и защитит программы от вируса или внедрения троянца.
Применяйте шифровку программ и данных. Очень неплохо сжать программу и данные. Я, например, разработал свой собственный архиватор - RAR-у и ZIP-у он конкуренции не составит, но сжатые им данные разжать очень непросто, придется изрядно повозиться. Да и изменить их проблематично - придется разжать, изменить и сжать.
Отлов пошаговой отладки программы. Существует много способов, я в свое время провел целое исследование этого вопроса под DOS, насобирал и придумал не менее 20 методов, но они мало приемлемы под Windows. Самый простой и надежный способ - таймер. При работе программы периодически фиксируем системное время и рассчитываем время работы фрагментов кода между ними. И если 200-400 команд процессора работают 2-3 минуты, то тут есть над чем задуматься.
Рекомендации для создания меток для организации ограничения по времени.
Защита "ограничение времени работы" состоит в том, что программа каким образом фиксирует момент своего первого запуска и работает установленное время (обычно 20-30 дней). После истечения этого срока программа отказывается запускаться. Как проверить текущую дату я уже где-то тут писал - нестандартным способом, например по дате на файлах реестра или свежесозданном своем файле. Весь фокус в другом - как зафиксировать на компьютере дату первого запуска (естественно так, чтобы изничтожение программы и ее повторная установка не давали эффекта). Использование "секретных" файлов в системных папках или изменения в существующих файлах легко отловить при помощи FILEMON. Реестр то же отпадает из-за REGMON. Прочие методы (типа записи в ВООТ сектор ...) тоже неприемлемы - не те времена, по Windows все это не пройдет. Наиболее оригинально прошить дату в саму программу и постоянно обновлять ее на своем сайте (естественно, автоматически). Таким образом отсчет неявно идет от момента скачивания программы с сайта. Есть тут правда и минус - после завершения срока можно повторно скачать эту программу и получить еще 15-20 дней. С другой стороны это оригинально - пользователю рано или поздно надоест скачивать эту программу и он или откажется от нее, или купит. Но при этом стоит помнить, что программу можно скачать несколько раз и сравнить варианты, выявив, где лежит дата. Поэтому стоит позаботиться о том, чтобы изменился почти весь файл (например, изменить пару опций компилятора)
Рекомендации по формированию регистрационных кодов
Формирование кодов может вестись по следующим основным направлениям:
Жестко фиксированные коды, прошитые в программу. Их обычно немного и их огласка сводит защиту к нулю.
Некий алгоритм проверки кода. Немного лучше первого, но лишь немного. Возьмите за пример код Windows - его знает любой пользователь
Алгоритм проверки кода, использующий имя пользователя. Очевидно, что для каждого имени будет уникальный номер (или номера - их может быть несколько, в зависимости от алгоритма). Это уже лучше, но нелегальное распространение держится на эгоизме зарегистрированных пользователей - ничто не мешает им предать имя/пароль огласке, но тогда хотя бы можно вычислить виновника и заблокировать его код
Алгоритм проверки кода, использующий имя пользователя и некоторые уникальные или динамически изменяющиеся параметры, например информацию о компьютере. Это надежно, дает привязку к компьютеру, но в наш век постоянных апгрейдов очень неудобен.
On-Line регистрация. Состоит в том, что программа в On-Line связывается с сайтом разработчиков (или компании, осуществляющей продужу софта) и передает туда ревизиты пользователя. В ответ программе передается регистрационная информация. Этот метод может и хорош для ряда программ, но на мой взгляд не выдерживает никакой критики по двум соображениям:
Никто не может гарантировать, что конкретно передаст программа в Инет. А передать она может все, что угодно - параметры компьютера, пароли, любые данные и т.п.
Конкретный пользователь может не иметь доступа к Инет. Это особенно важно для программ, работа которых не связана напрямую с Сетью. И зарегистрировать такую программу его практически никто к себе на компьютер не пустит (из соображений п.п. 1)