1. Зміст статті «Якщо порівнювати SecuROM v7.33.17 з танком Абрамс без динамічного захисту, OllyDbg...
2. Warning!
3. What is target
4. Філософія злому
5. SecuROM v7 Virtual Machine
6. LINK
7. висновок

Зміст статті

«Якщо порівнювати SecuROM v7.33.17 з танком Абрамс без динамічного захисту, OllyDbg - з гранатометом РПГ-7, а X-code injection - з кумулятивною гранатою для гранатомета, то, як і в реальності, такий постріл навзнак прошиє броню цієї важкої неповороткою машини і досягне поставленої мети - OEP ... Виведену з ладу машину вивчають Російські інженери ... »

Вступ

Стратегія Tiberium Wars досі є однією з найпопулярніших ігор серії Command & Conquer від відомої контори Electronic Arts. Остання лояльно ставиться до Sony Digital Audio Disc Corporation (SONY DADC), чию матір згадують, коли чергова іграшка, запротекченная SecuROM, просить вставити оригінальний диск. Незважаючи на божевільну «популярність» SecuROM у всьому світі, в нашій країні рідко коли можна почути про нього публічно ( exelab.ru в розрахунок не беремо). В першу чергу це пояснюється наявністю свого зоряного протектора, але якщо Sony після кількох судових розглядів відмовилася від послуг нульового кільця, то хлопці з Protection Technology продовжують користуватися низькорівневими функціями, де абсолютним чемпіоном за викликом є ​​KeBugCheckEx.

Warning!

Вся інформація надана виключно в ознайомлювальних цілях. Ні редакція, ні автор не несуть відповідальності за будь-можливу шкоду, заподіяну матеріалами даної статті.

Таким чином у розробників залишилася одна арена для битви - прикладний рівень. І, природно, вони доклали максимум зусиль для забезпечення надійного захисту ... яка була пробита, розібрана і демонтована :).

What is target

Спочатку визначимося з нашим інструментарієм. Власне, знадобиться сама іграшка Tiberium Wars (з останнім патчем 1.9), для зняття дампа - OllyDbg 1.10 з OllyDmp (власне як дампер) і OllyDbg 2.0 без будь-яких плагінів. Незважаючи на такий настільки скромний набір, в нашому випадку працювати можна з одним отладчиком, а основною зброєю буде асемблерний код. Але перш за все відповімо на питання, який виконуваний файл для завантаження у відладчик. Переходимо в папку з встановленою грою. Першим на очі потрапляє нешкідливий CNC3.exe: судячи по точці входу, откомпилирован Microsoft C ++ 7.0, стандартні секції .text, .rdata ... Правда, якщо його запустити, нас чемно попросять вставити оригінальний диск. Вибачте, є тільки Daemon Tools з образом, тому виникає цілком нормальне бажання розв'язати четверту тіберіумную бійку і, врешті-решт, віддерти перевірку диска від програми. Так як я був знайомий з попередніми іграми з серії CnC, то знав, що CNC3.exe грає роль обгортки і просто через WinAPI CreateProcess запускає потрібний файл з розширенням .dat (насправді звичайний Microsoft PE EXE format) з потрібними параметрами. Нескладно здогадатися, що шукана мета - \ RetailExe \ 1.9 \ cnc3game.dat. Вантажимо в відладчик згаданий файл і по секції .securom розуміємо, з чим маємо справу. F9 ... Миле віконце з написом «Не вдалося запустити потрібний додаток безпеки». Ще раз його можна прочитати, якщо запустити будь-який API-шпигун, ProcMon ... Одним словом, розробники прекрасно інформовані про всі програми, що створюють проблеми їх продуктам. Приєднатися до процесу теж не можна - він просто завершиться. Втім, ця гидота діє тільки на час перевірки диска. Не погано! Для мене тоді це означало, що найближчий місяць OEP і робочий дамп я точно не побачу. Звичайно, через кілька місяців я не гірше розробників знав, що і як працює в SecuROM 7.33. Причому вся лінійка 7.3x практично ідентична, особливо це стосується віртуальної машини (саме помітна зміна: в більш пізніх версіях замінено на «You Are Now Entering a Restricted Area»). Але зараз у мене тільки один відладчик і ніякої надії вийти переможцем такого серйозного ворога, над створенням якого працювали вельми не дурні люди.

Нам дали зелене світло! Знімаємо дамп!

Філософія злому

Пробити навісну броню і доїхати до OEP тупим копирсання в отладчике - занадто довго і неефективно. Будемо бити в борт! Перша діра в захисті не змусила себе довго шукати: я відразу помітив, що протектор не перевіряє цілісність всього файлу. Ну, не те щоб зовсім не перевіряє, щось подібне є, але ось тільки йде воно як перевірка ділянок і спрямована, перш за все, на виявлення програмних точок зупину (так званий «перекриває код»). Вона мені ніяк не заважала, тому в практичному плані це означає, що можливе впровадження X-коду в образ файлу статичним шляхом. Строго кажучи, X-код - це осмислена сукупність байт, впроваджених сторонньою особою або програмою в цільової код процесу з метою виконання певного завдання.

Розрізняють такі типи:

1. On-line patching. Через WinAPI ReadProcessMemory / WriteProcessMemory читаємо / пишемо в адресний простір процесу. Наприклад, таким чином, ставлять прапор реєстрації в NtExplorer під егідою AsPack 2.11c, щоб не морочитися з розпакуванням. Однак сучасні протектори типу Themida не дають доступ в свій адресний простір.
2. Offline patching. Або статичний патчінга. Власне, наш випадок, коли ніщо не заважає писати прямо в виконуваний образ і перехоплювати в ньому управління. Виявити такого «Штірліца» у себе в тилу протекторам на порядок складніше. При необхідності обдурюють захист, роблячи оригінальну копію файлу і через GetCommandLine / GetFilePath повертають посилання на нього.
3. Dll-hijacking. З урахуванням того, що при завантаженні образу першими отримують управління динамічні бібліотеки, записані в його таблиці імпорту (точніше, функція DllMain), то ми першими отримуємо кермо влади над захистом і встигаємо приховати себе задовго до роботи навісний броні.

Нагадую, що для швидкого завантаження можна прописатися в HKLM \ Software \ Microsoft \ WindowsNT \ CurrentVersion \ Windows \ AppInit.

Розуміння головного сховища є ключовим для злому алгоритмів роботи віртуальної машини

Так ось, наше завдання - перехопити управління в потрібному місці і показати адресу повернення, щоб в потрібний час приєднатися до процесу. Чому я йду таким шляхом? Як уже було згадано вище, вся проблема полягає в тому, що розробники прекрасно інформовані про будь-яких програмах, які створюють проблеми їх продуктам. Цей факт нескладно перевірити, прослухавши CreateFile, FindWindow в досліджуваному протекторі. Механізми взаємодії між процесами - вчорашній день; передовий спосіб боротьби з навороченими защіщалкамі - безпосереднє впровадження в цільової образ захищеної програми. Виявити його на порядок складніше, адже в цьому випадку ми використовуємо ресурси самого протектора. Щоб протистояти такому розкладу, перш за все вводять перевірку цілісності файлу (динамічний захист). Ту саму, яка відсутня в нашому випадку (чим я, власне, скористався). Їдемо далі. Я вже сказав, що для компіляції CNC3.exe використаний Microsoft C ++ 7.0. Але ж очевидно, що і cnc3game.dat откомпилирован тим же компілятором. Точка входу виглядає як:

004628DA CALL 004784B8 004628DF JMP 004626FA

Реально точка входу знаходиться по операнду стрибка - 004626FAh. Функція за адресою 004784B8h нічим корисним не займається, і я її завжди ігнорую. Однак в ній ми знаходимо, що вона викликає кілька API (GetSystemTimeAsFileTime, GetCurrentProcessId ...). Для нас це означає тільки одне: якщо в GetSystemTimeAsFileTime впровадити X-код, який перехопить управління і покаже нам адресу повернення, то у нас буде чудова можливість потрапити в околиці OEP і зняти робочий дамп, за умови, що після розпакування стартовий код дійсно на своєму законному місці. І хоча SecuROM 7.33 перевіряє прологи деяких значущих WinAPI, цей список досить неповний, плюс сама перевірка йде тільки на самому початку. Ось тобі і наступний недолік! Тепер пора зібрати нашу кумулятивну гранату. Місце для базування я вибрав в кінці секції .est і приступив до збірки - написання asm-коду, який самостійно виконає всю роботу. Весь код складається з двох частин. Перша доставить саму гранату на місце: замінить пролог GetSystemTimeAsFileTime на безумовний перехід до другої частини. Власне, в цьому випадку отримуємо управління з Розпакувальник (визначити місце якого нескладно, поставивши крапку зупинки на секцію .text) і туди ж його повернемо після того, як перехід буде встановлений. До речі, спочатку, щоб отримати доступ на запис в секцію kernel32.text (справа була на вісті), я офлайн на 2k3 через PeTools встановлював атрибут Write, перераховував контрольну суму ... і адже працювало! Спосіб досить поганий, враховуючи, що є WinAPI VirtualProtect, але нестандартні підходи іноді теж на руку. Переходимо до другої частини нашого уявлення. Першочерговим завданням тут є показ адреси повернення і утримання управління до прибуття на місце відладчика. Я реалізував свій алгоритм, який переводить large integer в ACSIIZ-рядок (про ltoa я тоді не знав), а завдання показу і утримання управління елегантно вирішив за допомогою MessageBox, але потім управління передається назад в WinAPI. Втім, для показу можна нахабно використовувати функціонал самого протектора - CreateThread з адресатом 00F9AD0E, але це непродуктивно. Отже, граната зібрана, спробуємо! Монтуємо міні-дамп. Запускаємо гру. Нас цікавлять всі MessageBox після перевірки: 00DDCE77, 76B414D4, 7C34207B, 0040A5AE ... Сто-ООП! Останній, але ж виклик йде з секції .text! We need attach now! Приєднуємося до процесу Ольгою 1.10, яка з дампер, і переходимо за останньою адресою. Неймовірно, але ми зупинилися практично в OEP (точка входу розташована за адресою 0040A2C7). Трохи пізніше, коли віртуальна машина (VM) стала більш-менш вивчена, було зроблено ще одне умошокірующее відкриття (знову прорахунок команди з SONY DADC) - потрапити в OEP можна з ювелірною точністю і при цьому ще більш безпечним шляхом. І як ви думаєте, що цього допомогло? SecuROM v7.33 Virtual Machine, чиє завдання - навпаки захищати від зломщиків, але ніяк вже не допомагати їм!

Оптимізуючи швидкість роботи віртуальної машини, в SONY DADC вирішили залишити без обфускаціі один з острівців!

SecuROM v7 Virtual Machine

Інженери Sony DADC як у воду дивилися: з готовим чином дістатися до OEP і зняти дамп - за фактом справа кількох хвилин, запеклих хакерів це ніяк не зупинить. Навісна захист безсила, значить, вихід один - зробити максимально непрацездатним дамп! За такою логікою, більшість не хоче морочитися з VM, прописуючи її складну структуру, в якій неможливо розібратися за прийнятний час, і вважаючи за краще дампи всю виділену віртуальну пам'ять, і має, і не має відношення до VM, і приварюють її у вигляді окремої секції, попередньо здогадавшись вставити після конструкції «MOV EAX, 1; CPUID; »інструкції« MOV AL, CURRENT_CPUID_KEY_DELTA_DECODE »і виконати оне ще 254 рази. В результаті не виграємо ні в розмірах дампа, ні в швидкодії.

В цілому на повний розбір VM пішло близько двох місяців, причому перші півтора я просто копався в усьому без розбору, поки не «здогадався» почати дослідження з самого початку ланцюжка - і ось тут почалося ... Сама SecuROM v7.3x VM по суті не є віртуальною машиною в звичному розумінні, ніякої АСМ-код там НЕ емулюється. Все набагато простіше: по суті процедура з двома аргументами (LPDWORD і VOID) і трьома варіантами роботи. Ну а далі залишається тільки дивуватися. По-перше, щоб зрозуміти, як воно працює, просто уважно вивчи перший острівець (шматок коду від spin-блокування до JMP EAX), який, як не дивно, виконується завжди, і завжди перший.

REP STOS DWORD PTR ES: [EDI] .... MOV DWORD PTR DS: [EBX + 4], EAX MOV EAX, DWORD PTR SS: [ESP] MOV DWORD PTR DS: [EBX + 8], EAX MOV DWORD PTR DS: [EBX + 0C], EDX MOV BYTE PTR DS : [EBX + 10], 95 MOV DWORD PTR DS: [EBX + 14], EBX MOV DWORD PTR DS: [EBX + 1C], ESP SecuROM v7.33.017 і не уявляє, якими серйозними наслідками загрожує впроваджений X-код

Код, наведений вище, з потрохами видає головне сховище, яке відіграє ключову роль в VM. Розберешся в змінних і в області зберігання проміжних даних - вважай, що VM на 90% зламана! По-друге, стало очевидно, що по суті тут все наштамповане методом copy / paste. По-третє, божевільна кількість закономірностей аж до використання регістрів CPU на острівцях. А той факт, що один з острівців знаходиться без обфускаціі - взагалі вбило! Єдине, що тут реально приносить, це ROL-байт (crypt-byte), так як без знання того, які точно матопераціі з ним виконують всі 255 острівців віртуальної машини, неможливо побудувати кулхацкерскую автоматизовану ломалка і зняти все за раз. Власне, кому хочеться розуміти, про що все-таки йдеться - читайте повний варіант статті на диску або на нашому сайті. Наступне питання - чи реально віддерти VM від тіберіумом? Інтуїція підказує, що більш ніж! Я вже встиг обмовитися, що варіантів роботи три. Почнемо з останнього (спосіб №2), власне нумеруються по мірі їх появи в захищеній програмі. Спосіб №2 повністю зав'язаний з двома протилежними за логікою роботи алгоритмами, представленими у вигляді двох процедур з двома аргументами, які відпрацьовують один за одним. У першому заносимо будь-яке число (наприклад, 1), другий - посилання на масив ключів (offset 00B93AFC), які копіюються в стек VM. На виході в EAX виходить щось типу закодованого числа (0790A442), яке було передано в першому аргументі. Якщо це закодоване число (0790A442) згодувати в перший аргумент алгоритму зворотного ходу, то на виході в EAX ми отримуємо ту ж 1, за умови, що масив ключів був однаковий (offset 00B93AFC). Коротше, маємо дві функції, що дають в сумі нульовий ефект. Власне, роль VM в них така: у першому випадку кришуються АСМ-інструкції

MOV ECX, DWORD PTR SS: [EBP + 8] MOV ECX, DWORD PTR DS: [ECX] MOV EAX, DWORD PTR SS: [EBP + 0C] AND EAX, ECX MOV ECX, EAX

У другому - інструкція NOP в переносному сенсі. Причому прийти до цього висновку можна і без розтину VM, просто порівнявши дві згадані процедури (зворотного і прямого ходу).

Наступні в списку способи - № 1А і №1. Вони схожі, але з тією лише різницею, що перший після виходу з VM переносить нас в запитувану WinAPI, а другий - в запитувану внутрішню функцію (до слова, це може бути одна АСМ-інструкція, найчастіше - операція з резервуванням стека). Прихованих WinAPI не так вже й багато, ось неповний список: SetUnhandledExceptionFilter, GetModuleFileNameA, DeleteFileA, GlobalFree. Звернення до VM в цьому випадку завжди ознаменовується CALL EAX, інформація черпається з відомим зсувів в таблиці імпорту. У загальній сумі в дампі набралося близько десятка викликів - сміливо видирає і ставимо нормальні виклики WinAPI. Найбільш проблемним є найперший спосіб (через божевільного кількості викликів - близько 10k). Тут два варіанти:

1. Дампи. Проста технічна реалізація, але потрібно перетикати всі можливі меню, та й взагалі пройти мало не всю гру. На відміну від «Косинки» і «Пасьянсу» - вірний спосіб убити час з користю!
2. Знаючи структуру всіх 255 острівців (насправді в способі №1 беруть участь близько 50), по сигнатурі бази запитів написати на С ++ програму, яка шукає всі бази запитів, потім будує весь ланцюг роботи VM і в потрібному місці віртуального стека витягає і дешифрує (XOR SecretDATA, 43E2AB9D) заховані дані. Найбільш ефективне рішення.

Особливістю способу №1 є перехід до VM: CALL ANY_OFFSET -> JMP DWORD PTR DS: [переміщуваний адреса] -> база запиту -> JMP [VM_VIRTUAL_ADDRESS] -> VM. В інших випадках все обходиться прямим викликом VM без другого елемента в ланцюжку.

Суть в тому, що інструкція JMP DWORD PTR DS: [переміщуваний адреса] грає роль залізничної стрілки. Перший раз, коли викликається внутрішня функція, «стрілка» переведена на VM, а точніше - в базу запитів, де відбувається заправка згаданих вище двох аргументів для віртуальної машини (LPDWORD і VOID). В процесі роботи VM витягує адресу запитуваної функції і ставить його як переміщуваний адреса - стрілка переведена! Після виходу з VM відбувається перехід в нашу необхідну функцію, ну а після першого виклику все, хто буде її викликати, потрапляють відразу куди потрібно. Як бачиш, оптимізація! До речі, кількість інструкцій, які виконуються за один прогін віртуальною машиною в способах №1 і № 1А, коливається близько 3k, зате спосіб №2 б'є всі рекорди - 30k. Причому острівець без обфускаціі належить саме останньому способу. Фінішна робота з дампом включає перестроювання в нормальний вигляд секції коду, видалення непотрібних і сторонніх впроваджень типу

0044F4D2 DEC DWORD PTR DS: [158297A] 0044F4D8 JE NODVD.00482DE5 00482DE5 MOV DWORD PTR DS: [158297A], 18D 00482DEF JMP NODVD.0044F4DE

Останнім пунктом відсилаємо дамп в Sony DADC. На цьому тіберіумную бійка закінчується.

OEP на горизонті! VM під контролем xD

LINK

• tuts4you.com/download.php?view.2090 У самому кінці, завдяки Nightshade, я абсолютно випадково дізнався, що існує англомовна стаття по віртуальній машині SecuROM 7.30. Було приємно побачити, що в цілому наші висновки збіглися. Однак в статті структура VM викладається в дещо іншому вигляді, та й деяких аспектів роботи VM я не побачив.
• playground.ru/cheats/4932/ NoDVD для CnC3: Tiberium Wars v1.9. Відмінною особливістю є прибудована в секцію .memory віртуальна машина. У статті узятий в якості основного прикладу. Новачкам рекомендується почати з нього.

висновок

На закінчення я просто подякую SONY DADC за її дійсно цікавий продукт (для хакерів зокрема)! До зустрічі на сторінках] [.