AURA STEALER — Уничтожение | Credit: LLCPPC
Наш друг реверс-инженер LLCPPC подготовил очень интересный разбор "новенького" Aura Stealer. В статье вы узнаете о том, что AURA STEALER - это низкокачественная копия LummaC2 с уязвимостями в шифровании.
Приветствую всех читателей! В связи с последними событиями, нечасто на рынке можно встретить какие-либо интересные новые стиллеры с особенностями. Полистав BHF, я наткнулся на некий AURA STEALER.
Сегодня будем разбираться, что он из себя представляет. Присаживайтесь поудобнее, статья будет длинная... Я постарался собрать максимально много материала, здесь будет много полезной информации, от полностью ревёрснутого C&C трафика стиллера, до полностью дампнутых конфигов стиллера.
Не пытайтесь прочитать эту статью быстро. Просто наслаждайтесь, читайте внимательно и запоминайте каждое слово...
Fully translated article to English: https://telegra.ph/Reverse-Engineering-AURA-STEALER--Just-a-Low-Quality-Knockoff-of-LummaC2-07-27
Полностью переведённая статья на английский: https://telegra.ph/Reverse-Engineering-AURA-STEALER--Just-a-Low-Quality-Knockoff-of-LummaC2-07-27
Затрачено на написание статьи: 6 часов
Данная статья была написана полностью бесплатно, все мои кряки и проекты также бесплатные. Если вы хотите поддержать мою работу, можете отправить донат, буду рад любой сумме: https://t.me/send?start=IVRigWhaNkzB
Группа: https://t.me/LLCPPC_ALIVEСайт: https://LLCPPC.xin
LLCPPC — кто такой?
Данная статья, вероятнее всего, разлетится по многим форумам и различным источникам информации и некоторые люди услышат обо мне впервые...
LLCPPC (то есть, я) — псевдоним ревёрс-инженера, который с 2021-го года занимается деятельностью по дестабилизации рынка вредоносного ПО. Под дестабилизацией имеется в виду нанесение любого ущерба вредоносным проектам.
В первую очередь, я — против вредоносного ПО, но занимаюсь борьбой своими методами. Первой моей атакой был кряк MarsStealer с последующей статьёй по его разоблачению. На проект обрушилась волна ненависти, продажи упали и он впоследствии закрылся.
За 5-й год работы мне удалось собрать вокруг себя команду таких же хороших ревёрс-инженеров и пентестеров, в свободное время в своей группе мы иногда занимаемся совместными атаками — DDoS и ревёрс-инжиниринг панелей вредоносных проектов, деанонимизация и слив информации авторов вредоносных проектов (например, атака против CellikRAT) и, конечно же, кряки — этим занимаюсь только я.
В качестве лица проекта я использую Декстера Моргана (из сериала "Декстер") — так я представляю свою работу, когда занимаюсь кряком стиллера или его разбором.
Описание проекта и первые впечатления
Первое, что видит покупатель — оформление и описание темы, с этим трудно поспорить. Ссылка на тему на форуме BHF: https://bhf.pro/threads/710309/
На данном этапе необходимо запомнить все ключевые моменты и тезисы, поскольку в дальнейшем будет рассматриваться то, насколько продукт соответствует описанию.
Встречает нас цена - 295-585$. В нынешних реалиях — завышена, учитывая, что проект вообще не подразумевает наличие качественного крипта или обхода антивирусов. Рекомендую прочитать мою статью о том, почему сейчас рынок вредоносного ПО стагнирует: https://telegra.ph/Agoniya-07-12
Вес: 500-700 килобайт. Забегая вперёд, соответствует описанию.
Динамический конфиг, как у LummaC2, StealC и других стиллеров (основываясь на тезисе "в любой момент вы можете добавить в конфиг сбора любое приложение или расширение за пару кликов").
Серверная дешифровка — как и у LummaC2 и StealC. Что привлекло внимание — "свой шеллкод для дешифровки App-Bound", проверим качество шеллкода.
Раздел "О нас" пропускаем, поскольку написано нейросетью и содержит пустые слова... Идём дальше...
Подмечаем: импорты скрыты (или поддельные), строки зашифрованы, ApiHammering, шифрование трафика через AES-256 и HTTPS протокол, анти-СНГ, анти-отладка (по заявлениям авторам, прям заставит плеваться (нет)).
Ниже автор снова кидает нам повторяющиеся тезисы:
О вкусах не спорят, конечно. Кому-то цветовая схема панели понравится, но по моему личному мнению — подобраны цвета очень плохо. Зелёный слишком сильно выделяется, слишком токсичный оттенок.
Больше ничего полезного в теме нет, поэтому можем переходить к следующему этапу.
Качество поддержки после приобретения
Данная статья — первая статья, которая была написана в присутствии реального пользователя и подписчика проекта, благодаря чему у меня есть реальные переписки и реальные эмоции человека от использования продукта.
Как заявляет пользователь, после получения доступа, в первый же день пользователь не смог зайти в панель — у них упал провайдер.
На следующий день панель заработала, но очередной косяк — в последней версии билда, которая как раз попалась покупателю — билд не работал! Вот так... Долгое время AURA отнекивался, мол, всё работает — но по итогу признали ошибку...
На форуме BHF есть один интересный пункт в правилах при публикации приватного ПО — СТРОГО работающий и проверенный продукт. По моему личному мнению, здесь явное нарушение.
Также на жалобы покупателя — AURA назвал покупателя "предвзятым и засланным от конкурентов"... Наверное, такое должно быть отношение за 295$?
"Никто так не докапывается, купил — терпи!".
Первое разочарование — статический анализ билдов
Благодаря прямой связи с покупателем, у нас есть разные версии билдов и мы можем оценить их соответствие описанию.
Повторю тезисы: импорты скрыты (или поддельные), строки зашифрованы, ApiHammering, шифрование трафика через AES-256 и HTTPS протокол, анти-СНГ, анти-отладка (по заявлениям авторам, прям заставит плеваться (нет)).
Открываем 3 разных билда РАЗНЫХ версий в CFF Explorer и обращаем внимание на импорт-таблицу и строки...
Импорт-таблицы билдов ВООБЩЕ не отличаются и никак не скрыты. Без шуток — у стиллера взаимодействие с серверов происходит через WinHTTP, и эти функции никак не скрыты. Никакого заявленного морфинга импорт-таблиц между билдами — нет!
Хорошо... Может, строки у нас хотя бы зашифрованы?...
Но и строки тоже нормально не зашифрованы! User-agent и некоторая часть путей просто торчит наружу, у всех 3-х билдов РАЗНЫХ версий... Молодцы!
Динамический анализ — тест на качество не пройден
Напоминаю: импорты скрыты (или поддельные), строки зашифрованы, ApiHammering, шифрование трафика через AES-256 и HTTPS протокол, анти-СНГ, анти-отладка (по заявлениям авторам, прям заставит плеваться (нет)).
Стиллер имеет проверку на наличие крипта. И если крипта нет — выдаёт вот такую вот капчу:
Как именно происходит проверка на крипт я не смотрел — но можно догадаться, вариантов тут много. Где-то внутри PE оставлен флаг, либо хеш секции .text, либо хеш всего исполняемого файла (да, если что, программа может прочитать саму себя во время исполнения и вычислить хеш самой себя).
Сначала оценим страшнейшую и безжалостную анти-отладку... Но её толком нет... Авторы заявляют в теме, что её отключить нельзя. В билдере покупатель отключил для меня только anti-VM, чтобы я мог тестировать билд на виртуальной машине. Проще говоря, анти-отладка скорее всего обходится самым обычным ScyllaHide с пресетом на VMProtect\Themida... После установки ScyllaHide — можете ревёрсить билд вдоль и поперёк.
Итак, открыв в отладчике билд, думаем о том, какие у нас могут быть, скажем так, "метки" для поиска главного цикла\главной функции. В самом начале код содержит много мусора и обфусцированных блоков инструкций. Возможно где-то там есть пародия на динамический импорт или какие-либо операции, но всё, что идёт ДО основного функционала стиллера — мы будем пропускать, потому что ранее уже выявили, что стиллер буквально кричит о том, какие функции он использует, поэтому если и есть какие-либо динамические операции в начале — это полностью бессмысленные операции, ведь стиллер использует winhttp? Использует. В импорт-таблице он есть? Есть. Поэтому скрытия импорт-таблицы толком никакого нет.
Вернёмся к меткам... Критическим местом стиллера является анти-СНГ. Ведь в теме автор сам признался, что проверка в стиллере реализована через проверку раскладки и языка системы. А какие функции используются для этого в WinAPI — в основном, GetUserDefaultLCID, GetSystemDefaultLCID, GetSystemDefaultLangID, GetUserDefaultLangID, GetUserPreferredUILanguages, GetSystemPreferredUILanguages, GetKeyboardLayout и другие. Также может использоваться GetTimeZoneInformation
Для чего вам эта информация? Как я очень давно учил, ревёрс-инжиниринг это не просто обратная разработка программы, это восстановление МЫСЛЕЙ разработчика. Поэтому чтобы стать ревёрс-инженером — важно самому быть разработчиком. Ставим бряки на все вышеперечисленные функции, настраиваем ScyllaHide и ловим нашу первую главную функцию стиллера — функция анти-СНГ. Выглядит она так:
Да, она абсолютно никак не обфусцирована прыжками. Вот такой просто голый блок инструкций, где вызываются функции типа GetUserDefaultLCID, и возвращает она - 0 (не-СНГ) или 1 (СНГ).
Как видим из скриншота, указатели действительно обфусцированы, поэтому вызовы функций не будут парситься через IDA Pro и x32dbg.
После получения языка системы, дальше идут вызовы GetLocaleInfoA — данная функция по коду возвращает язык строкой. Конечно, вредоносное ПО — не то место, где стоит ругать за оптимизацию, но намного проще было сделать тут проверку кода на код (0x419 == 0x419, а не "RU" == "RU"), без использования строк. Как сделано у MarsStealer, например. Так что реализацию можно считать плохой.
Стек вызовов никак не скрывается, поэтому кликнув в стеке на возврат — мы возвращаемся в самую главную функцию — именно из неё вызвалось анти-СНГ. А поскольку стиллер действительно написан на С\С++, то никакой виртуальной машины или обёрток над стеком вызовов у него нет (как у GoLang, например). Поэтому функция — наша.
У главной функции уже есть обфускация прыжками, что радует. Но она достаточно слабоватая и легко прослеживаются главные и необходимые моменты. Если ревёрсер знает ассемблер, конечно же. Проверяются в билде классические страны СНГ, расписывать их не буду.
Также пройдусь по тому, что действительно есть — ApiHammering. Да, стиллер действительно генерирует мусор в папку %TEMP% — это поддельные логи. Авторы заявляют (и возможно действительно так думают), что это поможет для обхода антивирусов.
На деле же — нет, не поможет. Но стоит отдать должное — шаг по обходу машинного анализа действительно сделан. Ведь старые методы по обходу антивирусов подразумевали под собой генерацию мусора или какой-либо полезный функционал по защите — операции с кодом, процессами и прочим. Теперь же, поскольку антивирусами управляет нейросеть — важно делать свой функционал максимально легитимным. Поэтому шаг частично правильный, но всё ещё очень слабый.
Также стоит подметить, что это очень сильно выделяет стиллер из всех других стиллеров. Ну, прям очень сильно! И далее это сыграет нам на руку, ведь на днях мне скинули билд, который работает по СНГ, и у него имено такая же генерация логов. Впереди ещё много интересного...
Итак, для отладки нам потребуется обойти анти-СНГ. Как его обходить? У нас есть 2 вызова функции. Часто внутри функций спрятаны дополнительные флаги, которые далее проверяются глубоко в коде. Поэтому просто подделать ответ функции или пропатчить ветвление — вариант ненадёжный. Необходимо патчить ответы системных функций.
В самом начале функции анти-СНГ у нас легко прослеживаются два вызова. Один (GetUserDefaultLCID) — я подменил на уровне системы, просто поменял язык по-умолчанию.
Однако второй — GetSystemDefaultLCID возвращает 0x419, это "русский", что входит в СНГ. Меняем ответ на 0x409 (США), готово — анти-СНГ для отладки успешно обошли (ну, и прокси поверх виртуальной машины, естественно).
Теперь мы можем спокойно и свободно копать под любые функции стиллера!
Ловим первый запрос на: https://glossmagazine.shop/api/live
Как уже было сказано ранее, стиллер использует WinHTTP для запросов. А именно — функции WinHttpSendRequest, WinHttpReceiveResponse и др.
https://glossmagazine.shop/api/live возвращает "true" — скорее всего, эта страница используется для информирования стиллеру о том, что мост в рабочем состоянии.
После отправки запроса идёт конвертация json bool в 0\1 для валидации ответа от сервера:
Функция на скриншоте возвращает 0 или 1 в зависимости от ответа сервера (соответственно "false" и "true"), далее идёт ветвление.
Немного пошагово походив по коду, ловим целый расшифрованный конфиг стиллера. Строка "Global\4cZaWSGRxYzaSDOsVFr" скорее всего отвечает за мьютекс, а дальше идут зашитые мосты стиллера прямо внутри билда!
Мосты у билда следующие:https://armydevice.shophttps://opencamping.shophttps://glossmagazine.shop
Далее ловим самый сок — формирование запроса! Сначала идёт build_id:
Пока мы не дошли до полного расшифрованного и ревёрснутого запроса ДО шифрования AES-256, напомню:
"AntiDebug - противные методы антиотладки тесно интегрированные с нашими технологиями. Заставят плеваться даже матёрых ревёрсеров. Отключить антиотладку в панели нельзя".
Я не считаю себя "матёрым ревёрсером", я вообще скорее обычный программист на ассемблере, но могу заявить — антиотладка полный отстой.
А теперь внимание! Я собрал полноценный расшифрованный и голенький запрос на C2:
{"build":{"build_id":"9f6947f2-bea1-4ffd-b7a3-44acb2ad7395"}}
К слову, хочу напомнить об очередном тезисе — скрытие аргументов вызовов функций. Дело в том, что они никак не скрываются!
Смотрите, на вызове функции в регистре ECX, мы видим чётко 3 аргумента, они никак не скрыты. Данная функция - и есть шифрование AES-256.
Следом за вызовом ECX идёт шифрование в Base64 через CryptBinaryToStringA. Прекрасно, прекрасно! А зачем было делать такое крутое шифрование, если мы таким легчайшим способом всё вывернули наизнанку?)
Далее вызов EAX — это и есть отправка запроса. Вот таким тупейшим способом стиллер: зашифровал в AES-256, зашифровал в Base64, отправил.
После отправки запроса ловим конфиг стиллера, такой же сырой и голый, но очень круто изначально зашифрованный в AES-256, похлопаем же их шифрованию (сарказм)!
Конфиг достаточно большой, опубликовал его сюда: https://pastebin.com/Hy0cSpgg
Всего в конфиге содержится 211 заданий для стиллера. Это достаточно жирно, спорить не буду. Также функционал стиллера управляется прямо из панели, что хорошо. Например, в любой момент авторы могут убрать из конфига "screenshot", и стиллер перестанет его собирать:
Зашифрованные в AES-256 запросы отсылаются через POST form-data на URL: /api/send или /api/conf
"name" формы зависит от последовательности. Каждый запрос нумеруется: data, data1, data2, data3
Первым, соответственно, идут build_id, в ответ - конфиг. Вторым - собранная информация с ПК. Пример расшифрованного data1:
{"build":{"build_id":"9f6947f2-bea1-4ffd-b7a3-44acb2ad7395","hwid":"--efd--2-fb56-4808-a624-9cf0a02aa667","uuid":"6795036d-baa9--a66-95-7-e22-4d720-b1"},"info":{"archive_entry":"Microsoft Edge","name":"Microsoft Edge","type":"chromium"}}
В data2 соответственно находятся данные. В data1 - информация о данных (build_id, type, name), в data2 - данные.
Так полностью выглядит структура запроса начиная с data1 и data2:
Граббер отправляет файлы в ZIP-формате. Вот так выглядит лог собранного граббера:
Ну, далее не вижу смысла разбирать запросы, поскольку они очень легко ревёрсятся. Подметим лишь начало, которое может пригодится пентестерам.
Первым запросом на /api/send идёт следующее:
{"build":{"build_id":"9f6947f2-bea1-4ffd-b7a3-44acb2ad7395"}}
Данную строку надо зашифровать в AES-256 (ключа, к сожалению, нет, но можно использовать билд как контейнер и через Frida подменять там данные на свои), а затем в Base64 (CryptStringToBinaryA) и отправить через form-data с name="data". В ответ придёт конфиг размером в 42 килобайта. Что интересно - аккаунт покупателя был давно заморожен и доступ к нему ограничен, однако конфиги панель всё равно возвращает.
Вторым запросом идут уже сами собранные данные, на основе конфига. Это могут быть "Local data" от Edge или Chromium, или же "Important Files" (граббер) в виде ZIP-файла.
В принципе, C&C очень схож с LummaC2, но что его отличает от LummaC2? Во-первых, у StealC и LummaC2 намеренно скрыты все ключи. Вместо них только "a1", "b1" и т.д. - это максимально затрудняет ревёрс. Потому что непонятно, какой ключ что в себе хранит и для чего нужен.
В AURA Stealer же - ключи кричат сами о себе ("build", "build_id", "type", "name" и т.д.). Это достаточно глупо...
Вернёмся к функции шифрования, выглядит она так:
Состоит она из внутренних подфункций и передаются в неё следующие аргументы: aes_encrypt(указатель_на_выходные_данные, исходные_данные, размер)
Возвращает функция указатель на зашифрованные данные, в ecx - размер зашифрованных данных.
Среди аргументов ничего похожего на ключ нет. Значит ключ (и IV?) скрыт внутри функции и один ключ используется на все запросы и никак не генерируется. Грустненько.
В общем, ключ я искать не стал, потому что лично я для пентеста использовал бы билд как контейнер - его легко перепатчить и внутри него нет никаких функций антиотладки (по крайней мере, адекватных и стойких). Все запросы можно патчить прям в отладчике, ставить неправильные конфиги, слать на сервер неправильные запросы и т.д.
Ладно, знаете, что смешно? Пока я писал статью, я на время отпустил билд и решил поснифать запросы, и увидел просто невероятно смешную картину - билд собрал лог на 13 мегабайт, но не смог отправить на сервер, потому что nginx начал выдавать 413 "Request too large". Мосты AURA Stealer неправильно настроены, представьте сколько логов теряют клиенты!
После получения 413 - билд не останавливается, а отправляет запрос на /api/live чтобы проверить, жив ли сервер, и снова фигачит тот же лог!
По итогу, мосты просто долбятся клиентами и потому достаточно очевидно, почему панель так медленно работает и задыхается.
Во-первых, потому что панель и API у них не разделены и работают на одном сервере. А во-вторых, потому что API долбится кривым клиентом.
Только на этапе ревёрса панель начала выдавать скорость отклика чуть ли не в 5 в секунд... Стиллер спасает лишь то, что у него мало клиентов. Когда клиентов будет много - панель просто умрёт, если они не перепишут эту логику.
Итак, снова вернёмся к шифрованию. Извините, но эта тема меня очень сильно интересует. Дело в том, что ключи у стиллера действительно одинаковые ВСЕГДА, на все билды и на все запросы.
Чтобы доказать это - из HTTP Debugger я скопирую запрос и отправлю его ещё раз. Если бы ключи генерировались - сервер должен был бы отклонить мой запрос. Но что я получил? true!
Нет... В том, смысле, что я получил действительно "true" - ответ от сервера. А что это значит? Правильно, вы можете скопировать самый, мать вашу, огромный запрос стиллера, который уже правильно зашифрован в AES-256, и начать им долбить мосты! Я на 100% уверен, что мосты от таких действий просто лягут намертво. Ведь стиллер не генерирует ключи (а зачем?), у стиллера на все запросы один ключ, поэтому долбим сервера, ребятки, не стесняемся!
Тук-тук, это шеллкод?
Напомню: по заявлениям авторов, у проекта есть "уникальный" шеллкод для извлечения данных из Chrome
Для теста шеллкода мне пришлось установить последний Chrome на свою виртуальную машину. В данном анализе меня интересуют лишь следующие вещи:
- Стиллер 32-х битный, Chrome — 64-х битный. Неужели авторы сделали инъекцию через Heaven's Gate?
- Качество шеллкода — он написан на ассемблере, или же это просто конвертированный код из С\С++ в шеллкод через какие-то кривые библиотеки или генераторы?
Итак, первое обращение к Chrome я словил в этой функции. Тут стиллер открывает процесс Chrome.exe с правами:PROCESS_TERMINATE PROCESS_VM_READ PROCESS_QUERY_INFORMATION
Процесс под этим PID - оказался дочерним. Далее стиллер находит PID 4932, который является главным Chrome.exe и пытается открыть уже его...
После успешного открытия — стиллер замораживает процесс Chrome.exe (после такого - высока вероятность словить обнаружение со стороны антивируса, без шансов):
А затем... Просто читает "Cookies" через IO путь \\?\ ... ? Честно, я прогнал все запросы билда, поставил хуки на OpenProcess и любым обращениям к процессам, также мониторил записи в Chrome.exe - но никакого шеллкода я не нашёл! Не знаю, что имелось в виду там под шеллкодом, но, увы, самое интересное для меня - я проверить не смог...
Я предположу одно - авторы не осилили Heaven's Gate... И не удивительно, проект написан на С\С++, вполне вероятно - самыми типичными программистами на С\С++. Они явно не знают, что такое Heaven's Gate. Пару раз попытались сделать инъекцию, ничего не получилось, ну... И на этом всё. Никакого шеллкода нет, друзья!
AnyRun
По моим наблюдениям, для стиллера очень важно иметь хорошую защиту от песочниц. По мере роста популярности проекта, на него обратят внимаание все Threat Intelligence платформы, а значит каждый билд будет сливаться на такие платформы, как AnyRun.
AnyRun, на самом деле, достаточно особенная платформа — она имеет мощные снифферы и анализаторы трафика. Так, например, она обнаруживала 90% всех билдов LummaC2, помечала их на своей платформе и даже могла расшифровывать конфигурации стиллера!
Как же дела обстоят с AURA Stealer? https://app.any.run/tasks/61c23f11-2ba3-4aa4-b1af-4497abfe0f62
На самом деле, ожидания уже давно отпали — после осознания того, что ключ на всём трафике у стиллера один... После того, как у билда обнаружились незащифрованные строки и незашифрованная импорт-таблица... После того, как я не столкнулся с ожидаемой "мощной" анти-отладкой... В целом, после всего, что я описал выше.
Стиллер... Ну, объективно, ужасен. Я не собирался писать статью с откровенным хейтом, но проект сырой и плохой. С медленной панелью, с кучей уязвимых мест, у проекта всего 4 сервера, и все они вшиваются прям в билд — вероятность убить все билды просто огромная. Если спецслужбы арестуют все 4 домена — проект умирает...
Это ещё не конец
После публикации статьи, мне пришёл ответ от автора...
С радостью разберу его претензии:
1) "скрываются апишки которые используются в нашем коде" - WinHTTP в коде используется, BCrypt в коде используется, kernel32 в коде используется - почему не скрыто? Или автор хочет сказать, что WinHTTP использует CRT? Нет, не использует. Вообще неясно, что автор имеет в виду. Просто высер, если честно.
Про шифрованные хеш-таблицы как-то пофиг, честно... Буду я сейчас 3 часа подробно билд разбирать и разбираться в таких подробностях... Это никого не волнует, как вы там круто хеш-таблицы сделали... На что это повлияло? Будем честны. Я всё ещё легчайшим образом вывернул все функции API и похукал все функции, так же легчайше перехватил все расшифрованные конфиги и команды. Что ваша хеш-таблица дала? Все импорты торчат наружу... Молодцы, сделали хеш-таблицу. Только по-факту ничего она не дала.
2) в строках есть пути к браузерам, это Defender просто с вероятностью 90% не пропустит никогда. А так, учитывая что крипт в любом случае нужен (который не поможет тоже) - тогда пофиг. Но это плохо всё равно.
3) хорошо, ключи генерируются. Только вот ключи генерироваться должны не на клиенте. В клиенте AURA более-менее скрыто шифрование AES256. В плане, что будет лень разбирать реализацию. Если бы они сделали генерацию со стороны сервера - было бы вообще без вариантов подделать запрос - искусственно отправить запрос не получится (сервер ключ сменил), подделать запрос - тоже (IV неизвестен, придётся ревёрсить долго).
Гении же сделали генерацию в клиенте, ЕЩЁ и ключ прямо в запросе! Поэтому я тупо копировать запросы могу и сервер хавать их будет. Просто бред... Переписывайте.
4) тоже как-то не интересно... Панель стиллера логи не принимает и выдаёт 413 "Request too large", а я тут буду восхищаться такими посредственными вещами... Сделайте стиллер рабочим для начала.
Хочется напомнить, что автор долгое время убеждал покупателя, что билд рабочий (когда он был нерабочий). Поддержка у сервиса невероятно сильно хромает, авторы думают, что только они всегда и во всём правы, только у них всё лучшее, а кто не согласен - тот говно. И данный ответ - очередное тому подтверждение. Ушли в полную крайность защиты себя, даже там, где они на 100% не правы.
Подведём итоги
Я очень надеюсь, что вы были паинькой и прочитали статью очень внимательно. Если это так — значит вероятнее всего, вы, как и я, тоже разочарованы в этом проекте. Хорошего мало...
Стоит ли надеяться на то, что проект обновят? К счастью, не думаю. Скорее всего, этот проект недолгосрочный. Да, обычный скам-проект, как и многие стиллеры сейчас. Одно отличает его от других — над ним чуть-чуть постарались. Сделали серверную дешифровку. Но стиллер всё ещё не дотягивает до качественного продукта.
Билды стиллера найдёте у меня в чате Телеграм. Там же можете задать у меня какие-либо интересующие вас вопросы.
Автор: LLCPPC | Поддержка: https://t.me/send?start=IVRigWhaNkzB
Группа LLCPPC: https://t.me/LLCPPC_ALIVE