Pawn.Raknet и его не раскрытые возможности. -
Jasno - 03.08.2018
Всем привет!
Недавно захотел сделать антивх у себя на dayz сервере, всё это хотел делать через Pawn.Raknet, а точнее через OPacket:207. 207 - Синхра игрока.
И что я увидел? Я увидел то, что enum PR_OnFootSync не подходит к этому.
Я попробовал создать свой и первое значение которое у меня получилось добыть это ID игрока, которому мы отсылаем данные о себе.
Всё окей, но когда я попробовал пойти дальше, второе значение выводилось какое то странное, я перепробовал все PR_UINT8,PR_UINT16,PR_UINT32 и т.д., выводит непонятное второе значение и оно меняется при передвижении NPC, я решил проверить, может быть это lrkey, но значение не подходят ни к одной из кнопок.
Пошёл в инет, не нашёл никакой информации по OPacket и OutcomingPacket, вообще 0 инфы, даже в wiki Pawn.RakNet ни единого упоминания (кроме самой функции) нет, но как я узнал, именно через 207 OPacket возможно убрать показывание ника над головой даже через ВХ, собейты и др чит программы, а так же убрать полоску хп и армора, но для начала нужно прочитать значения и изменить их!
Если кто-то заинтересовался и хочет вместе со мной разобраться в этом, пишите!
Так же если кто-то знает как вывести всю информацию битов bs, так же пожалуйста скажите.
Ведь с помощью этой функции можно придумать ни один анти-чит.
Самое странное то, что в самом Include Pawn.RakNet нет вообще никаких enum и Read для OPacket.
Re: Pawn.Raknet и его не раскрытые возможности. -
Romz - 03.08.2018
207 это пакет ID_ONFOOT_SYNC, нельзя сделать с помощью него анти WH.
Quote:
Parameters: UINT8 Packet_ID, UINT16 lrKey, UINT16 udKey, UINT16 keys, float X, float Y, float Z, float quat_w, float quat_x, float quat_y, float quat_z, UINT8 health, UINT8 armour, 2_BITS additional_key, 6_BITS weapon_id, UINT8 special_action, float velocity_x, float velocity_y, float velocity_z, float surfing_offsets_x, float surfing_offsets_y, float surfing_offsets_z, UINT16 surfing_vehicle_id, INT16 animation_id, INT16 animation_flags
|
Re: Pawn.Raknet и его не раскрытые возможности. -
Jasno - 03.08.2018
Это значение для IPacket.
Возможно всё, ставим проверку на стены в OPacket по иду, если за стеной высылаем координаты 0.0 0.0 -10.0
Чтобы игрок пропадал, вот и всё, нужно лишь прочитать 207 OPacket и перезаписать его.
Так то уже анти вх готов, просто у меня он на месте в АФК стоит, игрок может подойти и убить. Поэтому я пытаюсь прочитать 207 пакет, именно через OPacket.
Re: Pawn.Raknet и его не раскрытые возможности. -
joker2020pro - 03.08.2018
Структура исходящей синхры очень отличается от входящей. Точнее она не статическая, а записывается динамически (похоже в целях экономии трафика).
На 0.3e разбирался с этим и написал такую фн, но я не уверен, что она подойдет для 0.3.7:
Code:
void decodeHealthArmour(unsigned char byteHealthArmour, unsigned char& byteHealth, unsigned char& byteArmour)
{
unsigned char byteArmTemp = 0;
unsigned char byteHlTemp = 0;
byteArmTemp = (byteHealthArmour & 0x0F);
byteHlTemp = (byteHealthArmour >> 4);
if (byteArmTemp == 0xF) {
byteArmour = 100;
}
else if (byteArmTemp == 0) {
byteArmour = 0;
}
else {
byteArmour = byteArmTemp * 7;
}
if (byteHlTemp == 0xF) {
byteHealth = 100;
}
else if (byteHlTemp == 0) {
byteHealth = 0;
}
else {
byteHealth = byteHlTemp * 7;
}
}
void decodePlayerSync(BitStream* bsRead, stOnFootData* data)
{
bool bLeftRightKeys = false;
bool bUpDownKeys = false;
unsigned char byteHealthArmour = 0;
unsigned char byteCurrentWeapon = 0;
unsigned char byteAdditionalKey = 0;
unsigned char byteSpecialAction = 0;
bool bSurfing = false;
bool bAnimationID = false;
bsRead->Read(bLeftRightKeys);
if (bLeftRightKeys) {
bsRead->Read(data->sLeftRightKeys);
}
else {
data->sLeftRightKeys = 0;
}
bsRead->Read(bUpDownKeys);
if (bUpDownKeys) {
bsRead->Read(data->sUpDownKeys);
}
else {
data->sUpDownKeys = 0;
}
bsRead->Read(data->sKeys);
bsRead->Read(data->fPosition[0]);
bsRead->Read(data->fPosition[1]);
bsRead->Read(data->fPosition[2]);
bsRead->ReadNormQuat(data->fQuaternion[0], data->fQuaternion[1], data->fQuaternion[2], data->fQuaternion[3]);
bsRead->Read(byteHealthArmour);
bsRead->ReadBits(&byteAdditionalKey, 2);
bsRead->ReadBits(&byteCurrentWeapon, 6);
bsRead->Read(byteSpecialAction);
bsRead->ReadVector(data->fMoveSpeed[0], data->fMoveSpeed[1], data->fMoveSpeed[2]);
decodeHealthArmour(byteHealthArmour, data->byteHealth, data->byteArmor);
data->byteCurrentWeapon = byteCurrentWeapon;
data->byteAdditionalKey = byteAdditionalKey;
data->byteSpecialAction = byteSpecialAction;
bsRead->Read(bSurfing);
if (bSurfing) {
bsRead->Read(data->sSurfingID);
bsRead->Read(data->fSurfingOffsets[0]);
bsRead->Read(data->fSurfingOffsets[1]);
bsRead->Read(data->fSurfingOffsets[2]);
}
else {
data->sSurfingID = 0xFFFF;
data->fSurfingOffsets[0] = 0.0;
data->fSurfingOffsets[1] = 0.0;
data->fSurfingOffsets[2] = 0.0;
}
bsRead->Read(bAnimationID);
if (bAnimationID) {
bsRead->Read(data->sCurrentAnimationID);
bsRead->Read(data->sCurrentAnimationFlags);
}
else {
data->sCurrentAnimationID = 0;
data->sCurrentAnimationFlags = 0;
}
}
Re: Pawn.Raknet и его не раскрытые возможности. -
Jasno - 03.08.2018
Благодарю! Буду проверять.
Re: Pawn.Raknet и его не раскрытые возможности. -
Jasno - 03.08.2018
Нефига не вышло, жду ещё мыслей.
Re: Pawn.Raknet и его не раскрытые возможности. -
Eims - 09.08.2018
А не проще потратить те же самые усилия на написание своей клиентской "надстройки", добавив туда нужный функционал? Это всяко будет лучше, чем ради того, чтоб закрыть какой-то один чит (при том, скорее всего, лишь какой-то один его подвид), ты хочешь создать огромный трафик, делая кучу проверок десятки раз за секунду лишь для одного конкретного игрока. А с учётом пинга и прочих радостей SA-MP, ты рискуешь в конце узнать, что в реальных условиях твой античит работать не будет как надо, ибо будет на каждого третьего лагающего игрока выдавать ложные.
Re: Pawn.Raknet и его не раскрытые возможности. -
Jasno - 14.08.2018
Я хочу исправить все возможные ВХ, путём отключения синхронизации для игрока, который находится не в поле зрения. Таким образом мы полностью убираем любой вид ВХ.
Re: Pawn.Raknet и его не раскрытые возможности. -
Eims - 14.08.2018
А заодно и ломаем кучу скриптов самого SA-MP, ловя новые баги клиента. Если бы всё так было просто, уже давно бы это зафиксили. А твоя система мало того, что сломает клиентские скрипты, зависимые от синхры игроков, так ещё и будет работать с задержками, ибо всё будет вычисляться на сервере. Не думаю, что игрокам будет комфортно, когда игрок, выбегающий из-за угла, будет появляться не сразу, а через некоторое время
Re: Pawn.Raknet и его не раскрытые возможности. -
Jasno - 14.08.2018
что мы ломаем? Мы отключает не синхру игрока с сервером, а отключаем входящию синхру от других игроков OPacket, абсолютно ничего не ломаем, если вы не смыслите в этом, то не пишите ересть пожалуйста.
На счёт угла, можно поставить проверку на этот самый угол, например: что до выхода из-за угла останется 1-2 координат и тогда подключим синхру, чтобы небыло таких проблем.
Re: Pawn.Raknet и его не раскрытые возможности. -
][Noname][ - 14.08.2018
а как IsLineOfSightClear реализуешь на серве то?
Re: Pawn.Raknet и его не раскрытые возможности. -
Eims - 18.08.2018
Quote:
Originally Posted by Jasno
что мы ломаем? Мы отключает не синхру игрока с сервером, а отключаем входящию синхру от других игроков OPacket, абсолютно ничего не ломаем, если вы не смыслите в этом, то не пишите ересть пожалуйста.
На счёт угла, можно поставить проверку на этот самый угол, например: что до выхода из-за угла останется 1-2 координат и тогда подключим синхру, чтобы небыло таких проблем.
|
Лол. А причём тут вообще синхра с сервером? У нас разве только сервер участвует в обработке информации, а клиент вообще ничем не занимается?
Посмотри как синхронизируется транспорт, в котором сидит игрок + кто в системе "клиент - сервер - клиент" занимается отрисовкой тех же иконок авто/игроков на карте и какую информацию, при этом, использует.
Касаемо углов: ты забываешь, что существует такая штука, как задержка (aka пинг). И как я уже говорил изначально: тебе либо придётся учитывать кучу всего, нагружая сервер настолько, что это будет крайне неоправданно; либо это будет вызывать боль у игроков, так как всё равно система будет запаздывать. Начнёшь учитывать пинг - найдутся те, кто начнёт этим пользоваться (уж искусственно повысить задержку не составит труда). В итоге вылезет куча новых проблем.
Если бы всё было так просто, читеров в онлайн-играх уже давно не было бы. В той же CS процветает Silent Aim и разрабы ничего с этим не могут поделать, хотя у них есть гораздо больше возможностей, чем у тебя. И в той же Арме до сих пор ни мододелы, ни сами разрабы не избавились от всяких мапхаков и прочих читов, работающих на синхре игроков со всей карты. Просто потому что, во-первых, это твой подход будет создавать проблемы для игроков с высоким/нестабильным пингом, а, во-вторых, есть ряд систем, которые работают на этой самой синхре (в CS это прострелы, а в Арме это всякие звуки и многое другое). И реализовать такое можно только в случае, если задержка сведётся к минимуму. Но тогда настанет момент, когда игры просто будут запускаться где-то на серверах разработчиков, а игрок будет получать лишь картинку и тогда, тащемта, читеров не будет вообще (хотя для этого ещё нужно дождаться каких-нибудь квантовых компьютеров, которые вытянут подобные нагрузки).
Re: Pawn.Raknet и его не раскрытые возможности. -
Jasno - 23.08.2018
Quote:
Originally Posted by Eims
Лол. А причём тут вообще синхра с сервером? У нас разве только сервер участвует в обработке информации, а клиент вообще ничем не занимается? Посмотри как синхронизируется транспорт, в котором сидит игрок + кто в системе "клиент - сервер - клиент" занимается отрисовкой тех же иконок авто/игроков на карте и какую информацию, при этом, использует.
Касаемо углов: ты забываешь, что существует такая штука, как задержка (aka пинг). И как я уже говорил изначально: тебе либо придётся учитывать кучу всего, нагружая сервер настолько, что это будет крайне неоправданно; либо это будет вызывать боль у игроков, так как всё равно система будет запаздывать. Начнёшь учитывать пинг - найдутся те, кто начнёт этим пользоваться (уж искусственно повысить задержку не составит труда). В итоге вылезет куча новых проблем.
Если бы всё было так просто, читеров в онлайн-играх уже давно не было бы. В той же CS процветает Silent Aim и разрабы ничего с этим не могут поделать, хотя у них есть гораздо больше возможностей, чем у тебя. И в той же Арме до сих пор ни мододелы, ни сами разрабы не избавились от всяких мапхаков и прочих читов, работающих на синхре игроков со всей карты. Просто потому что, во-первых, это твой подход будет создавать проблемы для игроков с высоким/нестабильным пингом, а, во-вторых, есть ряд систем, которые работают на этой самой синхре (в CS это прострелы, а в Арме это всякие звуки и многое другое). И реализовать такое можно только в случае, если задержка сведётся к минимуму. Но тогда настанет момент, когда игры просто будут запускаться где-то на серверах разработчиков, а игрок будет получать лишь картинку и тогда, тащемта, читеров не будет вообще (хотя для этого ещё нужно дождаться каких-нибудь квантовых компьютеров, которые вытянут подобные нагрузки).
|
Довольно верно и в точку сказал, но, я уже реализовать кучу античитов, которые не сильно нагружают сервер и при этом не существуют не на одном из серверов.
Я уже смог убрать полностью АИМ и автоновдки, плюс доводки и сайленты, так же поборол полностью флай и телепорты без единого ложного и многое другое без ложных срабатываний, да проверок уйма, но самп не та платформа которая грузит проц, плюс на моей VDS машинке ещё 95% свободного CPU при онлайне в 100 человек. Так же просторы есть, на счёт проверки углов и всего такого, да, буду значит в синхру пихать и учитывать пинг игроков, иначе никак.
Синхронизацию уже научился отключать, чтобы другие игроки не синхронизировались для тебя, как в тоже время всё остальное синхронится для тебя.
Просто нужно брать и делать, а не говорить, это невозможно, а тут то так и так, в процессе мозга варит.