Содержание статьи
Какое-то время назад мой друг Jupiter предложил вместе разобрать алгоритм лицензирования Total’а. Пораскинув мозгами, мы написали генератор лицензии — файлов-ключей. И все было бы замечательно, если бы не присутствие в основе алгоритма лицензирования криптосистемы с открытым ключом — LUC. И ключи, разумеется, для успешного прохождения лицензирования нужно знать.
LUC — это похожая на RSA криптосистема. Ее отличие от RSA заключается в использовании последовательностей Люка вместо возведения в степень. Как и для RSA, для генерации закрытого ключа необходимо знать множители (P и Q), которые можно получить через факторизацию модуля (N). Но в нашем случае длина модуля — 832 бита. Естественно, ни у меня, ни у Jupiter’а таких вычислительных мощностей нет. А на квантовый компьютер мы еще денег не накопили. 🙂
Для решения этой проблемы мы сами сгенерируем приватный и публичный ключ криптоалгоритма LUC. Приватным зашифруем лицензию, публичным программа будет расшифровывать лицензию. А чтобы публичный ключ проходил, мы пропатчим его в памяти.
Помимо LUC, в Total’е присутствуют механизмы самозащиты, защита от модификации исполняемого файла. Можно, конечно, хардкорно запатчить файл, но это как раз и есть «костыль», который лишает обход защиты универсальности.
WARNING
Статья публикуется в образовательных целях. Редакция не несет ответственности за любой вред, причиненный материалами данной публикации. В статье намеренно не рассматривается сам алгоритм лицензирования, а демонстрируются практические аспекты имплементации обхода защиты с помощью техники proxy DLL.Что делаем?
Наша задача — заменить модуль (N) в исполняемом файле программы, не нарушая его целостности. Тогда наш сгенерированный файл ключа будет верно расшифрован и программа будет зарегистрирована.
Существует два варианта решения данной задачи:
- Написать загрузчики для х86- и х64-версий программы (Loader).
- Написать proxy DLL, которые будут выполнять ту же функцию, что и загрузчики.
Оба варианта позволяют беспрепятственно обновлять программу. Но я выбираю второй вариант, он более удобный. В этом варианте не нужно будет исправлять пути в свойствах ярлыков программы с исполняемого файла Total’а на наш лоадер. Достаточно просто скопировать DLL’ки и файл ключа в папку с установленной программой.
Инструменты
x64dbg
— отладчик;masm x32
— компилятор;masm x64
— компилятор;wincmd.key
— ключ для программы, сгенерированный моим с Jupiter’ом кейгеном.
Процесс
Я скачал с официального сайта последнюю бета-версию, включающую в себя обе версии программы (х86 и х64). Установил в директорию, которую предложил инсталлятор (C:\totalcmd
).
Теперь запускаем на выбор TOTALCMD.EXE
или TOTALCMD64.EXE
, без разницы. Получаем вот такое окно.
Это было ожидаемо. 😉 Теперь запускаем Total под отладчиком и заходим в закладку Symbols.
В левой половине окна видим загруженные в память процесса модули (DLL). Из всех модулей нас интересуют только две динамические библиотеки — это version.dll
и winspool.drv
.
Пусть тебя не смущает, что у winspool.drv
расширение не dll
, на самом деле внутренняя структура у winspool.drv
как у обычной динамической библиотеки. Эти два модуля и будут кандидатами для написания одноименных proxy DLL для Total’а.
INFO
Мы пишем два модуля потому, что у нас две версии программы: х86 и х64. Для каждой версии мы будем использовать proxy DLL соответствующей разрядности.Как работает механизм proxy DLL
В основе механизма proxy DLL лежит особенность загрузки модулей (DLL) в память процесса Windows загрузчиком (NTLDR или NT Loader).
В Windows-загрузчике этим занимается API LdrLoadDll
, который находится в модуле ntdll.dll
. Обертками этого API служат такие API, как LoadLibrary
и LoadLibraryEx
.
Один из этапов загрузки исполняемого файла (в нашем случае это модуль с расширением EXE) — это заполнение таблицы импорта исполняемого файла адресами API из DLL, необходимых для работы программы. В начале этого процесса LdrLoadDll
начинает искать модуль (DLL) по имени файла, к примеру version.dll
, который находится в таблице импорта в виде строки в кодировке ASCII. LdrLoadDll
ищет DLL в текущей директории созданного процесса, в нашем случае это C:\totalcmd
. Далее, если модуль не был найден, в зависимости от битности процесса (х86 или х64) LdrLoadDll
продолжает поиск требуемой DLL в системной директории (C:\Windows\System32
или C:\Windows\SysWOW64
). Если и в системной директории модуль не будет найден, мы получим сообщение об ошибке.
LdrLoadDll
позволяет загружать в адресное пространство созданного процесса модули, имеющие одно и то же название, из разных директорий. К примеру, в нашем случае proxy DLL загружает в память NTLDR из директории, где находится TOTALCMD.EXE
, а оригинальную DLL (из системной директории) мы загружаем в память из proxy DLL с помощью API LoadLibrary
, передавая ей в качестве параметра абсолютный путь к оригинальной DLL. Это еще один нюанс, который позволяет реализовать механизм proxy DLL. Далее из приведенного кода proxy DLL ты поймешь, как это работает. 🙂
Продолжаем. В процессах TOTALCMD.EXE
и TOTALCMD64.EXE
обе DLL присутствуют. Для TOTALCMD.EXE
мы будем использовать version.dll
, а для TOTALCMD64.EXE
— winspool.drv
.
В Total’е модуль (N), участвующий в расшифровке файла ключа (wincmd.key
), имеет вид строковой константы в кодировке ASCII:
AAD4474DC8387E81BB095D810F4F4F21D5D7CCC756E3D6E5DEE48AC000C25AA0EFAD0AD3A5AC46F15B50249597461BBB87CDC3F1BA37C17A9A207A3603E38E718F9927A5EB38005D8B72EAFDC63931C3D93C1FAD457A17CA85BEB40F3FA9152770DAC12E8E3B912D
Его необходимо, для правильной расшифровки нашего ключа, заменить на наш модуль (N):
E813039FB5F248DDA582F1C411D3B5B7A4C97CBB6982388EB354A8B78324A6A7B494ABAB4A0A97728BAC585FCD856D2173F4C3ADE89E8176AE53F7BF7AEC39FCACEC907829B31FE1C3BB3E2E4C30925525655F967B52A0318FCE0BA0BAE065D8A68DBE86167F67A1
Теперь вновь по очереди запускаем под отладчиком обе версии программы, чтобы определить, где (в какой секции исполняемого файла) находится искомый модуль (N).
Итак, запускаем х86-версию и переходим в закладку Memory Map. Нажимаем сочетание клавиш Ctrl + B, откроется окно бинарного поиска в памяти процесса, копируем оригинальный модуль (N) и вставляем его в поле ASCII.
Нажимаем OK, и у нас откроется закладка References с результатами поиска.
Видим адрес, по которому был найден модуль (N), — 0x004E219C.
Переходим в окно дампа памяти по данному адресу и скроллом поднимаемся вверх.
Видим адрес 0x00401000. Это верхний адрес секции, в которой находится модуль (N).
Опять возвращаемся в закладку Memory Map и видим, что адрес 0x00401000 соответствует адресу первой секции исполняемого файла TOTALCMD.EXE
— CODE
.
Для х64-версии проделываем те же самые манипуляции с отладчиком.
В результате выясняем, что ASCII-строка модуля (N) для х86-версии находится в секции CODE
(0x00401000
), а для х64-версии — в секции .data
(0x0000000000AD9000
).
Ну что же, необходимую информацию для написания proxy DLL мы получили. Начинаем кодить. 🙂
Кодинг
Разберем код для х86-версии, а именно version.dll
. Для х64-версии все аналогично. Точка входа proxy DLL (EntryPoint
). Здесь все стандартно.
API DisableThreadLibraryCalls
использовать не обязательно. Я пользовался им для отключения уведомлений DLL_THREAD_ATTACH
и DLL_THREAD_DETACH
, на всякий случай.
Далее переходим в MainProc.
Здесь я объявляю глобальные переменные, для сохранения адресов оригинальных API.
Резервирую область памяти для сохранения полученного пути к оригинальной version.dll.
Здесь я прокомментировал все шаги исполнения кода MainProc.
Чуть ниже MainProc я объявляю экспортируемые функции с безусловными переходами (JMP) из proxy DLL в оригинальную DLL. В файле version.def
определены имена экспортируемых функций proxy DLL, которые аналогичны именам функций в оригинальной DLL.
LIBRARY version
EXPORTS
GetFileVersionInfoA=__GetFileVersionInfoA@0
GetFileVersionInfoByHandle=__GetFileVersionInfoByHandle@0
GetFileVersionInfoExW=__GetFileVersionInfoExW@0
GetFileVersionInfoSizeA=__GetFileVersionInfoSizeA@0
GetFileVersionInfoSizeExW=__GetFileVersionInfoSizeExW@0
GetFileVersionInfoSizeW=__GetFileVersionInfoSizeW@0
GetFileVersionInfoW=__GetFileVersionInfoW@0
VerFindFileA=__VerFindFileA@0
VerFindFileW=__VerFindFileW@0
VerInstallFileA=__VerInstallFileA@0
VerInstallFileW=__VerInstallFileW@0
VerLanguageNameA=__VerLanguageNameA@0
VerLanguageNameW=__VerLanguageNameW@0
VerQueryValueA=__VerQueryValueA@0
VerQueryValueW=__VerQueryValueW@0
И главная функция proxy DLL — это ReplaceModulus
.
В секции данных proxy DLL у меня находятся оригинальный модуль (Original) и модуль (New), на который необходимо заменить оригинальный.
Здесь тоже все шаги выполнения кода прокомментированы.
Финал
Результатом всех описанных действий будет зарегистрированная версия программы. Причем в данном случае можно спокойно обновлять программу, не боясь того, что регистрация «слетит». 🙂
Копируем в папку с Total’ом три файла — это наш ключ wincmd.key
и наши DLL’ки: version.dll
и winspool.drv
. Запускаем программу.
В диспетчере задач видим, что в процесс загружены обе DLL’ки.
Радуемся. 🙂
Итоги
Как видишь, механизм proxy DLL — удобный и мощный инструмент. С его помощью ты можешь беспрепятственно эмулировать работу оригинальных функций и при этом комфортно модифицировать данные и код в памяти процесса.
Исходники и ключ
Скачать исходники программы и ключ для самостоятельной практики ты можешь по этой ссылке. Напоминаем, что все материалы выкладываются исключительно в образовательных целях. Редакция не несет ответственности за любой вред, причиненный материалами данной статьи.
Пароль — xakep.ru.