Время от времени сталкиваюсь с просьбами, касающимися программ для проведения компьютерного тестирования (MyTestX и easyQuizzy), которые заключаются либо в извлечении файла теста из .exe-файла (в случае с MyTestX), либо в открытии защищенного паролем теста.
Набросал "деревянный" последовательный мануал для тех, кому необходимо самостоятельно извлечь тест или сделать, чтобы редактор позволял открыть тест при вводе любого пароля.
Нам понадобится отладчик, например, OllyDbg и программа для упрощенной работы со структурой PE-файла, например, CFF Explorer, также нам понадобится редактор тестов (элементарно ищется в Google), который мы будем "исправлять", и файл, содержащий тест, который необходимо открыть.
Перейти к описанию про easyQuizzy
Перейти к модифицированным редакторам для открытия тестов без пароля
Снимаем пароль с тестов MyTestXPro (.mtx)
Утилита для извлечения теста (.mtf/.mtx) из .exe-файла (пароль kaimi-io)
Для начала, разберем самую тривиальную проблему: как извлечь из .exe-файла файл с тестом - .mtf (речь о MyTestX).
Берем .exe-файл, который содержит тест (я воспользовался экземпляром с форума) и открываем его в CFF Explorer. Сразу же переходим в раздел "Resource Directory" в колонке слева, далее, в списке справа, ищем "Resource Directory Entry ... AKA: RCData", открываем выпадающий список и в нем ищем "Resource Directory Entry ... AKA: MTA".
Этот ресурс фактически является .mtf-файлом, который нас интересует. Теперь нам необходимо извлечь его. Для этого обратимся к дочернему элементу последнего вышеупомянутого ресурса - "Resource Data Entry". Выделим его и увидим в нижней половине окна его атрибуты, нас интересуют поля "OffsetToData" и "Size".
Запомним значение поля "OffsetToData" и переключимся на "Address Converter" в списке слева. Теперь введем значение в поле RVA - мы получили физическое смещение интересующего нас ресурса относительно начала файла ("File Offset").
Воспользуемся встроенным hex-редактором, который расположен в нижней части окна и пометим это место (правая клавиша мыши, "Begin Of Block"), теперь прибавим к "File Offset" значение поля "Size", которое я упоминал выше: 003437E8 + 0001A50B = 0035DCF3 (значения указаны в hex, у вас значения могут отличаться), переместимся по этому адресу (кнопка с изогнутой стрелкой), отметим это место (правая клавиша мыши, "End Of Block"). Осталось сохранить выделенный фрагмент в отдельный файл. Снова нажмем правую клавишу, выберем Copy->Into New File, укажем имя файла, и готово (dx предлагает упрощенный метод: CFF Explorer->Resource Editor->RCData->"MTA"->правой кнопкой мыши Save Resource (Raw)).
Мы получили .mtf-файл, который можно открыть в редакторе тестов MyTestX - MyTestEditor. Однако, тест может быть защищен паролем. Давайте рассмотрим, как модифицировать редактор тестов, чтобы файл с тестом открывался при вводе любого пароля.
Запускаем редактор тестов MyTestEditor и отладчик OllyDbg. Аттачимся OllyDbg к процессу MyTestEditor (File->Attach). Мы оказываемся внутри ntdll.
Нажимаем Debug->Run и возобновляем работу приложения. Далее нажимаем правую клавишу где-нибудь в левом верхнем окне отладчика. В появившемся меню выбираем Go to->Expression, в появившемся окне вводим ReadFile (имя функции WinAPI, которая скорее всего будет использоваться для чтения содержимого файла с тестом).
В списке снизу выбираем kernel32.ReadFile и нажимаем "Follow expression". Мы находимся в начале функции ReadFile, теперь нам необходимо поставить breakpoint, чтобы отследить обращение программы к функции. Ставим breakpoint, для этого нажимаем правой клавишей на подсвеченной линии ассемблерного кода и выбираем Breakpoint->Toggle. Вообще, прежде чем ставить breakpoint, лучше сначала в MyTestEditor вызвать диалог открытия теста, иначе придется пропускать много обращений (F9) к ReadFile из не интересующих нас мест, их можно определить по значению на верхушке стек-фрейма (правое нижнее окно отладчика, строка с текстом "Return from kernel32.ReadFile to ..."). Интересующий нас вызов будет выглядеть приблизительно так:
Как только мы поймали нужное обращение (оно произойдет, когда мы в диалоге открытия теста выберем наш тест, защищенный паролем, и нажмем "Открыть"), посмотрим внимательнее в правое нижнее окно отладчика (в нем мы видим содержимое стека), прокрутим окно вниз в поисках строки, которая представляет собой полный путь к файлу с тестом (нас интересует этот стек-фрейм, так как скорее всего он был сформирован в интересующей нас функции).
Поставим hardware breakpoint, чтобы отследить обращение по этому адресу. Для этого выберем строчку, которая содержит путь к тесту, нажмем правой клавишей мыши и выберем Breakpoint->Hardware... В открывшемся окне в первой колонке (Break on), выберем Access (R/W) и нажмем OK.
Продолжим выполнение программы (F9 или Debug->Run). Через какое-то время программа в очередной раз остановится, сработает наш свежепоставленный hardware breakpoint. У меня место срабатывания выглядело как-то так:
Напоминает какую-то промежуточную функцию для работы с файлом, поэтому воспользуемся несколько раз опцией Debug->Execute till return (Ctrl+F9), пока не окажемся в более "высокоуровневом" участке кода, где строится основная логика обработки файла с тестом.
Полистаем код. Нас интересуют всевозможные условные переходы (je, jne, jz, jnz и так далее), которые перепрыгивают более-менее внушительные фрагменты кода, скажем от 5 инструкций. Некоторые участки я сразу пропустил, где, как мне показалось, производятся неинтересные действия, как, например, в этом фрагменте:
Напоминает проверку версии теста. Мне так сразу показалось, но можно убедиться и опытным путем, поставив breakpoint на инструкции условного перехода и поменяв значение Z-флага в окне регистров справа, когда выполнение программы прервется на этом участке. Пролистаем немного вниз и наткнемся на следующую группу условных переходов:
Попробуем в лоб поменять Z-флаг на каждом переходе. То есть в MyTestStudent у нас открыт диалог выбора файла с тестом, мы ставим breakpoint на одном из переходов, в диалоге выбираем файл с тестом, который защищен паролем, наблюдаем окно, запрашивающее ввод пароля, вводим туда произвольный текст, после этого у нас должен сработать ранее установленный breakpoint, меняем Z-флаг и продолжаем выполнение программы нажатием F9.
Мы увидим, что на вышеупомянутых двух переходах, при изменении Z-флага программа завершает свою работу, после этого запускается браузер, где открывается сайт с фрагментом законодательства: какая-то самопальная "защита" от простого взлома. Однако, при изменении логики условного перехода, который расположен чуть ниже, мы видим, что в программе предварительно открывается тест, хотя после этого программа все равно завершает свою работу и открывает браузер.
Для открытия браузера скорее всего используется функция WinAPI ShellExecute. Проверим наше предположение: снова нажимаем правую клавишу где-нибудь в левом верхнем окне отладчика, в появившемся меню выбираем Go to->Expression, в появившемся окне вводим имя нашей функции, переходим в начало функции и ставим там breakpoint. Снова выполним модификацию логики последнего, интересующего нас, условного перехода, и наш breakpoint срабатывает:
Воспользуемся несколько раз Debug->Execute till return (или Ctrl+F9), чтобы вернуться из недр shell32.dll и попасть в модуль MyTestEditor (следим за заголовком окна отладчика, там где в данный момент написано "[CPU - main thread, module shell32]"). Почти сразу попадаем в подобное место:
Здесь мы видим еще один условный переход, который нам необходимо исправить (на лету, либо заменив условный переход на безусловный - jmp). Получается, что нам нужно подправить два условных перехода, чтобы получить возможность открывать защищенный тест, вводя любой пароль. Заменим и проверим:
Мой тестовый .mtf-файл, защищенный паролем, открылся без проблем (ссылки на модифицированный редактор и пример файла с тестом находятся в конце статьи). После внесения необходимых изменений, нажимаем правой клавишей в левом верхнем окне отладчика, выбираем Edit->Copy all modifications to executable, в появившемся диалоге указываем имя файла и получаем модифицированный редактор тестов.
Переходим к той же самой проблеме открытия защищенных тестов, созданных с помощью программы easyQuizzy. В этом случае тест представляет собой .exe-файл, однако нет необходимости проводить с ним какие-то дополнительные манипуляции - редактор умеет открывать такие файлы.
Давайте запустим редактор файлов easyQuizzy, отладчик OllyDbg, подсоединим отладчик к процессу (здесь и далее я не буду детализировать тривиальные моменты работы с отладчиком, как в тексте до этого) и возобновим работу процесса. В этот раз воспользуемся другим способом поиска участка кода, который необходимо исправить. Как вы могли заметить, при открытии защищенного паролем теста, программа выдает сообщение "Incorrect password" (у меня язык интерфейса переключен на английский). Будем отталкиваться от этого.
Переключимся на основной исполняемый модуль easyQuizzy в отладчике (View->Executable modules, двойной клик по имени модуля, убедитесь, что в заголовке окна присутствует текст: "...module easyQuizzy"). Нажмем правой клавишей мыши в окне отладчика и найдем все строковые ресурсы, на которые существуют ссылки в исполняемом коде.
Перед нами появится перечень строк в одной большой таблице, найдем в ней строки с сообщением о некорректном пароле и поставим на них breakpoint'ы.
Пробуем открыть защищенный тест и тут же ловим срабатывание breakpoint'а.
Почему? Скорее всего программа подгружает необходимые строковые ресурсы при открытии теста, опираясь на некоторые внутренние идентификаторы. Бегло осмотрев функцию, где мы оказались, можно сделать вывод, что ничего особого интересного здесь не происходит. Единственный примечательный момент, это условный переход, отвечающий за отображение подсказки к паролю - ссылка на строку "Password hint:" в коде. Давайте рассмотрим функцию, откуда была вызвана эта функция (либо воспользовавшись Execute till return, либо посмотрев адрес возврата в стеке).
Мы оказались внутри занимательной функции, где можем наблюдать пропуск довольного большого фрагмента кода по условному переходу, вдобавок пропускаемый фрагмент содержит ссылку на строку "Incorrect password.".
Но как мы вообще попадаем в этот фрагмент кода? Прокрутим листинг немного вверх и увидим гораздо более интересный условный переход: он позволяет пропустить даже вызов функции, которая отображает нам диалог ввода пароля.
Пробуем изменить логику его работы (например, забиваем условный переход NOP'ами) - вуаля, защищенный тест открывается не запрашивая пароль.
Подведем итог: как мы видим, защита теста паролем в общем-то номинальная и ее легко преодолеть при наличии базовых навыков работы с отладчиком.
Файлы с тестами, на которых я проводил эксперименты: cкачать.
Оригинальные редакторы тестов: MyTestX и easyQuizzy.
Модифицированные редакторы тестов, позволяющие открыть тест, не зная оригинального пароля:
☯ mega.co.nz: MyTestX-mod, easyQuizzy-mod
☯ sendspace.com: MyTestX-mod, easyQuizzy-mod
Обсуждение закрыто.