Файл: Методы и средства обратного проектирования. Понятие обратного проектирования.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 11.01.2024
Просмотров: 21
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Методы и средства обратного проектирования.
1.1. Понятие обратного проектирования
Основными угрозами для программного продукта, защищенным от несанкционированного использования третьим способом (ввод ключевой информации пользователем), являются угроза нарушения функциональности модуля защиты и угроза раскрытия ключевой информации. Реализация первой угрозы может заключаться в обходе либо полном отключении модуля защиты путем модификации кода программы. Реализация второй – выяснении путем исследования программы ключевой информации, требуемой при регистрации (таблица 1.1).
Таблица 1.1
| Угроза для модуля защиты ПО от несанкционированного использования | Возможная реализация угрозы |
| Угроза нарушения функциональности модуля защиты | Отключение модуля защиты |
| Обход модуля защиты | |
| Угроза раскрытия ключевой информации | Выяснение ключевой информации злоумышленником путем исследования программы |
Наиболее распространенные способы, используемые злоумышленником при реализации первой либо второй угрозы – использование специализированных средств исследования работы программ, а также их кода.
Существует несколько задач, которые злоумышленник должен решить при реализации данных угроз.
1. Задача обнаружения в коде программы модуля защиты. Следует отметить, что без использования специализированных программных средств эта задача в принципе не решаема за приемлемое время. Это обусловлено следующими обстоятельствами.
Модуль защиты занимает достаточно малый объем в общей совокупности кода программы. Задача ручного поиска блока модуля защиты размером 100 – 200 байт в общем коде программы, занимающем сотни мегабайт, без использования специализированных средств в принципе не решаема за приемлемое время.
Анализ кода программы в значительной степени затрудняется тем, что производится анализ не исходного текста программы на языке высокого уровня, а анализ машинного кода, сформированного компилятором. На разборку и понимание такого кода уходит значительное время даже у специалистов высокого класса в данной области. Зачастую даже анализ исходных текстов программы, написанных другим человеком, является нетривиальной задачей. Анализ же машинного кода усложняет уже задачу в тысячи раз. Недостаточно провести анализ каждой машинной команды. Как правило, при анализе машинного кода приходится увязывать в единую последовательность действий как минимум 80 – 100 байт, чтобы понять, что действительно сокрыто за данной последовательностью кодов. Как правило, это очень усложняет анализ программы.
Задача исследования модуля защиты и понимания принципов его действия. Злоумышленник должен понять, каким образом построена защита, где она хранит (если хранит) ключевую информацию, где сохраняет (если сохраняет) свои метки и ключи, на каком этапе принимается решение о регистрации программы, либо об отклонении регистрации. При этом, злоумышленник сталкивается с проблемой анализа машинного кода, что приводит к трудностям перечисленным в первой задаче.
Однако, исходя их вышеперечисленных трудностей нельзя делать вывод об отсутствии необходимости защиты ПО от угрозы нарушения функциональности модуля защиты и от угрозы раскрытия ключевой информации. Большой объем взломанных программ на рынке ПО говорит об обратном – что эти угрозы вполне реальны и осуществимы. Продукты фирм, пренебрегающих защитой от реализации данных угроз оказываются в числе первых из взломанных.
На самом деле, сложности, перечисленные выше, для подготовленного злоумышленника в большинстве случаев таковыми не являются. Существует множество программных продуктов, позволяющих направленных на облегчение злоумышленнику решения задач 1 и 2, их решение в отдельных случаях доводится вплоть до автоматизма.
Анализ задач 1 и 2 показывает, что основная цель, решаемая злоумышленником при взломе ПО – анализ работы программы, поиск в ней участка кода, отвечающего за реализацию модуля защиты, детальное исследование принципов и механизмов работы данного модуля. При этом, ставится задача представления машинного кода на как можно более высоком уровне с целью более упрощенного его понимания. Для злоумышленника наиболее оптимальный вариант – формирование по машинному коду модуля защиты, его текста на исходном языке высокого уровня, однако данный вариант практически никогда не достижим.
Под обратным проектированием (reverse engineering) понимают процесс исследования и анализа машинного кода, нацеленный на понимание общих механизмов функционирования программы, а также на его перевод на более высокий уровень абстракции (более высокий уровень языка программирования) вплоть до восстановления текста программы на исходном языке программирования.
Основными методами обратного проектирования являются отладка и дизассемблирование программ. При этом используются следующие средства.
Отладчики – программные средства, позволяющие выполнять программу в пошаговом режиме, контролировать ее выполнение, а также вносить изменения в ход выполнения. Данные средства позволяют проследить весь механизм работы программы на практике и являются средствами динамического исследования работы программ.
Дизассемблеры – программные средства, позволяющие получить листинг программы на языке ассемблера, с целью его дальнейшего статического изучения. Дизассемблеры являются средствами статического исследования.
Мониторы событий – программные средства, позволяющие отслеживать определенные типы событий, происходящие в системе. Наиболее опасными для программного обеспечения с точки зрения их защиты являются мониторы операций с реестром и мониторы файловых операций, позволяющие проследить – какая программа куда и что записывала, считывала и т.д.
Редакторы кода занимают отдельное место среди средств обратного проектирования. Данные средства, как правило, включают функции дизассемблирования, но позволяют также вносить изменения в код программы. Данные средства предназначены, в основном для исследования программ, занимающих сравнительно небольшой объем.
Таким образом, классификацию средств обратного проектирования ПО можно представить в виде следующей схемы (рис. 1.1).
Рис. 1.1. Классификация средств обратного проектирования
Иначе говоря, средства динамического исследования ПО, позволяют исследовать работу программ в процессе их работы в реальном времени, а также вносить изменения в их работу. С другой стороны, средства статического исследования ПО предназначены для исследования кода ПО в режиме оффлайн.
1.2. Основные приемы, используемые злоумышленником при отладке и дизассемблировании программного обеспечения
Следует отметить, что любую систему защиты ПО можно вскрыть за конечное время. Это следует из того, что ее команды однозначно интерпретируются процессором. Как правило, если программа защищена только от средств статического анализа, то она легко изучается динамически, и наоборот.
Используя методы и средства обратного проектирования, взломщик может использовать различные уязвимости модулей защиты, которые не посчитал должным образом защитить разработчик программы.
Как правило, чисто программные модули защиты ПО работают на основе следующих методов.
Проверка правильности введенной ключевой информации при регистрации программного продукта.
Проверка на истечение временного срока работы программы при ее запуске или ограничения по количеству ее запусков.
Приемы осуществления атак взломщиком на данные методы, в общем-то, схожи, однако, имеют и свою специфику при реализации. Следует отметить, что без принятия мер к защите программных модулей защиты, последние могут быть легко обнаружены и вскрыты, либо отключены.
Рассмотрим специфику атак на представленные методы.
1.2.1. Специфика атак на модули проверки корректности ключевой информации
Для вскрытия данного типа защит в первую очередь необходимо найти в коде программы код модуля защиты и, а в нем – процедуру данной проверки.
В большинстве программных продуктов, проверка корректности ключевой информации выполняется непосредственным образом. При этом, исходный текст программы выглядит, приблизительно, следующим образом.
If (!ValidUser())
{
Message (“Неверный пользователь”);
Abort;
}
Здесь, ValidUser() – базовая процедура проверки. Ключевая информация может вводиться пользователем как в данной процедуре, так и ранее. Данный исходный текст компилируется компиляторами в код, аналогичный следующему:
PUSH AX
CALL IsValidUser;
POP AX
OR AX, AX
JZ continue
PUSH offset str_invalid_user
CALL Message
CALL Abort
Continue:……
В данном коде команда CALL IsValidUser осуществляет вызов процедуры IsValidUser. Передача в данную процедуру параметров (например, ссылки на ключевую информацию) осуществляется через стек командами PUSH (занесение параметра в стек) до команды CALL и POP (вызов из стека результата, возвращенного процедурой IsValidUser) после команды CALL.
В представленном примере результат выполнения процедуры IsValidUser заносится в регистр AX. В дальнейшем производится проверка на равенство нулю возвращенного результата (команды OR AX,AX). Если AX=0, то ключевая информация верна, производится ее регистрация и дальнейшее продолжение работы (JZ continue). В ином случае выводится сообщение о невозможности продолжения работы (PUSH offset str_invalid_user; CALL Message) и завершение работы программы (CALL Abort).
В данной ситуации, после обнаружения представленного выше программного кода модуля защиты, взломщик может осуществить атаку следующим образом.
Заменить команду условного перехода JZ continue на команду безусловного перехода JMP continue. В данном случае, регистрация программы будет осуществляться в любом случае, вне зависимости от правильности ввода ключевой информации.
Изменить в процессе работы программы содержимое регистра AX после команды POP AX, либо значение регистра флагов после команды OR AX,AX. В данном случае, злоумышленник вынужденно заставляет модуль защиты работать по нужной ветке.
Исследовать работу процедуры IsValidUser вручную с целью выяснения ключевой информации.
Реализация первых двух типов атак называются «жестким» взломом программного продукта, так как он требует модификации кода программы. Реализация третьего типа атак называется «мягким» взломом программного продукта и во многих случаях является более предпочтительной для злоумышленника, хотя и требует от него несколько больших временных затрат.
Первые два типа взлома позволяют осуществить взлом программного продукта в достаточно короткие сроки, не прилагая к этому слишком больших усилий (одна из таких защит была взломана в течение 10 секунд). Достоинством для злоумышленника третьего типа взлома заключается в том, что иногда исследовав логику работы процедуры IsValidUser, можно не только вычислить ключевую информацию, но также написать и генератор ключевой информации для последующего использования другими пользователями. Это возможно сделать, если разработчик вложил в модуль защиты непосредственную связь между идентификатором пользователя и его аутентификатором (ключевой информацией). Кроме этого, достоинством третьего типа взлома является то, что получив ключевую информацию, злоумышленник снимает все проблемы, тогда как «жесткий» взлом иногда для злоумышленника затруднителен в силу того, что проверка корректности осуществляется в нескольких местах программы и различными способами.
В процессе анализа процедуры IsValidUser особое внимание уделяется следующим элементам.
1.Информации, передаваемой в процедуру IsValidUser в качестве параметров и возвращаемой из нее.
2.Содержимому регистров, передаваемых в другие процедуры, вызываемые из процедуры IsValidUser.
Содержимому памяти по адресам, передаваемым в процедуру IsValidUser и процедуры, вызываемые из нее.
Содержимому памяти по адресам, в которые заносятся идентификатор пользователя и введенная им ключевая информация (например, пароль), а также обращение к данным адресам из функции IsValidUser. Отслеживание обращений к этим адресам позволит более локализовать код, отвечающий за проверку адекватности ключевой информации.