Описание задачи указывает на то, что был пойман некоторый хакер и с его машины был снят дамп оперативной памяти. Также был записан трафик отладки некоторого драйвера, соответственно, нам представлено два файла.
Откроем файл с трафиком и увидим только зашифрованный трафик отладки ядра Windows.
Для расшифровки трафика существует публичный диссектор, который поддерживает расшифровку — https://github.com/Lekensteyn/kdnet. Однако, нам нужно найти ключ. На этом моменте необходимо анализировать дамп, чтобы понять, какой ключ был использован.
Дамп памяти был снят с Windows 10x64_19041. Используем volatility, чтобы найти запущенные на системе процессы.
В списке процессов можно увидеть windbg.exe:
В совокупности с трафиком, это направляет на мысли о том, что в дампе данного процесса может находится ключ шифрования. Далее идёт не самая очевидная часть решения: при внимательном просмотре списка процессов можно заметить процесс Microsoft.Pho… (это первый процесс в списке). Данная программа служит для просмотра изображений. Значит, на компьютере открыты какие-то изображения, и мы можем посмотреть их. Дампим процесс и открываем его в GIMP.
Ищем нужное смещение руками и затем видим кусочек пароля для WinDBG.
Первая часть ключа «17890.». Ключ для WinDBG разделяется точками. Теперь мы можем поискать ключ в дампе. В памяти ключ хранится в преобразованном виде. Каждая часть ключа конвертируется в байты как число по базе 36. При этом каждая часть ключа занимает 8 байт.
Пробуем найти данную последовательность в дампе.
В итоге находим оставшиеся байты ключа.
На этом этапе дамп памяти больше не нужен, нам надо использовать полученный ключ, но для начала преобразовать его из байт в верный формат. Для конвертации можно использовать данный инструмент (как вариант) — http://extraconversion.com/base-number/base-36.
В итоге получаем следующий ключ: 17890.af3489a.9345kjm.lio147.
Теперь нам нужно расшифровать трафик с помощью диссектора, который был указан в самом начале.
Для того, чтобы диссектор работал корректно, необходимо установить дополнительную библиотеку — https://github.com/Lekensteyn/luagcrypt, также от автора диссектора. Информация по её сборке есть в самом проекте, и мне удалось без особых проблем собрать её.
После того, как мы собрали библиотеку, можно протестировать работу диссектора на примере из репозитория (насколько мне известно, у многих участников это получилось).
Однако, на трафике из задания диссектор не срабатывает. Это происходит из-за ошибки внутри lua-скрипта в функции парсинга ключа. Дело в том, что в случае ключей, содержащих больше 1 байта, конвертация происходит неверно, т.к. автор забыл, что нужно развернуть байты. В итоге нужно добавить одну строчку, чтобы ключ стал верно обрабатываться.
После этого мы можем расшифровать трафик:
Теперь наш трафик расшифрован, и можно приступать к его анализу. Отладка ядра генерирует очень много запросов, но у нас есть понимание, что отлаживался драйвер, и нам нужно найти его. Попробуем поискать начало флага «Aero» и увидим директорию, в которой разрабатывался таск, а также имя драйвера TestDriver.
Теперь мы знаем имя драйвера и можем поискать его в трафике.
Найдя упоминания имени драйвера, мы получаем дополнительную информацию об этом модуле. Его смещение, размер, а также текущий адрес выполнения. Теперь мы можем найти по какому адресу загружен драйвер, т.к. старшие 4 байта адреса текущей точки выполнения не будут изменены. А смещение добавляется в младшие 4 байта (это также можно было выяснить опытным путём, запустив отладку любого ядра Windows). Поищем обращения к адресу драйвера и найдём обращения на чтение данной памяти: первый блок содержит сигнатуру исполняемого файла Windows. Теперь нам нужно скопировать драйвер из трафика.
Для того, чтобы скопировать все данные, которые читаются по нужным нам адресам, используем следующий фильтр:
Такой фильтр позволит нам получить все операции чтения, на которые были возвращены данные. Сохраним данные в виде JSON.
Затем обработаем скриптом и восстановим файл.
Загрузим файл в IDA. Функций не так много и, если просто просмотреть их, то на глаза попадётся функция с инициализацией множества констант.
Посмотрим, что она делает.
Судя по всему, она просто ксорит два каких-то массива. Можно обратить внимание, что размер массивов 38 байт, что является размером флага при условии, что внутри md5-hash.
Однако, сейчас мы не можем просто взять и поксорить два массива, потому что ключи, заложенные в драйвер, не верные. На это может натолкнуть то, что они идут от 0 до 37:
Вероятно, хакер передал их через отладчик. Поищем команды записи в память.
Находится не так много записей, а записей с данными ещё меньше. Сразу можно обратить внимание на последовательную запись байт по последовательным адресам. Попробуем применить эти байты как ключи.
И получаем флаг.