Алгоритм системы обновления клиента игры(лаунчера)

Добрый день.

Хотелось бы услышать ваше мнение и предложения по алгоритму обновления, что лучше использовать? Интеграция обновления с веб сайтом или разработка серверного механизма проверки клиента? Стоит ли шифровать передаваемые данные AES, или может у вас в голове есть какой то более продвинутый алгоритм проверки и обновления клиента.

 

В том-то и беда, что при любом шифровании, можно выдернуть все ключи, потому что враг находится не между "Алисой и Бобом", а прямо у Алисы в мозгу, ведь никто не мешает запустить лаунчер под отладчиком, собственно, поэтому тут скорее нужно думать не столько над криптостойкостью математического алгоритма шифрования, сколько над защитой программы от отладки.

Как-то писал некоторые мысли про защиту, но тему с тем ответом почему-то выпилили.

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

В общем, мне пока не удалось придумать ничего более оригинального, чем тупо получение шифрованных конфигов с сервера, со ссылками на источники для загрузки и хешами контролируемых файлов + "белым списком" для папки mods (ну, чтобы конфиги не потереть).

Что понимается под "продвинутый алгоритм проверки и обновления клиента.", какие функции должны быть?

 

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

Ну если канал широкий(гигабит например) то можно и на основном, можно шейпинг настроить на скачивание клиента по наименьшему приоритету, а можно организовать вообще подобие торента средствами лаунчера.

Функции проверки и обновления клиента =), но чтобы все было защищенным. У меня есть мысли которое я реализовываю на С++, возможно ваши идеи наведут меня на правильное решение

 

@Racvol, Лучше всего чтоб проверки шли на протяжение всей игры клиента и модов. Если проверка не пройдена бан.

 

Само собой, над этим я и работаю

 

А лучше полная проверка всей папки клиента. Чтоб всякие проги не сували в папку с клиентом для обхода. Определение левых папок файлов которых быть не должно и тд.

 

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

 

А что если в лаунчер воткнуть фичу , которая будет давать параметры клиенту . Вот на одном проекте , так сделано + шифрование CRC (Клиент) 32 . А также 3 сессии :
1 - авторизация лаунчера.
2 - Перед запуском клиента , ловится другая сессия .
3 - И уже финальная , при нажатии "Сетевой игры"

 

Не совсем понял, речь идет о параметрах скажем запуска на полный экран, выделение памяти и тд?
Я пишу из расчета что лаунчер и есть клиент и я в любой момент могу менять все параметры клиента, в том числе и проверка загруженных в память данных, но достаточно узким местом является связь между лаунчером и сервером, я хоть и реализовал динамическое шифрование данных но всеже это всеравно можно взломать.

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

 

Вот именно, что только затруднить. : (
Конечно, никто не отменял протекторы, но это тоже только затрудняет анализ.
Насчет контроля модов не только при запуске, но и во время самой игры - разумеется, так и должно быть, фоном раз в n минут проверка, предположим, или поставить хуки на изменение файлов в директории, а ещё лучше получить ring0 и отлавливать любые типы обращений к файлам и своим процессам (но, как уже говорил, под x64 драйвера без подписи караются). Тем более, касается получения ключей с сервера - надо сделать так, чтобы было непросто подделать ответ, но какая нафиг имитозащита, если вся память просматривается пользователем, вот поэтому и надо перехватить любые обращения к адресному пространству лаунчера.

 

Периодически я по той или иной причине изменяю клиент. Случается, что после этого мне крайне желательно, чтобы все обновили версию клиента. Но у меня работает и старая, и новая версия клиента -поэтому не все игроки обновляют клиент. Как сделать работавшую прежде версию клиента нерабочей? (клиент к серверу привязан) То же - с лаунчером.

 

Понятное дело что от опытного асемблеровшика ничто не спасет, он способен провести инжиниринг любого приложения. По поводу файлов и нулевого кольца, я думаю будет достаточно просто заблокировать все файлы своим процессом при старте. А что он сможет увидеть в памяти? Ключ? Для него это будет поток байтов, его нужно в процессе найти, отыскать алгоритм его обработки на асемблер, написать свою программу которая будет обманывать сервер и слать подложные ответы, короче гемороя не на один месяц. При том в любой момент я могу поменять алгоритм для профилактики

 

Тебе поможет тока программист, в двух словах не обьяснить, вообщем тебе нужен нормальный лаунчер

 

И, да, ещё что касается защиты, как понимаю, всё же мало отсечь установку модов, мне тут писали, что юзают "Cheat Engine" для спидхака и работает даже онлайн. Вначале не поверил, но потом вспомнил о модах только на клиент, что дают прыгать на 2 блока вверх и понял, что перемещение игрока просчитывается не полностью на сервере, так что, скорее всего насчет спидхака через cheat engine - это правда (поправьте, если гоню пургу, ок?), что влечет проблему отслеживания запущенных нежелательных программ, но получать список окон и смотреть на заголовки - не вариант, любой школьник найдет хэндл нужного окна и изменит надписи, искать по хеш-суммам файлов - запариться заносить различные версии в блеклист, так что тут тоже всё сходится к тому что нужно ставить хуки на некоторые функции, ну и защищать память процесса игры, что опять упирается в неподписанные дрова под x64. v___v

 

На скока я помню Cheat Engine просто шлет большое количество покетов на перемешение на сервер, я побыстрому состряпоть могу тока одну зашиту это выравнение количества поступающих пакетов через iptales, правило будет примерно таким: с каждого уникального Ip адреса разрешается поступать пакетам со скорость 5 пакетов в секунду(надо проверить на практике),

 

Я, собственно, о чём? В сервер вписать функцию (плагин?), которая будет проверять у клиента наличие неких "внутренностей". Например, наличие файла с некоторой информацией внутри, в папке клиента или в архиве minecraft.jar...
Существуют готовые решения?

 

Кстати, на простые отчеты, по-моему, не надо забивать, они ведь тоже помогают, особенно в спорных моментах^^. Но, разумеется, опять-же нужно будет что-то делать с защитой от подмены и перенаправления... Ночью запилил отправку - уже есть улов : P

Code:

...
4000 | cheatengine-i386.exe | D:\Игры\Cheat Engine 6.2\cheatengine-i386.exe
 
(8:00:38) USER_SHDS_ID = 1FC7734DDD22B88581186FA2C0297BC3, dynid = 1151845055 IP = 145.255.141.242
    last login =
    system info {
      OS {
        arch = x86
      }
      JVM {
        Version = 1.7.0_09 [x86]
        java home = C:\Program Files\Java\jre7
        Memory settings: xms = 512, xmx = 512
      }
      Memory {
...

 

Сам клиент это не потдерживает. Тут придется переписывать клиент и сервер добавлять новый пакет для таких передач.

 

@foxquiz, Ты кстате реализовал алгоритм поиска установленной Java?

 

:fp: после установке java создается переменная среда. И java стартует по команде java или start java. Ну на крайняк сделать как у w4p лаунчер качает java в свою папку и от туда ее юзает.