Техніка емуляції викликів WinAPI у застосунках Windows як метод протидії зворотної розробки

Рейценштейн Кирило,

здобувач вищої освіти

Анотація

В статті представлені результати дослідження пошуку ефективного методу протидії зловмисному зворотному інжинірінгу. В результаті аналізу джерел було визначено пошук в напряму методу емуляції' виклику WindowsAPI. Техніка емуляції викликів WinAPIдозволяє захистити програмне забезпечення від таких атак шляхом перехоплення викликів API-функцій. Однак тестування показало певні недоліки цього методу. Дослідження виявило, що більш ефективним захистом є додаткове використання алгоритмів мутації та віртуалізації з емуляцією викликів WinAPI.

Ключові слова: зворотний інжинірінг, обфускація, емуляція, Windows, API

Основна частина

З точки зору програмного забезпечення, зворотне проектування - це процес дослідження програми для отримання закритої інформації про те, як вона працює та які алгоритми використовує. Хоча реверс програмного забезпечення можна використовувати у законних цілях, зокрема для аналізу зловмисного програмного забезпечення або не задокументованого дослідження системи, зазвичай вважається, що хакери використовують його для незаконної діяльності. Тематика техніки протидії зворотної розробки набуває все зростаючої актуальності[1], причому ще не склалися канонічні її варіанти, хоча вже з ранніх етапів розробки технік протидії почались спроби їх узагальнення. Так, зокрема, у в роботі К. Колберга та його колег[2] були класифіковані методи заплутування коду за чотирма критеріями: обфускація даних, обфускація керування, обфускація трасування та запобіжні перетворення. В роботі[3] було запропоновано класифікацію методів заплутування коду, яка базується на тих методах, що використовуються в процесі створенні шкідливого програмного забезпечення. До них відносять: метод мертвого коду, реєстрація перерозподілу, реорганізація підпрограм, інструкція заміни, метод перестановки коду, метод об'єднання.

Однак для застосунків Windowsз нашого погляду найбільш перспективним є підхід використання емуляції викликів WinAPIзахисту програмного забезпечення від зловмисних атак[4].

Техніка емуляції викликів WinAPIдозволяє захистити програмне забезпечення від таких атак шляхом перехоплення та емуляції викликів API - функцій. Як і інші методи емуляція викликів ускладнює процес зворотної розробки та робить його менш ефективним.

Крім того, техніка емуляції викликів WinAPIможе бути використана для відлагодження та тестування програмного забезпечення. Вона дозволяє симулювати поведінку деяких API-функцій, що дозволяє розробникам тестувати свої програми на різних платформах та середовищах.

Отже, техніка емуляції викликів WinAPIє важливою для захисту програмного забезпечення від зловмисних атак та для покращення процесу тестування та відлагодження програмного забезпечення.

Методи ускладнення налагодження.

Ускладнення налагодження - це процес застосування методів для запобігання аналізу та налагодженню програмного коду. Метою ускладнення налагодження є забезпечення безпеки програмного забезпечення та захисту від несанкціонованого доступу до нього.

Деякі методи ускладнення налагодження:

1. Виявлення відлагоджувачів: цей метод використовується для виявлення наявності відлагоджувача в процесі виконання програми. Цей метод може бути застосований, наприклад, шляхом перевірки статусу прапорців у поточному процесі.

2. Запобігання відлагоджувачів: цей метод використовується для запобігання запуску програми відлагоджувачем. Цей метод може бути застосований, наприклад, шляхом використання функцій, які перевіряють, чи відсутній відлагоджувач під час запуску програми.

3. Запобігання виконання коду у режимі відлагодження: цей метод використовується для запобігання виконання деяких частин програми у режимі відлагодження. Цей метод може бути застосований, наприклад, шляхом використання функцій, які перевіряють наявність відлагоджувача перед виконанням деяких частин програми.

4. Запобігання виявлення точок зупинки: цей метод використовується для запобігання встановленню точок зупинки під час відлагодження програми. Цей метод може бути застосований, наприклад, шляхом зміни адреси точок зупинки, або застосування інших методів, які ускладнюють встановлення точок зупинки.

IsDebuggerPresent - це функція з WinAPI, яка дозволяє програмістам перевірити, чи запущена програма в режимі налагодження (debugmode).

Не є гарним рішенням, бо зловмисник має змогу перехопити цю функцію WinAPI, або змінити байт у просторі PEB.

TLSCallback - це функціональність, яка дозволяє програмістам виконувати певний код у відповідь на певні події, що виникають під час взаємодії з TLS - захищеним з'єднанням.

Перевірка наявності налагоджувача в основній функції - не найкраща ідея, оскільки це перше місце, куди дивиться реверсер під час перегляду списку дизассемблера. Перевірки, реалізовані в головній функції, можна стерти інструкціями NOP, таким чином знявши захист. Якщо використовується бібліотека CRT, головний потік вже матиме певний стек викликів до передачі керування головній функції. Таким чином, хорошим місцем для виконання перевірки присутності налагоджувача є зворотний виклик TLS. Функція зворотного виклику буде викликана перед викликом точки входу виконуваного модуля.

CheckRemoteDebuggerPresent - це функція в WindowsAPI, яка дозволяє перевірити, чи є віддалений відлагоджувач (remotedebugger) підключеним до процесу. Ця функція приймає два параметри: ідентифікатор процесу і вказівник на змінну, в яку буде записано результат перевірки. Якщо віддалений відлагоджувач підключений до процесу, то функція повертає ненульове значення і записує 1 в змінну, яку передано в якості другого параметру. Якщо віддалений відлагоджувач не підключений, то функція повертає 0 і записує 0 в змінну.

NtQueryInformationProcess - це функція в WindowsAPI, яка дозволяє отримати інформацію про певний процес. Ця функція приймає три параметри: ідентифікатор процесу, тип запиту та вказівник на буфер, в який буде записано результат запиту. Тип запиту вказує, яку саме інформацію потрібно отримати про процес. Наприклад, можна отримати інформацію про кількість потоків, пам'ять, що використовується процесом, та інше. Ця функція є корисною для багатьох системних інструментів та утиліт, які працюють з процесами, таких як менеджер завдань (TaskManager), дебаггери, антивірусні програми та інші.

Усі наведені вище техніки мають одну суттєву проблему - це використання прямих викликів WinAPI, що дає змогу зловмиснику перехопити певну функцію та змінити її результат. Мета цієї роботи саме полягає в тому щоб унеможливити перехоплення функцій WinAPI.

Перехоплення WinAPI.

Перехоплення WinAPI - це процес перехоплення викликів функцій WinAPI, що виконуються у процесі. Цей процес може бути використаний з різноманітною метою, таких як моніторинг системи, введення фільтрів для певних функцій, підмена функцій і т.д. Один з найбільш поширених способів перехоплення WinAPI - використання функції феймворка Detoursбібліотеки MicrosoftDetoursабо ж бібліотеки MinHook. Ці бібліотеки приблизно однакові за можливостями для перехоплення функцій, які використовуються в програмі, і для зміни їх поведінки. За допомогою перехоплення WinAPIможна відслідковувати виклики певних функцій, збирати статистику або замінювати функції на власні, що дозволяє робити додаткову обробку даних, отриманих з цих функцій. На Рис. 1 показана схема перехоплення за допомогою бібліотеки MicrosoftDetours[4].

Рис. 1 Перехоплення WinAPI

Проте, використання перехоплення WinAPIможе мати й свої недоліки, такі як погіршення продуктивності програми через додаткові операції перехоплення і обробки даних. Також, це може створювати додаткові точки вразливості у програмі, що можуть бути використані для злому. Тому, при використанні перехоплення WinAPIнеобхідно ретельно вивчати всі можливі наслідки і використовувати цей метод обережно та з обґрунтованими причинами.

Розглянемо процес перехоплення функції MessageBoxз використанням MinHook.

Для перехоплення будь-якої функції WinAPIнеобхідно і достатньо знати три речі:

1. Назву функції;

2. Назву модуля, де знаходиться ця функція;

3. Адресу функції у необхідному процесі.

Для отримання адреси функції достатньо використати такі WinAPIфункції: GetProcAddressта GetModuleHandle.

Перший аргумент функції GetProcAddress - це адреса необхідної DLL, другий аргумент - це назва функції, яку шукають, тобто отримаємо такий виклик - GetProcAddress (GetModuleHandleA(«user32.dll»), «MessageBoxA»).Результатом такого виклику буде адреса необхідної функції. Все що залишилось це використати необхідну функцію в бібліотеці MinHookдля її перехоплення.

Позаяк ми маємо всі необхідні дані можна написати демонстративний код з використанням бібліотеки MinHook: intmain()

{ // not hooked

MessageBoxA (NULL, «I Love KPI!», «Information», MBJCONINFORMATION);

 //

 // getting msg box address

auto msg_box_addr = GetProcAddress (GetModuleHandleA(«user32.dll»), «MessageBoxA»);

 //

 // initializing minhook MH_Initialize();

 //

 // hooking

MH_CreateHook (msg_box_addr, MessageBoxA_hooked,

 //

 // enabling hooks MH_EnableHook (MH_ALL_HOOKS);

 //

 // calling the same function

MessageBoxA (NULL, «I Love KPI!», «Information», MBJCONINFORMATION);

 //

getchar(); returntrue;

}

При першому виклику функції MessageBoxAвикликається оригінальна функція, коли при другому виклику викликається власна функція MessageBoxAяка змінює зовнішній вигляд віконця а також текст.

Як висновок, використання прямих викликів WinAPIє дуже простою мішенню для зловмисника, бо перехоплення WinAPIне є дуже складним для хакера.

Техніка емуляції викликів WinAPI (на прикладі функції MessageBox).

При використнні x64dbgбуло проаналізовано як MessageBoxAпереходить з простору користувача до надання сигналу ядру системи Windows: функція MessageBoxAробить стрибок до функції MessageBoxTimeoutA, яка конвертує вхідні дані с ASCIIу UNICODEта викликає MessageBoxTimeoutW, потім функція нарешті викликає функцію ZwRaiseHardErrorз ntdll.dll, яка містить у собі інструкції з використанням syscallдля запиту до простору ядра системи Windows.

Отже стає зрозуміло що фінальною функцією у цьому ланцюжку є функція ZwRaiseHardError, яка подає сигнал ядру системи використовуючи інструкцію

International scientific journal «Grail of Science» | №27 (May, 2023)

syscall. Для емуляції функції MessageBoxAнам потрібно знайти документацію для функції ZwRaiseHardError.

extern «C» NTSTATUS NTAPI ZwRaiseHardError (LONG ErrorStatus, ULONG NumberOfParameters, ULONG UnicodeStringParameterMask,

PULONG_PTRParameters, ULONGValidResponseOptions, PULONGResponse); При реалізації емуляції WinAPIфункції MessageBoxAбув створений новий проект, в який було під'єднано залежність від MASMдля можливості використати asmінструкцій у коді.

Був імплементований код для виклику емулюваної функції:

code

Рис. 2 Результат виконання застосунку з емульованою функцією