Чтобы мы хотели от лаунчеров проектов Minecraft?

Донатить будут не тебе, а владельцам серверов, которые будут пользоваться твоим лаунчером. Их аудитория - дети под виндой. Аудитория игроков на линуксе исчезающе мала, на маке чуть побольше. Ориентироваться надо не на игроков, а на создателей серверов: чем они рискуют, выбирая не сашка? Какова стоимость владения лаунчером? Насколько удобно будет его поддерживать?

Под мак хз, а для линукса всё просто: заинжектить можно только через strace. И его же можно использовать для защиты от него самого. Вангую, в маке плюс-минус то же самое.

 

А в чем, собственно, сложность?
std::filesystem - кроссплатформенный, алгоритмы шифрования и хэширования - тем более
Для работы с пакетами - есть свои особенности, но вроде тоже есть кроссплатформенные библиотеки...
Разве что с дизассссемблированием бинарника разобраться будет трудновато, но не нереализуемо...

Если вы про подмену библиотек самого маина (чисто форточковый обход) - можно будет отдельные модули защиты написать под каждую из ОС.

А больше на ум хаков не приходит...

 

Не думаю что все так просто. Ни у одной игры нет защиты под линукс или мак.

 

Есть еще внутриядерные способы, но они настолько сложны, что не думаю, что кто-то будет это пилить

 

Что и следовало доказать. Зеленый ты в этом вопросе.

 

Есть, но не настолько продвинутая, потому что это нафиг там не надо

 

Поясните?
Просто больше методов обхода, которые не ловятся стандартными (не экспериментальными) функциями С++ я не знаю...

 

Хоть это и экзотика, но они не сложные, просто чуть замороченные.
Всё, что тебе надо - доставить шелл с dlopen/dlsym в адресное пространство процесса и выполнить его любым способом. А так как в ядре у нас есть доступ ко всем процессам и мы можем крутить памятью и потоками, как угодно, инжект из драйвера уже не выглядит сложным.

Защищаться от этого, опять же, можно, похукав всякое в ядре, благо нет PatchGuard'a, но такие хуки придётся пересобирать под конкретное ядро конкретного дистрибутива. Сразу не годится.

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

 

Нецелесообразно. Линукс и гейминг - взаимоисключающие параграфы. Поэтому и не делают.
На линуксе ядро архитектурно проще и прямолинейнее виндового - большого отличия от юзермода там нет.
Например, в линуксе нет API. Нет готовых функций, которые переключат тебя в нужный процесс или выделят там память. Как в виндовом ядре удобно: ZwAllocateVirtualMemory -> KeStackAttachProcess. А в линуксе придётся руками перебирать страницы через какой-нибудь get_user_pages, через сто костылей переключаться в адресное пространство этого процесса, чтобы что-то туда записать, а ещё надо заставить этот шелл выполниться. Зато прямой доступ ко всем структурам и функциям. Захотел - залез в PTE, захотел, вмешался в шедулер (что немыслимо в винде, где процентов 90 ядра просто не экспортируется). А потом вышла обнова ядра - и всё сломалось.

В общем, защиту можно накрутить и на лиунксе, но нет игроков - нет и смысла.

 

Мне тут скинули ссылку на это обсуждение. Что ж, придется ответить.

Давайте внимательно посмотрим какие проблемы ждут того человека, что решит писать лаунчер для майнкрафта не на Java
Кросс-языковая интеграция. Это сложно. по любом вам понадобится код на Java для взаимодействия с authlib и составления api
Выбор фреймворка. Ниже предлагают Qt - отличный фреймворк. Однако вам придется делать установщик лаунчера, что бы притащить все эти .dll, а если собирать статически - можно огрести проблем с раздутым бинарников раз, и с некоторыми библиотеками вроде libpthread два.
GUI. Я не представляю как вы будете делать красивое GUI в Qt так, что бы оно одинакого смотрелось как на винде, так и на лине. Пользователям нужны яркие цвета, анимации, а не дефолтные кнопки. Редактирование дизайна под проект станет нетривиальной задачей
Сама сборка лаунчера под проект станет нетривиальной задачей для школьника

Криптостойкость. Этим всё сказано. Даже MD5 не является хорошим решением, а вы предлагаете такие быстрые нестойкие хеши. Получив файл чита с таким же хешем как у оригинального файла все ваши нативные защиты пойдут лесом

И повторить судьбу лаунчера Сашка с его уязвимостью перед DoS/DDoS/атаки медленного чтения и тп. У нас не 400 packet per second, нам нахрен не нужно экономить байты, что бы писать бинарную сериализацию, строить какие то свои велосипеды, придумывать бинарный протокол.

Серверная часть. Qt в серверной части - весьма малоэффективен и не подходит для больших нагрузок. CoW, концепция слот-сигнал, привязка объекта к определенному потоку, всё это мешает эффективной обработке поступающих запросов. Qt5 не особо использует новые стандарты C++, нужно ждать выхода Qt6. Работа с базами данных так же принесет некоторые проблемы

 

Если б всё было так просто... Читеров бы просто не было.

Linux: Зачем пытаться закрыть ptrace, если в замену ему найдётся kernel-level syscall hooking и там подменят САМ! ptrace и ты будешь думать, что всё хорошо.
Windows: Через в драйвер в другом процессе можно гору свернуть, даже сломать завершение процесса античитом или немножко отдебажив просто аккуратно убрать античит. (Вот почему EAC имеет драйвер, так они пытаются предотвратить читерство через них, но и там иногда лазейки находят).
MAC: Тот же модуль ядра, просто называется по другому.

Это пример написанный в лоб, просто чтоб показать, что не всё так просто.

 

Про дизайн и единый ексешник в QT полностью не согласен. Делали уже, одинаково смотрится на всех платформах. И единый ексешник работает отлично.
С ддосом тоже не согласен. Можно сразу кидать в нулроутинг все пакеты, что не являются валидными для сокет сервера. Все прокси ддосера моментально полетят в бан. Такое кстати и с банжекордом отлично работает.

 

А зачем слать невалидные пакеты? Будут слать очень даже валидные, и если нет HMAC или еще какойто защиты от невалидных пакетов.
Аудитория майнкрафта привыкла к JAR лаунчерам. Раздутый EXE будет смотреться подозрительно как для антивирусов, так и для пользователей
Аудитория владельцев серверов майнкрафта привыкла к Java лаунчерам. Настройка принципиально иного лаунчера, и тем более его сборка - задача сложная

 

Если брать подход Сашка(и возможно майнкрафта) - синхронно читать из input - получим уязвимость к атакам, но сможем делать потоковую передачу
Если брать подход когда размер пакета известен заранее - ограничение на размер пакета и следовательно невозможность потоковой передачи
В любом случае разработчику такого лаунчера потребуется огромное число сил и времени, а так же серьезные знания C++, умение выстроить грамотную архитектуру и не погрязнуть в тоннах говнокода. С отдаленным и неясным профитом и непонятной целевой аудиторией, без финансовой поддержки.

 

Ну вот что то не шлют и все отлично пробанивается. Досилки всего мира знают протокол сокета ага, держи в курсе.
На счет exe согласен, без подписи это просто мусор. Но антивирусники на QT еще пока что не орали.

 

Делаю на Qt со статик-сборкой с QtQuick3D, анимациями и эффектами, никаких проблем. Бинарник весит около 50 мегабайт. Дизайн редактируется легко и интуитивно-понятно - и в визуальном режиме, и в режиме разметки на QML.

Зачем? Каким боком здесь API и джава? И, тем более, authlib. Пропатчить авторизацию можно и из нативного кода. Или взять готовую пропатченную аутлибу от @alexandrage.

И сколько будем искать коллизии для 64х-битных хэшей, чтобы файл чита оставался валидным? Месяц? Год? 10 лет?

Никто и не говорит про Qt на серверсайде. Для серверов и надо брать заточенные под сервера языки. Например, Go.

На каждую хитро закрученную жoпy найдётся xeр с винтом.

Если пакет валидный - он и должен обрабатываться полноценно. Если пробили хостинговые антиддосы и cloudflare, останется простая проверка в вебчасти на частоту пакетов с клиента. Больше ты уже ничего не сделаешь.
Бинарный протокол - это лишь способ упаковки. Нет разницы, передавать в джейсонах или в сыром потоке байтов - принципиально ничего не изменится, и все атаки, справедливые для бинарных протоколов, останутся справедливыми и для текстовых. Только бинарный протокол очень экономный и его парсинг гораздо быстрее.

Это справедливо для любого языка. Не знаешь язык - хороший продукт не напишешь. Разве C++ намного сложнее джавы? На джаве тоже можно наворотить всякого.

Решается упаковкой системы сборки в докер.

Что значит "привыкли к Java лаунчерам"? Какая админам разница, какие команды выполнять для сборки, если есть инструкция? Любой лаунчер на любом языке настраивается по-своему. Можно привыкнуть к конкретному лаунчеру, но нельзя привыкнуть к лаунчерам на каком-то конкретном языке.

 

QtQuick попробую, спасибо за наводку. А вот 50Мб бинарник это перебор. Серьезно. Используя jlink можно всю Java собрать(9+)

Прелесть в том что различные моды, плагины, любые кастомные разработки могут свободно пользоваться API лаунчера(запросы, события, и пр.). Для нативного лаунчера это затруднительно. Пропатчить напрямую из натива можно, но не далеко просто. В authlib на уровне Java кода делают мост к native методам API лаунчера(классы всё равно придется писать, пусть и состоящие из одних native методов)

Для текстовых протоколов мы обязаны знать длинну всего пакета. Иначе никак. Накосячить и допустить RCE сложнее.
При работе с бинарными протоколами у нас больше контроля и больше ответственность. Ошибки при работе с буферами могут очень легко стать RCE. Кроме того, необходимо поддерживать согласованность протокола на клиентской и серверной стороне - меняем в одном месте не забываем менять в другом. Всё усложняется если клиент и сервер написаны на разных языка и/или фреймворках.

Сделать можно всё и на чем угодно. Но это не отменяет того факта что идея подобного лаунчера кажется мне утопической. Собственно все мои сообщения в этой теме о том, что бы RGLSM понимал какие сложности его ждут и не тратил время и силы пытаясь решить сложную и не очень профитную задачу. Ну а если всё таки взялся - не бросил

 

Думаю, это цифры с неба. У нас с челом в упаковке всего 9 метров получался лаунчер, без упаковки 16.

 

На QML или на виджетах?

 

Hello World на QT... Сам ELF = 16КБ
В закромах, без учёта всего кроме QT:
5,2M /usr/lib/libQt5Core.so.5.14.0
6,7M /usr/lib/libQt5Gui.so.5.14.0
2,4M /usr/lib/libQt5Location.so.5.14.0