Следующим шагом необходимо обратиться к профессиональному инструментарию, а именно интерактивному дизассемблеру «IDA PRO», которая свободно распространятся в интернете и имеет бесплатную версию.
Рисунок 12 – Меню импорта файла в дизассемблер
В процессе дизассемблирования будет задействована динамическая библиотека «sko.dll» (Рисунок 12). Именно в этом файле содержится участок кода, в котором участвует вызов функции «EnumWindows». После нажатия на кнопку «Открыть», Программа «IDA PRO» выполнит анализ и дизассемблирование бинарного файла.
Рисунок 13 – Меню импорта файла в дизассемблер
В пункт меню «Imports» перечислены все использующиеся API-сигнатуры системных библиотек (Рисунок 13). Найти необходимую функцию можно легко с использованием сочетания клавиш «CTRL+F» с пометкой «EnumWindows». В столбце «Library» указан бинарный файл (который в свою очередь тоже является динамической библиотекой) играющий роль как хранилище данной сигнатуры.
Рисунок 14 – Представление сигнатуры «EnumWindows»
Двойным нажатием открывается окно «IDA View-A», в котором отображается полная запись сигнатуры (указание возвращаемого значения, типы принимаемых параметров и их количество) (Рисунок 14). Теперь необходимо найти функцию, в которой происходит проверка данных с участием данной сигнатуры. В таблице «Import» найдя функцию «ExitProcess» из списка функций и открыв ссылки её участия будет обнаружена грубейшая ошибка разработчиков программного обеспечения. Место расположения функции «EnumWindows» выдала константное именование.
Рисунок 15 – Места использования функции «ExitProcess»
Перейдя по выделенной ссылке будет обнаружен участок кода, где видно будет видно, что исполнение функций «ExitProcess» начинается после операции условия (Рисунок 15). Именно в этом участке происходит сравнение вредоносного процесса с процессом, которые заранее заложен в базу данных жертвы.
Рисунок 16 – Дизассемблированный листинг в виде графа
Ассемблерная инструкция «jz» (jump if zero) срабатывает, если инструкция «cmp» (инструкция сравнения левого операнда с правым) возвращает в результате работы ноль (Рисунок 16). В случае, если результатом является ноль, исполнение обходит инструкцию «ExitProcess»
Для удобства можно отобразить шестнадцатеричное представление ассемблерных инструкций. Представленный выше листинг будет иметь следующий вид.
Рисунок 17– Дизассемблированный листинг в виде графа
Шестнадцатеричная запись ассемблерной инструкции «JZ» – 74. Существует полное право изменить её на однобайтную инструкцию «JMP» – EB. После реализации замены байтов, исполнение никогда не достигнет функции «ExitProcess» (Рисунок 17). В качестве доказательства приведен следующий листинг инструкций.
Рисунок 18 – Дизассемблированный листинг в графическом представлении
К большому удивлению сработала одна из защит программного обеспечения. Замена одного байта привело к полному изменению контрольной суммы. Серверное программное обеспечение после проверки файла «sko.dll» отправляла клиенту (взломщику) ошибку аргументируя это тем, что файл «sko.dll» устарел (найдено нарушение валидности) (Рисунок 19).
Рисунок 19 – Дизассемблированный листинг в графичес
В этой ситуации сразу бросается в глаза следующая идея реализации обхода данной защиты. Нужно найти участок кода где вычисляется хэш-сумма. В дальнейшем перехватить место записи контролной суммы и заменить не валидное значение валидным (где в итоге отправить серверу валидное значение). К сожалению этот путь довольно трудоёмкий, который не гарантирует стопроцентную работоспособность данной идеи.
В итоге после нескольких часов размышлений была обнаружена критичная ошибка со стороны разработчиков.
Рисунок 20 – Схема обхода блокировки вредоносного процесса
Оказывается, что сервер не контролирует клиентское программное обеспечение (Рисунок 20). Файл, над которым происходит процедура проверка контрольной суммы располагается на константном пути (который заложен внутри исполняемого файла). В добавок к этому оказалось, что исполняемая программа обращается к динамической библиотеке путем константной строки. (Рисунок 21) Никому не составляет труда с помощью шестнадцатеричного редактора изменить наименование динамической библиотеки.
Рисунок 21 – Шестнадцатеричное представление исполняемого файла
Таким образом в клиент-серверном процессе клиентское ПО использует не валидную динамическую библиотеку, а серверное ПО (которое в свою очередь осуществляет проверку контрольной суммы) не в состоянии ликвидировать вредоносный процесс.
Рисунок 22 – Шестнадцатеричное представление исполняемого файла
Для качественной демонстрации была проведена отладка программного обеспечения (Рисунок 22). На инструкции push EAX была установлена точка останова (ввод программы в режим «Пауза» в момент исполнения указанной инструкции». В регистр EAX записывается строковое значение, которое хранится по смещению «aCheatEngine», где «aCheatEngine» есть переменная хранящая адрес. Дизассемблер использует переменные для улучшения читабельности листинга. В последствии сравнения регистра EAX с данными, находящиеся в дата-секции «Size» вычисляется проверка. После изменения ассемблерной инструкции JZ на JMP, исполнение всегда будет обходить инструкцию «ExitProcess». В данном случае, процесс «Cheat Engine» является вредоносным.