Open-GTO / protection

Flexible server protection system (development)
MIT License
23 stars 8 forks source link

Pawn.Raknet #18

Closed NexiusTailer closed 4 years ago

NexiusTailer commented 6 years ago

Я заметил, что это один из немногих античитов на данный момент, который активно разрабатывается, потому хотел бы предложить (пока только идею) переписать его под Pawn.Raknet. Мне кажется конкретно этот античит с его идеей ресинхронизации вместо киков как наказаний по умолчанию очень хорошо бы дополнял Pawn.Raknet своими возможностями перезаписи пакетов, а именно: в то время как античит за большинство попыток читерства устанавливает игроку старые "правильные" данные, Pawn.Raknet мог бы перезаписывать пакет для других игроков с этими самыми реальными данными, отчего другие бы не видели попыток читерства этого игрока вообще. А любые нопы (игнорирование функций, которые пытается установить сервер игроку) вместе с тем полностью бы ломали игру самому читеру в первую очередь, т.к. тот бы получал рассинхрон.

ziggi commented 6 years ago

Я заметил, что это один из немногих античитов на данный момент, который активно разрабатывается

Это шутка?)

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

NexiusTailer commented 6 years ago

Это шутка?)

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

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

В общем и целом да. Ну мне просто показалось, что возможно для этого античита это было бы как нельзя кстати и такая идея тебя заинтересует)

ynhhoJ commented 5 years ago

На сколько это актуально в данный момент? Планирует ли кто то начать делать античит на базе Pawn.RakNet-a?

NexiusTailer commented 5 years ago

На сколько это актуально в данный момент? Планирует ли кто то начать делать античит на базе Pawn.RakNet-a?

Сам факт использования Pawn.Raknet'а уже есть в некоторых античитах. А вот если говорить об идее выше, где античит был бы построен на ресинхронизации игрока при читерстве для него самого и в то же время выборочной рассинхронизации его невалидных данных для других через перезапись пакета, то да, такого пока до сих пор нигде нет и мне до сих пор хочется увидеть эту идею реализованной. Я довольно долго хочу сделать это сам, и изучив получше этот вопрос я пришёл к одному важному выводу: такой античит лучше делать не с нуля и не на сырой основе, а на готовых алгоритмах, которые максимально стабильны и имеют настолько минимальное количество ложных срабатываний, насколько это возможно. Почему: если мы говорим об античите, где в качестве наказания происходит кик игрока или идёт предупреждение администрации, то любые ложные сразу видны в лоб - игрок сразу понимает, что раз его кикнул античит, а он не читерил - это ложный, ну и с варнингом админам похожая история. Если перевести такой античит же на ресинки (resync читера, выдавая ему реальные данные) и рассинхрон для других игроков его "читерских" действий, то игрок может даже не сразу заметить, когда что-то пойдёт не так. Простой пример - ложное срабатывание, которое иногда может ругаться на оружие, выданное сервером при спавне (скажем, какие-нибудь непредусмотренные задержки или лажа со стороны самого алгоритма античита). При кике игрок сразу придёт с жалобой и точным временем, когда и за что его кикнуло и такую проблему будет относительно просто понять и решить. С ресинками же ситуация может усложняться в разы: игрок может вообще не заметить, что античит отобрал у него оружие и это мало того, что замедлит обнаружение проблемы на некоторое время, так ещё и при успешном воспроизведении не каждый игрок сможет точно сказать, когда именно у него пропало оружие (он может заметить это не сразу). Логирование ресинков, ясное дело, упростит ситуацию, но никак не до уровня кика, потому как ресинков может бы несколько (десятков) на протяжении многочасовой игры, и какой из них будет по причине именно сбоя в античите, сказать будет уже гораздо сложнее.

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