Знімаємо пароль з тестів MyTestX і easyQuizzy

Наша взаимовыгодная связь https://banwar.org/

Час від часу стикаюся з проханнями, що стосуються програм для проведення комп'ютерного тестування (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