- Регистрация
- 30.06.18
- Сообщения
- 141
- Лучшие ответы
- 0
- Реакции
- 346
- Баллы
- 12
Целью этой статьи не является публичное осуждение кого-либо.
Предисловие
Ничего не предвещало беды, даже намека на разбор, но раз уж проект закрылся, то думаю пора, хотя бы с научной точки зрения...
Стоит упомянуть еще пару деталей:
Почему проект закрылся? - По словам селлера, кодер ушел работать в приват, оставив софт без дальнейших обновлений, поэтому проект закрылся, так как никто его больше поддерживать не сможет.
Были ли шеллы в панелях балдра? - Ссылаясь на слова кодера - нет. Дело в том, что в админке нашли дыру и по ней грузились шеллы, а потом уже выкачивались логи. Все бы ничего, если бы это происходило не сразу, как с KPOT, дыры находили и по мере поступления новых панелей заливали шеллы, но вот только не с Baldr, шеллы залили всем и сразу, на все панели, которых на трекерах и так очень много. А правда это или нет, я уже не знаю.
Причастен ли overdot? - Сложно сказать, но мое мнение: нет. Он просто селлер, от него в этой ситуации ничего не зависело. Но как селлер, он и отлетел на всех форумах.
Анализ - Введение
Сам софт состоит из 2 главных частей:
Анализ - Native
Как обычно начнем со скана в DiE:
Ничего примечательного нет, как и после просмотра в CFF. Поэтому открываем семпл в IDA:
Кликаем по __tmainCRTStartup и находим пользовательский EP:
Переключусь сразу в псевдокод:
Для начала разберемся с динамическим импортом, подгружаем нужный модуль через LoadLibraryW, дергаем из него функцию через GetProcAddess.
Теперь займемся расшифровкой .NET файла:
Расшифровка будет похоже на ту, что была в Racoon. Переносим ключ в буффер:
Копируем тот же цикл:
Далее нужно получить массив с зашифрованным бинарником, для этого делаем дабл клик по byte_40F0C8:
И ПКМ -> Array -> OK:
В меню IDA жмем Edit -> Export Data, выбираем С unsigned char array и ставим галочку у Save data to clipboard:
Далее вставляем это, желательно, в отдельный файл:
И далее дописываем цикл:
Прописываем запись бинарника на диск:
И запускаем программу:
Проверяем, что успешно расшифровали:
.NET Бинарник расшифрован, обычным статическим анализом, ничего мудреного. Толку от подобного шифрования действительно мало.
В данном случае адрес (*(*v48 + 12)) - является адресом функции GetRuntime. Где первым аргументом передается версия .NET для подгруза.
Итого по нативной обертке:
Снова начнем с DiE:
Видим целый веер протекторов, но это нам не мешает открыть файл в dnSpy:
Видим кучу треш-кода, который нельзя так просто вычистить через de4dot, но как минимум поверхностно проанализировать сможем. Софт является многопоточным, после прохождения всего того треш-кода, запускаются новые потоки:
Внутри каждой такой функции могут создаваться еще больше новых потоков. Далее анализировать смысла совсем нет, понять все очень трудно, но можно, например, как здесь увидеть название ManagementObject и понять, что это функция, которая создает запросы WMI:
Но на этом анализ .NET не заканчивается, ведь это C#, и получаем:
Но для свежести картины, загрузим семпл версии 3.0:
Домен все также в голом виде.
Заключение
Иногда хочется просто промолчать и только кинуть загадочный взгляд, а потом прошептать:
Предисловие
Ничего не предвещало беды, даже намека на разбор, но раз уж проект закрылся, то думаю пора, хотя бы с научной точки зрения...
Стоит упомянуть еще пару деталей:
Почему проект закрылся? - По словам селлера, кодер ушел работать в приват, оставив софт без дальнейших обновлений, поэтому проект закрылся, так как никто его больше поддерживать не сможет.
Были ли шеллы в панелях балдра? - Ссылаясь на слова кодера - нет. Дело в том, что в админке нашли дыру и по ней грузились шеллы, а потом уже выкачивались логи. Все бы ничего, если бы это происходило не сразу, как с KPOT, дыры находили и по мере поступления новых панелей заливали шеллы, но вот только не с Baldr, шеллы залили всем и сразу, на все панели, которых на трекерах и так очень много. А правда это или нет, я уже не знаю.
Причастен ли overdot? - Сложно сказать, но мое мнение: нет. Он просто селлер, от него в этой ситуации ничего не зависело. Но как селлер, он и отлетел на всех форумах.
Анализ - Введение
Сам софт состоит из 2 главных частей:
- Обертка, написанная на C++
- Сам софт, написанный на C#
Анализ - Native
Как обычно начнем со скана в DiE:
Ничего примечательного нет, как и после просмотра в CFF. Поэтому открываем семпл в IDA:
Кликаем по __tmainCRTStartup и находим пользовательский EP:
Переключусь сразу в псевдокод:
Для начала разберемся с динамическим импортом, подгружаем нужный модуль через LoadLibraryW, дергаем из него функцию через GetProcAddess.
Теперь займемся расшифровкой .NET файла:
Расшифровка будет похоже на ту, что была в Racoon. Переносим ключ в буффер:
Копируем тот же цикл:
Далее нужно получить массив с зашифрованным бинарником, для этого делаем дабл клик по byte_40F0C8:
И ПКМ -> Array -> OK:
В меню IDA жмем Edit -> Export Data, выбираем С unsigned char array и ставим галочку у Save data to clipboard:
Далее вставляем это, желательно, в отдельный файл:
И далее дописываем цикл:
Прописываем запись бинарника на диск:
И запускаем программу:
Проверяем, что успешно расшифровали:
.NET Бинарник расшифрован, обычным статическим анализом, ничего мудреного. Толку от подобного шифрования действительно мало.
Осталось только рассказать про CLRHosting, который использует Baldr для загрузки стиллера в память. Использует он .NET v4.030319 Runtime, который установлен далеко не у всех, как например, на многих Windows 7, поэтому на них стиллер не отработает:
В данном случае адрес (*(*v48 + 12)) - является адресом функции GetRuntime. Где первым аргументом передается версия .NET для подгруза.
Итого по нативной обертке:
- Динамический импорт остался без использования кастомного GetProcAddress, имена всех функций и модулей не зашифрованы
- Шифрования бинарника, сделанное для галочки (в версии 3.0+ алгоритм поменялся, но распаковать также многого не стоит)
- Зависимость от .NET 4.0
Снова начнем с DiE:
Видим целый веер протекторов, но это нам не мешает открыть файл в dnSpy:
Видим кучу треш-кода, который нельзя так просто вычистить через de4dot, но как минимум поверхностно проанализировать сможем. Софт является многопоточным, после прохождения всего того треш-кода, запускаются новые потоки:
Внутри каждой такой функции могут создаваться еще больше новых потоков. Далее анализировать смысла совсем нет, понять все очень трудно, но можно, например, как здесь увидеть название ManagementObject и понять, что это функция, которая создает запросы WMI:
Но на этом анализ .NET не заканчивается, ведь это C#, и получаем:
Но для свежести картины, загрузим семпл версии 3.0:
Домен все также в голом виде.
Заключение
Иногда хочется просто промолчать и только кинуть загадочный взгляд, а потом прошептать: