Практичне зворотне проектування: Практичний посібник для початківців

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

Налаштування безпечного середовища аналізу

Перед тим як торкатися незнайомого бінарного файлу, ізолюйте своє робоче середовище. Використовуйте виділену віртуальну машину без мережевого доступу до вашого хосту, створіть її снімок перед аналізом та відключіть спільні папки та синхронізацію буфера обміну. Інструменти на кшталт Linux VM з radare2, Ghidra, gdb та objdump покривають більшість статичних і динамічних потреб, а Windows VM з x64dbg та Process Monitor необхідна для PE-файлів. Ніколи не аналізуйте підозрілі зразки на своїй основній машині, і завжди повертайте снімки між сеансами, щоб уникнути перехресного забруднення.

Статичний аналіз: читання без запуску

Почніть з визначення типу файлу та архітектури за допомогою file та readelf -h (Linux) або інспектора PE-заголовка (Windows). Перевірте упакування чи обфускацію за допомогою аналізу ентропії — інструменти на кшталт Detect It Easy помічають підозріло високі значення ентропії секцій, які свідчать про стиснення чи шифрування.

Далі завантажте бінарний файл у дизасемблер, такий як Ghidra або IDA Free. Зосередьтеся на:

• Імпортах та експортах — виклики API на кшталт CreateRemoteThread чи VirtualAllocEx натякають на впровадження процесу; WSAStartup свідчить про мережеву діяльність.
• Рядках — запустіть strings -n 8 binary, щоб виявити жорстко закодовані URL-адреси, шляхи до файлів або повідомлення налагодження, які розкривають функціональність.
• Графіках потоку керування — вигляд декомпілятора Ghidra перетворює сирову асемблеру на читаний псевдо-C, що різко прискорює розуміння циклів і умовних операторів.

Додавайте анотації до імен функцій у міру їх розуміння. Перейменування sub_401020 на decrypt_config одразу ж робить решту аналізу простішою для відстеження.

Динамічний аналіз: спостереження під час виконання

Статичний аналіз дає вам не дуже далеко, особливо проти обфускованого чи упакованого коду. Завантажте бінарний файл у налагоджувач і встановіть точки зупинки на підозрілих викликах API, визначених раніше. У x64dbg, зупинка на VirtualAlloc чи WriteProcessMemory часто розкриває процедури розпакування у тій мірі, як вони записують розшифрований код у пам'ять безпосередньо перед виконанням.

Використовуйте Process Monitor або strace/ltrace на Linux, щоб реєструвати активність файлів, реєстру та мережі в реальному часі. Цей зовнішній вигляд доповнює внутрішній вигляд з налагоджувача й часто виявляє поведінку, яка важко помітна в дизасемблі, таку як створення тимчасових файлів чи пошук DNS.

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

Боротьба з трюками проти аналізу

Много бінарних файлів — особливо малвер — включають перевірки, розроблені для виявлення налагоджувачів, віртуальних машин або пісочниць. Поширені техніки включають виклик IsDebuggerPresent, перевірку специфічних для VM ключів реєстру або вимірювання часу виконання для виявлення покрокового виконання. Коли ви помічаєте ці перевірки під час статичного аналізу, ви можете виправити умовний стрибок у налагоджувачі, щоб примусити