Войти
ПрограммированиеФорумСеть

Как защитить пакеты от изменения? какие чексуммы нужны? (4 стр)

Страницы: 1 2 3 4
#45
14:20, 17 янв. 2020

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


#46
14:28, 17 янв. 2020

ErgoCore
Один раз все равно придется "заморочиться" - решить какую библиотеку использовать для обмена.
Фотон, вебсокеты, какую-нибудь самописную через удп, и так далее. И когда выбор сделан поменять его уже проблематично. Если уж так совпадет что игра выстрелит - почти наверняка к этому моменту протокол никто поменять не сможет, будут бороться с читами разными костылями.

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

#47
14:33, 17 янв. 2020

kipar
> И когда выбор сделан поменять его уже проблематично.
ООП в помощь - соблюдаешь принципы и тогда любую часть кода как коробку поменять - расплюнуть. Но в твоих словах есть много правды - особенно если человек не совсем программист - он врятли в полной мере будет весь проект держать чистым и поддерживаемым. Так что в инди проектах - твоя правда. В студии где есть хотя бы один сеньор - уже все намного проще).

#48
14:36, 17 янв. 2020

ErgoCore
В студиях где тысячи сеньоров - все мы знаем насколько надежные протоколы и как там борются с читерами. Только у инди и есть шанс сделать нормально.

#49
15:19, 17 янв. 2020

kipar
> В студиях где тысячи сеньоров - все мы знаем насколько надежные протоколы и как
> там борются с читерами. Только у инди и есть шанс сделать нормально.
Что бы бороться с читерами не обязательно как задрот сидеть и хреначить все по миллиарду лет - тем более что ты один. А там где есть тысячи сеньоров - проще иметь хороший юридический отдел). Обойдется дешевле). И ломать будут меньше).

#50
16:21, 17 янв. 2020

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

#51
16:33, 17 янв. 2020

Сошлись - дай пять :D

#52
(Правка: 0:41) 0:38, 18 янв. 2020

Втыкаешь каунтер в сообщение и шифруешь поверх AES. Да, и не забываешь про адекватный режим сцепления в духе CBC. Все.

#53
11:36, 18 янв. 2020
Как защитить пакеты от изменения? (man-in-middle)

Никак не защитить. Единственный вариант не передавать ключи по этому соединению, а передать их лично на бумажке.

#54
13:00, 18 янв. 2020

FourGen
> Никак не защитить. Единственный вариант не передавать ключи по этому
> соединению, а передать их лично на бумажке.
Правда? Ну теоретически да,никак не защитить. Но это если ключ один. Ну а если,например,в клиенте есть генератор,которому приходит кеш код на генерацию и он от него генерит ключ шифрования,тогда что вы подменять собираетесь,если,например,оно по hwid коду привязано? Ядро с виртуалкой и блок на дебаг где-то 99,9% желающих его ломать отсеет сразу. В итоге то оно полной защиты не дает,но как показывает практика в достаточно большой сегменте ммо игр ломать это никто не спешит. На деле же,если не полностью понимать структуру - это практически нереально сделать. Потому что разработчик может раз в неделю просто менять пару байт,тем самым получая совсем другие оффсеты. А без последнего обновления проверить ничего нельзя. Так что способов борьбы может быть много,вопрос только в том,насколько они целесообразны. Зачастую это все слишком избыточно. Есть масса способов получить результат меньшей кровью.

#55
13:07, 18 янв. 2020

У меня все очень простенько сделано.

Клиент и сервер получают один и тот же ключ определенного игрока по https в момент авторизации.
Между собой они ключами не обмениваются. Шифрования нет.

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

#56
(Правка: 15:53) 15:45, 18 янв. 2020

>Bioman

Ну теоретически да,никак не защитить.

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

P.S.
Поясню (мое мнение)

Если в игре 50-100 онлайна в день, я весьма сомневаюсь, что кто-то будет целенаправленно писать какие-то читы. Ну поотправляют пакетов измененных, при адекватных проверках на сервере можно вообще не замарачиваться с шифрованием на этом этапе. Потратить неделю на тесты что произойдет если в место CF отправить FF это надо быть совсем извращенцем, тем более понимая, что даже если будет куча всего (золота, шмоток, и тп), а толку от этого не будет никакого - какой смысл это делать?

Страницы: 1 2 3 4
ПрограммированиеФорумСеть