• Данный раздел создан исключительно для релизов! Вопросы по лаунчеру или обвязке задавайте ТОЛЬКО в соответсвующей теме автора. Любые другие темы будут удалены, а авторы понесут наказание.

Лаунчер [C++17] Avanguard

HoShiMin

Старожил
Пользователь
Баллы
173
Avanguard
The Win32 Anti-Intrusion Library​

Из-за отсутствия времени на коммерческую поддержку и доработки, выкладываю проект в открытый доступ. Продолжение проект получит в виде переписанного с нуля (и, скорей всего, приватного) Avanguard 2.0 с учётом всех недостатков существующей архитектуры.

Итак, Avanguard - защита от всех видов нативных инжектов для Windows с биндингами для всех популярных языков: C++, Java, C# и Delphi. Поддерживает любые программы (не обязательно Minecraft). Есть возможность подключить защиту без модификации исходного кода программ.

Возможности:
1. Статический криптор кода
2. Множество антиотладочных трюков (WinAPI, NativeAPI, трюки с SEH и ассемблером)
3. Библиотека для анализа PE-файлов
4. Анализатор памяти и поиск чужой памяти в нашем адресном пространстве
5. Анализатор стека вызовов и поиск посторонних фреймов в стеке
6. Защита от инжектов через CreateRemoteThread, AppInit_DLLs, оконные хуки, от ручного маппинга памяти, угона контекстов через NtSetContextThread/NtContinue, от инжекта через доставку APC
7. Защита памяти (ремаппинг исполняемой памяти с ReadOnly-правами, поддержка ядерных каллбэков)
8. Защита от сплайсинга и патча IAT (проверка исполняемых секций и таблицы импорта)
9. Анти-макросы (фильтр виртуального ввода, могут потребоваться права администратора)
10. Функционал для поиска лишних загруженных драйверов (не включен по-умолчанию)
11. Каллбэки на создание новых потоков и загрузку новых библиотек
12. Закрытие хэндлов нашего процесса в чужих процессах (экспериментальный функционал, unstable) - поможет от редакторов памяти при наличии прав администратора
13. Поддержка самомодифицирующегося кода: приложение может ставить свой перехват, защита не станет считать это угрозой
14. Поддержка исполнения из TLS-каллбэков
15. Ограничение прав доступа к процессу через DACL'ы
16. API для получения HWID'ов: CPUID, Physical HDD Serial, парсинг SMBIOS (SystemInfo, BIOS Info, BaseboardInfo)
17. Поддержка проверок сертификатов и цифровых подписей загруженных библиотек
18. API для вызова функций защиты извне
19. Каллбэки на найденную угрозу с возможностью выбора, что делать дальше

Сборка:
Visual Studio Community 2017 (или Insider Preview)
Открыть Avanguard.sln -> Выбрать параметры сборки (Win32/x64 и Debug/Release) -> Ctrl+Shift+B
Готовые бинарники будут в соответствующих папках Debug/Release или x64/Debug и x64/Release.

Настроить функционал защиты, проверяемые библиотеки и поведение можно в файле "Avanguard/AvanguardDefence/AvnDefinitions.h"

Запуск:
Запустить защиту можно двумя разными способами: статическим и динамическим.

Статическая загрузка:
Библиотека загружается раньше всех через пропатченную таблицу импорта, автоматически запускается защита. Не требует изменения исходного кода. Рекомендуемый способ.
1. Скачать CFF Explorer
2. ПКМ по целевой программе (например, java.exe или javaw.exe), в которую хотим загрузить защиту
3. Open with CFF Explorer
4. Переходим в боковую вкладку Import Adder
5. Add -> Выбираем Avanguard.dll
6. В списке Exported functions выбираем Stub -> Import by name
7. Rebuild Import Table
8. Переходим в боковую вкладку Import Directory -> ПКМ по Avanguard.dll -> Move Up
9. Поднимаем его на самый верх, чтобы был первым в списке
10. Save (большая кнопка с дискетой наверху)
11. Закрываем CFF Explorer, кладём Avanguard.dll в папку с программой, готово

Динамическая загрузка:
Загрузка и запуск динамически в коде программы. В этом случае библиотека будет подгружена вашим кодом. Требует запуска через AvnApi.
Для C++, Java, C# и Delphi есть биндинги, позволяющие загружать библиотеку и запускать через AvnApi.
Биндинги расположены в папке "# Bindings", биндинг для C++ в заголовочнике "Avanguard/AvanguardDefence/AvnApi.h".

Пример для запуска из Java:
Java:
    public static void main(String[] args) {
        // Ставим уведомлялку о срабатываниях защиты:
        AvnBind.avnRegisterThreatNotifier((int threatType) -> {
            System.out.println("Threat " + AvnBind.ThreatType.getThreat(threatType).name());
            return true;
        });

        // Запускаем защиту:
        AvnBind.avnStartDefence();

        // Эмулируем срабатывание (в каллбэк придёт уведомление):
        AvnBind.avnEliminateThreat(AvnBind.ThreatType.UNKNOWN_APC_DESTINATION.getValue());

        // Отключаем каллбэк и снова эмулируем срабатывание:
        AvnBind.avnRegisterThreatNotifier(null);
        AvnBind.avnEliminateThreat(AvnBind.ThreatType.UNKNOWN_APC_DESTINATION.getValue());
    }

Пример для запуска из C++:
Код:
#include "AvnApi.h"

// Подгружаем dll в процесс и импортируем API:
HMODULE hAvn = GetModuleHandle(L"Avanguard.dll");
PAVN_API AvnApi = *(PAVN_API*)GetProcAddress(hAvn, "Stub");

// Запускаем защиту:
AvnApi->AvnStart();

// Используем AvnApi:
AvnApi->Lock();
BOOL IsModuleValid = AvnApi->AvnIsModuleValid(hAvn);
// ... Other AvnApi calls ...
AvnApi->Unlock();

Использование каллбэков:
Если установлен каллбэк на любом языке, то при каждом срабатывании защиты управление будет передаваться в каллбэк, и по результату, возвращённому из каллбэка, будет приниматься решение, убивать ли процесс. Каллбэк возвращает true/false.
true - продолжить исполнение, проигнорировав срабатывание
false - убить процесс
Если каллбэк не установлен, действие по-умолчанию - убить процесс при первом срабатывании защиты.

В некоторых случаях, когда возможно, защита не убивает процесс при сработке, а предотвращает угрозу (например, отменяет доставку APC или создание новых потоков).

Защита создаёт лог в рабочей папке программы в файле AvnLog.log.

Скачать: https://gitlab.com/HoShiMin/Avanguard
 
Последнее редактирование:
Проверка активности DLL через AvnBind.avnIsStarted() или AvnBind.avnIsStaticLoaded()? (для справки)
 
А если насильно выключить Dll?
Тогда у тебя процесс крашнется при попытке вызвать что-то из апишек. Все сторонние программы для выгрузки библиотек так или иначе инжектят. Обычно, CreateRemoteThread(FreeLibrary). С этим защита спокойно справляется.
 
Ждем оценку от @Konstantin773. На сколько годно, или так же порвется универсалкой?
Мало подключить библиотеку - нужно проследить, чтобы из лаунчера\джавы не вырезали её запуск. Как вариант - пустить авторизацию через нативку защиты. Это должны делать уже разработчики лаунчеров.
 
Мало подключить библиотеку - нужно проследить, чтобы из лаунчера\джавы не вырезали её запуск. Как вариант - пустить авторизацию через нативку защиты. Это должны делать уже разработчики лаунчеров.
Допустим, v3 проверка размеров лаунчера/META-INF файлов через LaunchServer. Вырезать, может и смогут, но не пропустит авторизация.
 
Допустим, v3 проверка размеров лаунчера/META-INF файлов через LaunchServer. Вырезать, может и смогут, но не пропустит авторизация.
А лаунчсервер откуда размер лаунчера возьмёт? Пропатчат сам лаунчер, чтобы отсылал серверу правильные данные о размере лаунчера. Не поможет.
Надо или сам кусочек авторизации выносить в нативку, или пусть нативка отдаёт для авторизации какие-нибудь важные данные. А в идеале, конечно, полностью нативный лаунчер.
 
Последнее редактирование:
Ждем оценку от @Konstantin773. На сколько годно, или так же порвется универсалкой?
Зависит от степени интеграции с конечным приложением.

Проверять исполняемый код на наличие изменений/хуков в реальном времени невозможно, защита это делает с определенным интервалом. Это дает рядовому школохакеру огромную возможность:
1. Из левого процесса записать в защищенный процесс произвольный код
2. Тем же способом поставить хук на какую-либо часто используемую процедуру (например, чтобы получить указатель JNI)
3. Произвольный код выполняется
4. Хук и левый код подчищаются
5. PROFIT!!! Защита ничего не заметила, т.к. инжект произошел между N и N+1 проверками

Без переписывания JVM (вставка проверок в критически важные процедуры), практически, никакого ощущения безопасности не даст.

Уверяю, если это дело грамотно интегрировать, то смысл имеет место быть. В абсолют не возвести, но надежды даст.
 
А лаунчсервер откуда размер лаунчера возьмёт? Пропатчат сам лаунчер, чтобы отсылал серверу правильные данные о размере лаунчера. Не поможет.
Надо или сам кусочек авторизации выносить в нативку, или пусть нативка отдаёт для авторизации какие-нибудь важные данные. А в идеале, конечно, полностью нативный лаунчер.
Что там по jmp/хуки и антивирусам? Какая часть кода защиты сможет работать без алярмов?
 
Что там по jmp/хуки и антивирусам? Какая часть кода защиты сможет работать без алярмов?
Если не вылазить за пределы процесса (убрать анти-макросы, закрывалки хэндлов и, возможно, DACL'ы), то антивирусам безразлично. Единственное, что может понадобиться - при статическом импорте пересчитать контрольную сумму пропатченного бинарника, которую можно посмотреть в процесс-хакере и пропатчить в CFF Explorer'e в PE-заголовке программы.
 
Если не вылазить за пределы процесса (убрать анти-макросы, закрывалки хэндлов и, возможно, DACL'ы), то антивирусам безразлично. Единственное, что может понадобиться - при статическом импорте пересчитать контрольную сумму пропатченного бинарника, которую можно посмотреть в процесс-хакере и пропатчить в CFF Explorer'e в PE-заголовке программы.
Понятно, спасибо за ваш труд!
 
Зависит от степени интеграции с конечным приложением.

Проверять исполняемый код на наличие изменений/хуков в реальном времени невозможно, защита это делает с определенным интервалом. Это дает рядовому школохакеру огромную возможность:
1. Из левого процесса записать в защищенный процесс произвольный код
2. Тем же способом поставить хук на какую-либо часто используемую процедуру (например, чтобы получить указатель JNI)
3. Произвольный код выполняется
4. Хук и левый код подчищаются
5. PROFIT!!! Защита ничего не заметила, т.к. инжект произошел между N и N+1 проверками

Без переписывания JVM (вставка проверок в критически важные процедуры), практически, никакого ощущения безопасности не даст.

Уверяю, если это дело грамотно интегрировать, то смысл имеет место быть. В абсолют не возвести, но надежды даст.
Есть 3 идеи, как защититься от быстрых хуков.
Первая - ремапнуть библиотеки джавы с ридонли-правами, тогда VirtualProtectEx обломается, но требует пересборки джавы с выравниванием секций по 64 килобайта.
Вторая - проверять наличие WCX-флага у регионов памяти джавы. После первого изменения WriteCopy сменится на Read Execute, и вернуть его обратно уже нельзя. Мы не узнаем, кто и где что-то поменял, но получим лишь факт того, что в эту страницу производилась запись. А так как джаву мы не хукаем, это основание для срабатывания защиты. Подходит только в случае, если джаву действительно никто не хукает и на протяжении всей игры WCX-флаг остаётся валидным.
И третья - страницам памяти можно задать счётчики, тикающие, если к ним был доступ на запись. Периодически их проверять для библиотек джавы.

И самый простой и одновременно малоприменимый на практике способ - написать драйвер, порезать права при открытии хэндлов, пропатчить EPROCESS для принудительного включения PPL для нашего процесса.
 
Последнее редактирование:
Помер не успев вылезти в паблик. Можно выбрасывать. Столько надежд в пустую.
e6af542b7c.jpg
 
@alexandrage мягко сказано.
1. Это не всё я дальше тестировал, вот только что при тесте с простенькой программой с бесконечным hello world бедная вылетела с ошибкой памяти (через 2 мин и 15 сек)
2. Эта дрянь не даёт пользоваться обфой никакой! При использование обфа (не на классы этой либы (JNI) конечно) краш в помощь.
3. Лишний функционал и говнокод, примеров полно. Течи памяти и т. п. в наличии.
4. Программа не рабочая не спасла от банального Cheat Engine!!!
5. Я очень уважаю людей, которые умеют писать программы, но за такое мало руки оторвать.
6. Программа вызывает ощущение вируса ибо ОС лагает на 4 gb ОЗУ и intel core 2 duo.
P. S. 7. Win XP стало глючить от этой программы, хотя до этого ни разу не глючило. Ну что поделаешь, пришлось перезагружать причём 4 раза ибо не помогало, вроде на 4 раз помогло.
 
@alexandrage мягко сказано.
1. Это не всё я дальше тестировал, вот только что при тесте с простенькой программой с бесконечным hello world бедная вылетела с ошибкой памяти (через 2 мин и 15 сек)
2. Эта дрянь не даёт пользоваться обфой никакой! При использование обфа (не на классы этой либы (JNI) конечно) краш в помощь.
3. Лишний функционал и говнокод, примеров полно. Течи памяти и т. п. в наличии.
4. Программа не рабочая не спасла от банального Cheat Engine!!!
5. Я очень уважаю людей, которые умеют писать программы, но за такое мало руки оторвать.
6. Программа вызывает ощущение вируса ибо ОС лагает на 4 gb ОЗУ и intel core 2 duo.
P. S. 7. Win XP стало глючить от этой программы, хотя до этого ни разу не глючило. Ну что поделаешь, пришлось перезагружать причём 4 раза ибо не помогало, вроде на 4 раз помогло.
Лол, не знаю что там у тебя за программа, но у меня она прекрасно защищает, но в фулл нативке все же есть косяки
 
Тестил лишь сборочку с обфой - обфа обосралась, мои похождения закончились
 
Назад
Верх