Собеседование реверс-инженер: что реально спрашивают и как отвечать через strace и Ghidra

За последние два года я прошёл четыре технических интервью на позиции reverse engineer — от аутсорс-пентеста до продуктовой ИБ-команды. Ни на одном не попросили реализовать сортировку на доске. Зато на каждом давали бинарник и говорили: «У тебя 30 минут, расскажи, что это делает». Ниже — разбор того, что спрашивают на деле, с конкретными примерами ответов через strace и Ghidra. Без абстрактных «учите ассемблер» — только задачи и ожидания интервьюеров.

Вопросы на собесе реверс-инженер: три категории, которые повторяются

Собеседование на позицию реверс-инженера — не викторина по учебнику. Вопросы укладываются в три блока, каждый проверяет свой навык.

Теория форматов и архитектуры. PE-заголовки (PE — Portable Executable, формат исполняемых файлов в Windows), ELF (Executable and Linkable Format — то же самое, но для Linux), calling conventions (соглашения о передаче аргументов функции — через стек или регистры), layout памяти процесса. Проверяют одно: понимаете ли вы, как устроен бинарный файл до его запуска.

Практическое задание. Выдают файл — иногда заранее по e-mail, иногда прямо на месте. Нужно объяснить, что он делает. Иногда это crackme (учебная задача на снятие защиты), иногда реальный семпл с затёртыми строками. Инструменты на ваш выбор, но обычно ожидают дизассемблер (IDA Pro или Ghidra) и отладчик (x64dbg под Windows, gdb под Linux).

Сценарные вопросы. «Вам прислали подозрительный .exe, расскажите порядок действий». «Бинарник упакован UPX — что делаете?». «strace показывает connect() на внешний IP — что дальше?». Оценивают не знание команд, а мышление: умеете ли строить гипотезы и проверять их последовательно.

По данным cyberyami.com, типовое интервью malware-аналитика обязательно включает вопросы по статическому и динамическому анализу, работу с паковщиками и сценарий реагирования на инцидент. Русскоязычные вакансии добавляют знание PE/ELF-формата и умение читать ассемблер x86/x64 — но писать его с нуля не заставляют.

Статический анализ ПО: вопросы по структуре бинарника

Вопросы по PE-формату — абсолютный фаворит интервьюеров. Не потому что PE-заголовки — вершина науки, а потому что по ним сразу видно: работал кандидат с бинарниками руками или только читал про них.

«Перечисли основные заголовки PE-файла». Ответ, который ждут: DOS Header (_IMAGE_DOS_HEADER), NT Header (_IMAGE_NT_HEADERS), внутри NT Header — File Header и Optional Header, затем массив Section Headers (по одному на каждую секцию). Для Linux — аналогичный вопрос про ELF: ELF Header, Program Headers, Section Headers. Если вы хоть раз открывали бинарник в Ghidra или IDA — эти структуры знакомы, они отображаются в первых строках анализа.

«Что показывает поле Magic в Optional Header?» Значение 0x010B — PE32 (32-битный файл), 0x020B — PE64 (64-битный). Мелочь на первый взгляд, но именно по этому полю инструменты определяют разрядность. Интервьюер проверяет: видели ли вы hex-дамп заголовка живьём. Запоминать конкретные числа необязательно — достаточно знать, что такое поле существует и где его искать.

«Что такое IAT и зачем она нужна?» IAT (Import Address Table — таблица адресов импорта) хранит адреса функций из внешних DLL, которые бинарник вызывает при работе. Это первое место, куда смотрит аналитик при статическом анализе ПО: по списку импортов за секунды понятен характер программы. Если в импортах CreateRemoteThread, WriteProcessMemory, VirtualAllocEx — перед вами с высокой вероятностью инжектор. InternetOpenA, HttpSendRequestA — программа общается с сетью.

Здесь же часто спрашивают про разницу между RVA и VA. RVA (Relative Virtual Address) — смещение относительно базового адреса загрузки (ImageBase). VA (Virtual Address) = ImageBase + RVA. Формула простая, но на собеседовании реверс-инженера её просят написать и объяснить: зачем разделение существует. Ответ: из-за ASLR (Address Space Layout Randomization — рандомизация базового адреса при каждой загрузке) ImageBase каждый раз может быть разным, поэтому внутренние ссылки хранятся как смещения.

«Что такое TLS Callback?» TLS Callback (Thread Local Storage Callback) — функция, которая выполняется ещё до точки входа программы (Entry Point). Загрузчик Windows сначала создаёт поток, срабатывает TLS Callback, и только потом управление уходит к main(). Авторы малвари используют это для запуска антиотладочного кода до того, как отладчик остановится на Entry Point. Если кандидат знает про TLS Callbacks — значит, сталкивался с реальными образцами, а не только с учебными crackme.

strace — динамический анализ бинарников на практике

strace — утилита трассировки системных вызовов в Linux. На собеседовании часто дают задание: «Вот бинарник, запусти под strace, объясни вывод». Звучит просто — до момента, пока перед глазами не появляется 500 строк и непонятно, на что смотреть.

Интервьюер ждёт одного: вы умеете фильтровать шум и находить поведенчески значимые вызовы. Минимальный набор:

• open() / openat() — какие файлы читает или создаёт программа. Обращение к /etc/passwd, /proc/self/maps, к файлам в /tmp — каждый из этих паттернов о чём-то говорит.
• connect() — сетевые соединения. IP-адрес и порт в аргументах покажут, куда бинарник пытается «позвонить домой».
• execve() — запуск других процессов. Если бинарник вызывает execve("/bin/sh", ...) — это shell-дроппер.
• ptrace() — вызов, связанный с отладкой. Программа, вызывающая ptrace(PTRACE_TRACEME, ...) на саму себя — классическая антиотладочная техника. В терминологии MITRE ATT&CK (открытая база тактик и техник атак; T-коды вроде T1055 или T1622 — уникальные идентификаторы конкретных техник) это Debugger Evasion (T1622) и Ptrace System Calls (T1055.008).

Предпосылки: нужна Linux-среда (Kali, Ubuntu или любой дистрибутив). strace обычно предустановлен; если нет — sudo apt install strace. Запуск: strace -f -o trace.log ./suspicious_binary. Флаг -f отслеживает дочерние процессы (малварь часто форкается), -o trace.log пишет вывод в файл.

Пример значимых строк в выводе:

openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY) = 3
connect(4, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("185.x.x.x")}, 16) = 0
ptrace(PTRACE_TRACEME, 0, NULL, NULL) = -1 EPERM

Первая строка — бинарник читает DNS-конфигурацию, готовится к сетевому взаимодействию. Вторая — устанавливает TCP-соединение на порт 443 к конкретному IP. Третья — пытается вызвать ptrace на себя, получает ошибку EPERM (запрещено — потому что strace уже трассирует процесс). Это антиотладочная проверка: если ptrace(PTRACE_TRACEME) возвращает ошибку, программа «понимает», что её анализируют.

На собеседовании достаточно прокомментировать эти три строки и показать: вы понимаете, что бинарник делает сетевой callback и проверяет наличие отладчика. Дальше интервьюер спрашивает: «Что следующим шагом?». Хороший ответ: извлечь IP из connect(), проверить по threat intelligence, параллельно открыть бинарник в дизассемблере для статического анализа.

Ghidra для начинающих: типовое тестовое задание

Ghidra — бесплатный дизассемблер и декомпилятор от NSA (Агентство национальной безопасности США). Для подготовки к собеседованию он работает не хуже IDA Pro. Разница: IDA Pro — коммерческий стандарт с декомпилятором Hex-Rays; Ghidra — бесплатен, с открытым кодом, встроенным декомпилятором и поддержкой скриптов на Java/Python. Для задач интервью оба инструмента закрывают одинаковый объём работы.

Типовое задание: присылают бинарник (обычно x86-64) и просят описать его функциональность. Пошаговый процесс, который от вас ждут.

Шаг 1. Импорт и автоанализ. Откройте Ghidra, создайте проект, импортируйте файл. Ghidra автоматически определит формат (PE или ELF) и архитектуру. Если определение корректно — в окне импорта увидите правильную платформу. Нажмите «Analyze» с дефолтными настройками. Через несколько секунд в окне Listing появится дизассемблированный код.

Шаг 2. Анализ импортов. Перейдите в Symbol Tree → Imports. Список импортированных функций расскажет о поведении до чтения кода. RegOpenKeyExA, RegSetValueExA — работа с реестром Windows. CryptEncrypt, CryptDecrypt — криптография. URLDownloadToFile — загрузка из сети. Это самый быстрый способ сформировать первую гипотезу о назначении бинарника.

Шаг 3. Поиск строк и декомпиляция. Window → Defined Strings покажет читаемые строки: URL серверов управления (C2), пути к файлам, ключи реестра. Часть строк будет обфусцирована — это нормально, особенно в реальных семплах. В терминах MITRE ATT&CK обфускация строк относится к технике Deobfuscate/Decode Files or Information (T1140). Двойной клик по функции в Listing открывает декомпилированный псевдокод справа — это и есть главное преимущество Ghidra перед чистыми дизассемблерами.

На собеседовании не ожидают полного реверса за 30 минут. Ожидают методологию: импорты → строки → точка входа → ключевые функции → гипотеза о назначении. Если при этом озвучиваете: «Вижу CreateRemoteThread и VirtualAllocEx — похоже на process injection, ищу место вызова» — это уже сильный ответ.

Анализ вредоносного ПО на собеседовании: паковщики и антиотладка

Этот блок проверяет, сталкивался ли кандидат с боевыми образцами. Учебные crackme редко упакованы. Реальная малварь — почти всегда.

«Что такое паковщик и как он влияет на анализ?» Паковщик (packer) — инструмент, который сжимает, шифрует или трансформирует исполняемый файл. При запуске пакованный бинарник распаковывает себя в памяти и передаёт управление оригинальному коду. В MITRE ATT&CK это Software Packing (T1027.002). Для аналитика последствие простое: статический анализ покажет код распаковщика вместо реальной логики. Нужно либо распаковать вручную (найти OEP — Original Entry Point, дампить память), либо использовать автоматические инструменты.

Хороший ответ на практике: «Определяю паковщик через энтропию секций — у пакованных файлов она близка к 8.0 (максимум для случайных данных). Detect It Easy (DIE) определит конкретный паковщик. Если UPX — распаковываю командой upx -d sample.exe. Если кастомный — загружаю в отладчик, ставлю точку останова на VirtualAlloc или VirtualProtect, жду распаковки в памяти, дамплю процесс».

«Какие антиотладочные техники знаете?» Интервьюер хочет услышать конкретику:

• IsDebuggerPresent() — WinAPI-функция, возвращает TRUE под отладчиком. Обходится патчем одного байта в PEB (Process Environment Block — структура данных процесса, где Windows хранит флаг отладки).
• ptrace(PTRACE_TRACEME) — Linux-аналог. Программа трассирует саму себя; если уже трассируется через strace или gdb, вызов вернёт ошибку.
• Timing checks — замер времени через rdtsc (Read Time-Stamp Counter) или QueryPerformanceCounter. Под отладчиком код исполняется медленнее, разница выдаёт дебаггер. Всё перечисленное — Debugger Evasion (T1622).

«Что такое Dynamic API Resolution?» Техника (T1027.007), при которой малварь не указывает WinAPI-функции в таблице импортов, а разрешает их адреса во время выполнения через GetProcAddress или хеширование имён. Статический анализ покажет в IAT только GetProcAddress и LoadLibraryA, а реальный набор функций скрыт. Ответ: «Если IAT подозрительно бедная — ищу вызовы GetProcAddress в декомпилированном коде и восстанавливаю реальные импорты».

Практические задания реверс-инжиниринг: делай раз, делай два, делай три

Для тех, кто готовится к первому собеседованию — конкретные действия с измеримым результатом. Не «прочитайте книгу», а три этапа, после которых вы закроете 80% типовых вопросов.

Шаг 1. Настройте окружение

Виртуальная машина с Linux (Ubuntu или Kali) для strace и gdb. Виртуальная машина с Windows для x64dbg и Ghidra. Ghidra работает на обеих платформах (требует JDK 17+). Поставьте Detect It Easy (DIE) для идентификации паковщиков — всё перечисленное бесплатно. Для Windows-анализа есть готовый образ FLARE VM от Mandiant — среда с предустановленным набором инструментов (x64dbg, IDA Free, Python, YARA), экономит несколько часов настройки. Результат: два работающих окружения, в которых вы можете открыть произвольный бинарник.

Шаг 2. Разберите три бинарника — от простого к сложному

Первый — crackme с сайта crackmes.one. Задача: найти правильный пароль. Откройте в Ghidra, найдите строки, прочитайте декомпилированную функцию проверки. Результат: вы понимаете, как навигировать в Ghidra и где искать логику валидации.

Второй — скомпилируйте свою C-программу, которая делает сетевой запрос и пишет файл. Соберите без debug-символов: gcc -s -o test test.c. Откройте в Ghidra как «незнакомый» бинарник, пропустите через strace. Вы увидите собственный код «с другой стороны» — один из лучших способов научиться читать чужой. Результат: вывод strace совпадает с тем, что вы написали; декомпиляция в Ghidra узнаваема.

Третий — упакуйте бинарник: upx --best -o packed test. Откройте в Ghidra до распаковки — декомпилятор покажет мусор. Распакуйте (upx -d packed), откройте снова — код читаем. Результат: вы на практике видите разницу между пакованным и чистым файлом.

Шаг 3. Проговорите анализ вслух

Большинство готовят технические навыки и забывают: на собеседовании нужно объяснять увиденное. Откройте любой из бинарников в Ghidra и проговорите анализ, как будто интервьюер смотрит на экран: «Открываю импорты — вижу CreateFile, WriteFile, InternetOpenA. Гипотеза: программа качает что-то из сети и сохраняет на диск. Перехожу к entry point, ищу вызовы этих функций…». Эту часть подготовки к собеседованию ИБ пропускают почти все — и именно она отличает кандидата, который получает оффер.

Приём, который пригодится на любом интервью: перед запуском дизассемблера получите базовую информацию тремя командами. file suspicious_binary — тип файла и архитектура. strings suspicious_binary | grep -i "http\|\.exe\|password\|registry" — читаемые строки с фильтрацией по интересным паттернам. sha256sum suspicious_binary — хеш для проверки по VirusTotal и threat intelligence. Тридцать секунд — и первичная картина готова.

Вопрос по ассемблеру на собеседовании выглядит не как «напишите программу», а как «прочитайте три строки». Классический пример:

xor eax, eax
or  eax, eax
jz  label

«Произойдёт ли переход?» xor eax, eax обнуляет регистр (любое число XOR само с собой = 0). or eax, eax не меняет нулевое значение, но устанавливает флаг ZF (Zero Flag = 1, потому что результат — ноль). jz (jump if zero) — переход произойдёт. Такие микро-задачи проверяют одно: читаете ли вы дизассемблированный код на уровне отдельных инструкций.

Ещё один навык реверс-инженера, который оценивают неявно — способность объяснить разницу между статическим и динамическим анализом не определением из книги, а через практику. Статический — это Ghidra, IDA, strings, проверка хешей; бинарник не запускается. Динамический — strace, отладчик, песочница; наблюдение за работающей программой. Дополнение, которое отличает сильный ответ: «Статический анализ безопасен, но неполон — пакованный файл не отдаст секреты без запуска. Динамический показывает реальное поведение, но бинарник может менять его в зависимости от окружения: детект песочницы, гео-проверки, проверка hostname».

Если вы переключаетесь из разработки в ИБ и думаете, что для собеседования нужны годы опыта в анализе малвари — нет. Три разобранных бинарника дают больше, чем три прочитанных книги. Я видел кандидатов с пятилетним стажем в разработке, которые не могли объяснить, зачем ptrace вызывается с PTRACE_TRACEME. И видел студентов после месяца с crackme и strace, отвечавших увереннее. Разница не в «таланте к ассемблеру» — в том, работал ли человек с бинарниками руками.

Ошибка, которую совершают career-switcher-ы из разработки: привычка думать «от кода к результату» вместо «от поведения к коду». Разработчик пишет функцию и знает, что она делает. Реверс-инженер видит функцию впервые и восстанавливает назначение по косвенным признакам — импортам, строкам, паттернам вызовов. Это другой навык, и именно его проверяют, когда дают бинарник без описания.

Большинство гайдов по подготовке говорят: «выучите PE-формат, пройдите GREM». Формально правильно. Но бесполезно без привычки работать с неизвестным. Тот, кто сел за strace с незнакомым бинарником и сам себе объяснил вывод, готов к собеседованию лучше, чем тот, кто прочитал три книги и ни разу не открыл Ghidra. Если ищешь первую роль и хочешь что показать на собесе помимо резюме — на IB Basics разбирают именно такие задачи с нуля, от первых артефактов до формулирования гипотез.