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. Отслеживание обращений к этим адресам позволит более локализовать код, отвечающий за проверку адекватности ключевой информации.

Довольно часто злоумышленником производится исследование содержимого ОЗУ на осмысленные последовательности символов, а также отслеживание обращений к адресам, по которым хранятся эти последовательности (например, “Invalid Registration”, “Password Fail” и т.д.). Как правило, эти сообщения находятся недалеко от модулей защиты, отвечающих за проверку корректности ключевой информации. По обращению к адресам, хранящим данные сообщения также можно локализовать код проверки адекватности ключевой информации.

Как правило, передача параметров в функции и их возврат осуществляется через 32-битные регистры EAX,EBX, а также используя регистры ESI и EDI для указания на используемые данные.