Вопрос Защита лоадера

[whynotvoid]

Всем добрый вечер, извиняюсь за странный вопрос и возможное недопонимание, потому что я не C++ разработчик и просто интересуюсь. Можете пожалуйста описать общий принцип защиты по мимо обфускации кода? Я не раз видел как тут засирают проверку процессов по имени перед запуском, но а как можно по другому определить используется ли дебагер и т.п. . У меня в голове это выглядело все примерно так: Пользователь открывает лоадер, и создаётся отдельный поток, в котором по КД проверяется наличие дебагеров, всяких митм и прочих БДСМ штучек, дальше авторизация и при инжекте получение байтиков дллки через какой нибудь tcp. Но мне почему то кажется что чисто по хорошему такой расклад хуевый, хотя он явно лучше чем все лоадера из раздела про кубы

 

[W4tev3n]

Пожалуйста, авторизуйтесь для просмотра ссылки.

Для референса.
Ну и

Пожалуйста, авторизуйтесь для просмотра ссылки.

ещё

 

[whynotvoid]

Пожалуйста, авторизуйтесь для просмотра ссылки.

Для референса.
Ну и

Пожалуйста, авторизуйтесь для просмотра ссылки.

ещё

Спасибо, а по поводу получения чита, как его безопасно можно получить и заинжектить, чтобы его не спиздили и нужно ли делать защиту в самом чите?

 

[class_informer]

Спасибо, а по поводу получения чита, как его безопасно можно получить и заинжектить, чтобы его не спиздили и нужно ли делать защиту в самом чите?

Про получить и заинжектить способов тонна
Делать ли защиту в чите, зависит только от тебя
Не забывай что ломается все, и ты край сможешь усложнить жизнь типу

 

[Divviner]

Спасибо, а по поводу получения чита, как его безопасно можно получить и заинжектить, чтобы его не спиздили и нужно ли делать защиту в самом чите?

отправляй в респонсе пост запроса данные, зашифрованные одноразовым ключём
по поводу защиты в чите: конечно, помимо всей базы должна быть проверка на подключение к серверу и проверка данных авторизации

 

[whynotvoid]

Про получить и заинжектить способов тонна
Делать ли защиту в чите, зависит только от тебя
Не забывай что ломается все, и ты край сможешь усложнить жизнь типу

да, я прекрасно понимаю что все ломается и это лишь вопрос времени, но можно нехило так насрать и усложнить жизнь

отправляй в респонсе пост запроса данные, зашифрованные одноразовым ключём
по поводу защиты в чите: конечно, помимо всей базы должна быть проверка на подключение к серверу и проверка данных авторизации

мне кажется что https запросы как-то не сильно надежно использовать, мне кажется лучше по сокетам зашифрованные байтики отправлять, или все же нормальный вариант https

 

[Divviner]

да, я прекрасно понимаю что все ломается и это лишь вопрос времени, но можно нехило так насрать и усложнить жизнь

мне кажется что https запросы как-то не сильно надежно использовать, мне кажется лучше по сокетам зашифрованные байтики отправлять, или все же нормальный вариант https

а ты думаешь сокеты так сложно отснифать? да и какая разница, если у тебя будет кастомное шифрование?
как по мне - лишняя порнография и нагрузка


upd. хттпс запрос хотя бы не сможет отснифать человек, который просто сидит на роутере, нужен непосредственный доступ и митм

 

[whynotvoid]

а ты думаешь сокеты так сложно отснифать? да и какая разница, если у тебя будет кастомное шифрование?
как по мне - лишняя порнография и нагрузка


upd. хттпс запрос хотя бы не сможет отснифать человек, который просто сидит на роутере, нужен непосредственный доступ и митм

понял, а по защите dll что можно сделать?

 

[desccc]

определить используется ли дебагер

Как минимум проверить, подключен ли дебаггер через syscall, если не подключен, проверить хуки от плагинов, особенно если присутствует протект, и если скрытие дебагера не использует ядро, то этого должно хватать как минимум на мелких недокрекерах.

Если инжектишь чистую DLL или где всего одна проверка, то независимо от того, есть там протект или нет, всё ломается независимо от лоадеров.

мне кажется что https запросы как-то не сильно надежно использовать, мне кажется лучше по сокетам зашифрованные байтики отправлять, или все же нормальный вариант https

https или сокет разницы не имеет, в любом случае надо шифровать и расшифровывать после получения, желательно разделить на куски и передавать.

Соединение без SSL (чистый socket или HTTP) лучше исключить. Надо проверять SSL-сертификат в лоаде (если информация о сертификате отличается, в том числе и его хэш, то вызывать дисконнект), так как все HTTPS-сниферы подменяют сертификат для перехвата, и всякий шлак по типу HTTP Debugger/Analyser отвалится.


Насколько я помню, x64dbg оставляет следы в environments, так как он запускает процесс и он наследует их.

 

[desccc]

/del

 

[rektov]

лучшая защита это нападение

 

[shineus]

мне кажется что https запросы как-то не сильно надежно использовать, мне кажется лучше по сокетам зашифрованные байтики отправлять, или все же нормальный вариант https

https->tsl->tcp. Оно все работает на одном уровне, при правильном подходе к защите данных при передаче, не будет никаких проблем

 

[metafaze]

https->tsl->tcp. Оно все работает на одном уровне, при правильном подходе к защите данных при передаче, не будет никаких проблем

нууу...вообще то https все равно имеет углы которые по хорошему сгладить выбрав другой протокол.

stateless(отчасти решаемо костылями, да и релевантность НЕ всегда есть)
оверхед на спек http(старый довольно жирный)

 

[shineus]

нууу...вообще то https все равно имеет углы которые по хорошему сгладить выбрав другой протокол.

stateless(отчасти решаемо костылями, да и релевантность НЕ всегда есть)
оверхед на спек http(старый довольно жирный)

Не спорю да, но обычно я выбираю https/tls/secure websockets. И пока никогда не было проблем с этим

 

[Divviner]

https->tsl->tcp. Оно все работает на одном уровне, при правильном подходе к защите данных при передаче, не будет никаких проблем

tsl? что это вообще такое? если ты имел ввиду tls, то это и есть htts. https - http secure, tls в свою очередь - метод шифрования. за tcp(layer 4) вообще молчу, это протокол, который ничего общего не имеет с http(layer 7)

 

[shineus]

tsl? что это вообще такое? если ты имел ввиду tls, то это и есть htts. https - http secure, tls в свою очередь - метод шифрования. за tcp(layer 4) вообще молчу, это протокол, который ничего общего не имеет с http(layer 7)

Да мисскликнул пока писал. Я же и написал что https работает на tls, который ну по факту является оберткой tcp. Хотя точнее http работает на TCP/IP

 

[JuicyOrange]

да, я прекрасно понимаю что все ломается и это лишь вопрос времени, но можно нехило так насрать и усложнить жизнь

мне кажется что https запросы как-то не сильно надежно использовать, мне кажется лучше по сокетам зашифрованные байтики отправлять, или все же нормальный вариант https

HTTPs крайне надёжен, так как используется AES256 шифрование. Нет смысла создавать свой протокол. HTTPs это база для API, есть куча готвых либ. Со стороны клиента просто Boost.Asio используй и всё будет хорошо никто трафик перехватить не сможет.

понял, а по защите dll что можно сделать?

Еще советую добавить проверку регистрации в самом dll, если не бай бог dll сдампили, то придётся еще вырезать проверку в самом dll. Добавь еще к этому какой нибудь протектор для критичных секций кода, сбор hwid проверка регистрации и тп, достаточно будет CodeVirtualizer от Oreans, он отпугнёт 99% людей которые захотят взломать чит. Он стоит дешевле Темиды и VMprotect, и является кроссплатформенным.

 

[metafaze]

HTTPs крайне надёжен, так как используется AES256 шифрование.

да практически любое симметричное шифрование крайне надежное. tls обновляется в плане криптографии лишь в согласовании симметричного ключа используя ассиметричный(rsa -> dh for instance)

Нет смысла создавать свой протокол.

https - stateless.
если состояние подключения нужно, с https будет огромная проблема(а скорее костыль)
если трафик дополнительно шифруется, https вообще будет делать только хуже.

HTTPs это база для API

хорошие api разделяют логику принятия запроса и его обработку(смотри MVC, а лучше гексагональную архитектуру)
тогда твой контроллер будет расшифровывать данные, передавая их в бизнес логику для обработки, обратно шифровать их для клиент кода.

Добавь еще к этому какой нибудь протектор для критичных секций кода, сбор hwid проверка регистрации и тп, достаточно будет CodeVirtualizer от Oreans, он отпугнёт 99% людей которые захотят взломать чит. Он стоит дешевле Темиды и VMprotect, и является кроссплатформенным.

тут соглашусь.сейчас спорить что лучше в плане виртуализации(если не учитывать проебы в имплементации виртуальных инструкций сопоставленных реальному сету(поддерживаемому) - hi themidie)
не имеет смысла.дойти до этапа сопоставления потоку данных вмки(like a vmp) виртуальных инструкций с операндами не представляется возможным 99.99% людей которые обитают в комьюнити читмейкинга.
если с деньгами худо, бери ласт вмп кряк и не еби мозг.все что осталось в промежутке между объявлением виртуализации и концом критической секции никто никогда не увидит пока твой чит не станет рубить огромные деньги.

 

[JuicyOrange]

https - stateless.
если состояние подключения нужно, с https будет огромная проблема(а скорее костыль)
если трафик дополнительно шифруется, https вообще будет делать только хуже.

Так можно же сохранять состояние через

Пожалуйста, авторизуйтесь для просмотра ссылки.

, нет?

 

[metafaze]

Так можно же сохранять состояние через

Пожалуйста, авторизуйтесь для просмотра ссылки.

, нет?

когда ты будешь инвалидировать состояние сессии?
с постоянным подключением проблем все же меньше.