Я все еще переворачиваю образец LockerGoga. На этот раз я хочу сосредоточиться на сетевой части. Вы спросите, зачем программам-вымогателям вообще нужна сетевая часть? Да, тот же вопрос пришел мне в голову, но теперь я хотел бы придерживаться фактов. И, как вы можете видеть из подпредставления Ida Imports, есть две функции импорта из библиотеки WS2_32.
Поскольку прямого имени импортируемого символа нет (только порядковый номер), мне нужно было проверить библиотеку WS2_32 на соответствие порядковым номерам, присвоенным конкретным символам. Я загрузил библиотеку ws32.dll в Ida, и это экспорт.
Таким образом, кажется, что LockerGoga связан с двумя символами, WSAStartup и WSACleanup. Эти два вызова необходимы для инициализации использования winsocket вызывающим процессом и завершения использования winsockets. Вот и все. Не так много на данный момент. Давайте посмотрим, как называются эти символы.
Инициализация Winsock называется рядом с InterlockIncrement и InterlockExchange. Обе эти функции изменяют значение переменной атомарным образом — это потокобезопасно. Почему кто-то хотел увеличить некоторую переменную рядом с инициализацией winsock?
Крипточасть — не шифрование файлов
Перебирая интересные дизассемблированные строки, я нашел что-то вроде кодировки для всей латиницы.
Поэтому я погуглил, чтобы найти, что это может быть, я использовал строку EncodingLookupArray, чтобы найти ее в Google, потому что мне кажется, что эта кодировка более значима. Код взят из библиотеки CryptoPP — бесплатной криптографической библиотеки C++. Похоже, что библиотека была скомпилирована статически и ее код включен в бинарный файл вредоносного ПО. Исходный код, который, вероятно, виден на дизассемблере, доступен на сайте Гренобльского университета. Отсюда вы можете видеть, что код отвечает за кодировку Base64 — может быть, это код, отвечающий за кодировку строк пути к файлу, чтобы они были доступны для обмена между ведущими и подчиненными процессами? Это очень вероятно, поскольку процессы LockerGoga взаимодействуют друг с другом, обмениваясь путями, закодированными в Base64.
И да, моя гипотеза верна, вся эта инициализация энкодера Bas64 делается в функции main, отвечающей за работу мастер-процесса. Я описал эту функцию в предыдущем посте. Здесь видно, что этот инициализатор вызывается из кода мастер-процесса — того самого, который отвечает за вызов CreateMutex и выделение памяти файлов для обмена информацией между процессами.
Поскольку теперь я знаю, что там используется библиотека CryptoPP, я хотел бы найти, где используется какая-то асимметричная криптография — это приведет меня к месту, где выполняется шифрование файлов. Начиная с представления строк Иды, там есть кое-что интересное.
Похоже, здесь что-то генерируется какая-то строка. Давайте сравним его с исходным кодом CryptoPP, который ищет строку «для этого открытого ключа».
Но переход к ссылке на это конкретное ни к чему меня не привел. Я только что попал в сегмент .rdata, где хранится смещение для этих функций.
Давайте пойдем по более простому пути, я пошел к списку расширений файлов, наверное, к тому, который должен быть зашифрован — я так думаю, потому что там много расширений документов. Но что интересно, есть также некоторые расширения исходного кода.
Похоже автор не любит интерпретируемые языки
Я не вижу там никаких родных расширений. Ладно, к делу. Я прыгаю на один уровень выше к внешней ссылке в Иде и снова приземляюсь в коде основного процесса.
Что я имею в виду, говоря о мастер-коде? Я бы попытался объяснить это, увеличив представление графика Иды. Здесь вы можете найти основной код процесса, например, тот, который начинается со строки «сканирование…», которая ведет к файлу журнала, а зеленая строка показывает цикл, который постоянно сканирует расширения файлов.
Таким образом, первая стрелка сверху указывает на цикл, который идет почти от начала блока кода до его конца. Внутри него находится блок, отвечающий за получение атрибутов и сравнение расширений файлов. Этот блок работает в цикле зеленой линии.
