Сжатие пакетов и защита С# клиента с открытым исходным кодом

Привет, сообщество.

Мой путь в программировании: ASP VB script >> VB.Net >> C#, с С и С++ я знаком минимально.
С давних пор пишу онлайн RPG (около 9 лет) и сейчас дошел до стадии публичного онлайн тестирования.

Клиентская часть написана на С# и доступна для изучения(улучшения) всеми желающими.
У меня нет никакой паранойи (надеюсь ;-)) относительно хакеров и любителей поломать чужие сервера — я отлично понимаю, что никому нет дела до моих исходников, однако мне хочется, чтобы на сервер отсылались пакеты, обработанные только известной, проверенной и утверждённой версией клиента.
Поэтому я хочу реализовать защиту в виде подключаемой приватной нативной библиотеки, которая будет отсылать на сервер хеш код используемого клиента, плюс она-же будет шифровать/дешифровать/сжимать/разжимать все пакеты. То есть если в клиенте реализуют отсылку фиктивного хешь кода, без использования нативной DLL, то злоумышленнику также придется реализовать свою версию обработки пакетов.

У меня есть несколько вопросов:
1. Правильный ли это метод зашиты клиента? Может быть есть какие-то готовые актуальные методы, реализующие такую задачу.
2. Сложно ли будет исследовать нативную DLL для реализации своего обработчика- тоетсь насколько высок порог вхождения для этого.

В игре ожидаются очень массовые замесы, поэтому, как мне кажется, крайне важно минимизировать трафик в обе стороны. Для сериализации всех объектов используется «ручной» метод в байт код без избыточности (то есть в нем только значимые байты) + я хочу сжимать числа по VLQ алгоритму rosettacode.org/wiki/Variable-length_quantity + поверх ZIP сжатие.
Вопрос:
3. Имеет-ли смысл использзовать VLQ, ZIP и заморачиваться написанием нативной С DLL (напомню, я практически не знаком с этим языком) для обработки пакетов, и даст ли это ощутимый выигрыш в произодительности.

PS — как перенести это сообщение в вопросы?
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 15

    +10
    Если вы не разбираетесь в криптографических алгоритмах и мало работали с неуправляемым кодом — не надо мучиться. То, что вы напишете, будет ломаться средней руки специалистом за 10 минут. Не усложняйте себе жизнь.
      0
      Ох! Неужели реально 10 мин?
      Да, к сожалению, никогда не интересовался вопросами криптографи, защиты и т.д (
      Может тогда обфусцировать чем-нибуть? Обфусцированный код будет сложнее исследовать чем нативную библиотеку?
      Просто я-то хотел совместить и безопасность и производительность в одном флаконе)
        +3
        Обфусцированный код .NET восстанавливается квалифицированным специалистом за 15 минут в случае реализации тривиального алгоритма (а в вашем случае именно таким он скорее всего и будет).

        Security by obscurity — не лучший вид защиты.
          0
          Нда как всё печально…
          Так чтобы Вы порекомендовали применить на данном этапе?

          Имеет ли смысл опубликовать клиента с полностью открытым кодом и пока не заморачиваться с вопросами защиты допустим до появления «хакнутых» версий — когда это еще будет и будет ли вообще))

            0
            Все зависит от размера потенциального убытка от хакнутой версии.

            Если он потенциально велик — на можно на часть потенциального убытка нанять специалиста, который спроектирует вам систему защиты.
      +2
      Перенесите в вопросы, а то заминусуют же…
        0
        извините это мой первый пост тут) так и не разобрался как перенести из черновиков в вопросы(
          0
          По содержанию пост на статью тянет, несмотря на вопрос в конце.
          +3
          Написать нативную dll несложно. Порог вхождения средний, но если вы пишете игру 9 лет, то на правильное управление памятью и вообще аккуратный код на С++ терпения у вас хватит, я уверен. Однако писать свой криптографический алгоритм без знаний в этой области бессмысленно, так что я бы посоветовал взять готовые решения.
            0
            А вообще, на правах креатива: можете реализовать проверку подлинности клиента через какую-то специфичную его реакцию на ответ сервера спицифичной же формы. Ну это так, мысли на тему, все равно придется хорошо прятать это дело.
              0
              Спасибо за креатив :-) Хотя вобще-то я так я так и планировал сделать изначально! Что-то типа упрощенно Warden от Blizzard.
              НО, так как клиент поставляется с открытым исходным кодом, то всё это будет на виду, и при желании вся эта проверка будет закомментирована, а ответ будет высылаться в качестве правильной константы, после чего с клиентом можно будет делать всё что угодно, например отключить физику, добавить просмотр/атаку/прохождения сквозь стены и т. д.

              На сервер всё это проверяется, но значительно грубее чем на клиенте и владелец суррогатного/допиленого клиента скорее всего всегда будет в выигрышном положении относительно базовой версии — что будет очень сильно отрицательно сказыватется на балансе и рейтинге игры (взять тотже WAR, который непопулярен в том числе и из-за багов/взлома его сетевой библиотеки)

              То-есть я уверен, что защита нужна, и скорее всего даже в самых первых публичных версиях клиента, но вот теперь надо выяснить как её лучше реализовать — вон пишут что нативная dll ломается за 10 мин — это явно не соответствует тем усилиям, которые мне придется затратить на освоение с++(
                0
                Мне кажется все равно, какой бы ни была защита, но если вы передаете на клиент напр. координаты противников за стеной, то их так или иначе можно будет получить и «сторонним» путем, увидев тех самых «невидимых» в вашем клиенте персонажей. Закладывайте защиту в архитектуру, «by design» :)

                Если же говорить о пакетах от клиента, то если у человека будет ваш клиент — то он же так или иначе сможет понять, как он работает, и сделать свой. Постарайтесь как можно меньше доверять таким критичным с вашей точки зрения вещам в пакетах от клиента на сервере, больше проверяйте их.

                Для удостоверения, что у человка загружен именно ваш клиент — тоже всегда было интересно узнать, как же сделать это, минимизировав возможность подмены (также и с использованием каких-л. криптографических схем), но так ни к чему и не пришел, к сожалению. Одна из глупых идей была напр. через опред. промежутки времени спрашивать у него «а дай-ка хеш определенного куска из памяти» и сравнивать с оригинальным, но такая «защита» разбивается моментально в пух и прах взятием-хешированием этого куска из рядом лежащего/загруженного, но неактивного оригинального клиента. Аутентификация средствами ассиметричных криптоалгоритмов тоже не подошла (выдергиваем из клиента приватный ключ и «привет»). Так что вопрос, конечно, крайне интересный :)
                Вон у Lineage Frost из r0 пытался защищать — почитайте, поучительно.
                  0
                  Хе-хе занятная статейка. Не знаю как насчет La2, но вот Aion их фрост точно не защищал. Сразу после выхода русской локализации появился бот — кажется наз. Aibolit, который отлично работает и до сих пор.

                  ИХМО: Лучшая защита от ботов и ботоводов в сетевой RPG это изначальное встраивание такого бота в клиент в виде нпс-наемика, который собирает ресурсы пока основной герой оффлайн. А какая на них охота!!! Ах)
            +1
            В Вашем случае защиту надо строить по принципу «клиент в руках врага», все что может быть взломано — будет взломано и обязательно подорвет доверие остальных клиентов, которые играют честно. Все проверки вести на сервере, на клиенте минимум, только для сглаживания неизбежных лагов, если игра в RT, если походовка, то вообще ничего считать не надо.
              0
              Необходима система «Свой-Чужой», как в военной авиации, но где ее взять вот вопрос.

              Only users with full accounts can post comments. Log in, please.