Pawn.Raknet и его не раскрытые возможности.
#1

Всем привет!
Недавно захотел сделать антивх у себя на 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.
Reply
#2

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

Reply
#3

Это значение для IPacket.
Возможно всё, ставим проверку на стены в OPacket по иду, если за стеной высылаем координаты 0.0 0.0 -10.0
Чтобы игрок пропадал, вот и всё, нужно лишь прочитать 207 OPacket и перезаписать его.
Так то уже анти вх готов, просто у меня он на месте в АФК стоит, игрок может подойти и убить. Поэтому я пытаюсь прочитать 207 пакет, именно через OPacket.
Reply
#4

Структура исходящей синхры очень отличается от входящей. Точнее она не статическая, а записывается динамически (похоже в целях экономии трафика).

На 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;
	}
}
Reply
#5

Благодарю! Буду проверять.
Reply
#6

Нефига не вышло, жду ещё мыслей.
Reply
#7

А не проще потратить те же самые усилия на написание своей клиентской "надстройки", добавив туда нужный функционал? Это всяко будет лучше, чем ради того, чтоб закрыть какой-то один чит (при том, скорее всего, лишь какой-то один его подвид), ты хочешь создать огромный трафик, делая кучу проверок десятки раз за секунду лишь для одного конкретного игрока. А с учётом пинга и прочих радостей SA-MP, ты рискуешь в конце узнать, что в реальных условиях твой античит работать не будет как надо, ибо будет на каждого третьего лагающего игрока выдавать ложные.
Reply
#8

Я хочу исправить все возможные ВХ, путём отключения синхронизации для игрока, который находится не в поле зрения. Таким образом мы полностью убираем любой вид ВХ.
Reply
#9

А заодно и ломаем кучу скриптов самого SA-MP, ловя новые баги клиента. Если бы всё так было просто, уже давно бы это зафиксили. А твоя система мало того, что сломает клиентские скрипты, зависимые от синхры игроков, так ещё и будет работать с задержками, ибо всё будет вычисляться на сервере. Не думаю, что игрокам будет комфортно, когда игрок, выбегающий из-за угла, будет появляться не сразу, а через некоторое время
Reply
#10

что мы ломаем? Мы отключает не синхру игрока с сервером, а отключаем входящию синхру от других игроков OPacket, абсолютно ничего не ломаем, если вы не смыслите в этом, то не пишите ересть пожалуйста.
На счёт угла, можно поставить проверку на этот самый угол, например: что до выхода из-за угла останется 1-2 координат и тогда подключим синхру, чтобы небыло таких проблем.
Reply
#11

а как IsLineOfSightClear реализуешь на серве то?
Reply
#12

Quote:
Originally Posted by Jasno
View Post
что мы ломаем? Мы отключает не синхру игрока с сервером, а отключаем входящию синхру от других игроков OPacket, абсолютно ничего не ломаем, если вы не смыслите в этом, то не пишите ересть пожалуйста.
На счёт угла, можно поставить проверку на этот самый угол, например: что до выхода из-за угла останется 1-2 координат и тогда подключим синхру, чтобы небыло таких проблем.
Лол. А причём тут вообще синхра с сервером? У нас разве только сервер участвует в обработке информации, а клиент вообще ничем не занимается? Посмотри как синхронизируется транспорт, в котором сидит игрок + кто в системе "клиент - сервер - клиент" занимается отрисовкой тех же иконок авто/игроков на карте и какую информацию, при этом, использует.

Касаемо углов: ты забываешь, что существует такая штука, как задержка (aka пинг). И как я уже говорил изначально: тебе либо придётся учитывать кучу всего, нагружая сервер настолько, что это будет крайне неоправданно; либо это будет вызывать боль у игроков, так как всё равно система будет запаздывать. Начнёшь учитывать пинг - найдутся те, кто начнёт этим пользоваться (уж искусственно повысить задержку не составит труда). В итоге вылезет куча новых проблем.

Если бы всё было так просто, читеров в онлайн-играх уже давно не было бы. В той же CS процветает Silent Aim и разрабы ничего с этим не могут поделать, хотя у них есть гораздо больше возможностей, чем у тебя. И в той же Арме до сих пор ни мододелы, ни сами разрабы не избавились от всяких мапхаков и прочих читов, работающих на синхре игроков со всей карты. Просто потому что, во-первых, это твой подход будет создавать проблемы для игроков с высоким/нестабильным пингом, а, во-вторых, есть ряд систем, которые работают на этой самой синхре (в CS это прострелы, а в Арме это всякие звуки и многое другое). И реализовать такое можно только в случае, если задержка сведётся к минимуму. Но тогда настанет момент, когда игры просто будут запускаться где-то на серверах разработчиков, а игрок будет получать лишь картинку и тогда, тащемта, читеров не будет вообще (хотя для этого ещё нужно дождаться каких-нибудь квантовых компьютеров, которые вытянут подобные нагрузки).
Reply
#13

Quote:
Originally Posted by Eims
View Post
Лол. А причём тут вообще синхра с сервером? У нас разве только сервер участвует в обработке информации, а клиент вообще ничем не занимается? Посмотри как синхронизируется транспорт, в котором сидит игрок + кто в системе "клиент - сервер - клиент" занимается отрисовкой тех же иконок авто/игроков на карте и какую информацию, при этом, использует.

Касаемо углов: ты забываешь, что существует такая штука, как задержка (aka пинг). И как я уже говорил изначально: тебе либо придётся учитывать кучу всего, нагружая сервер настолько, что это будет крайне неоправданно; либо это будет вызывать боль у игроков, так как всё равно система будет запаздывать. Начнёшь учитывать пинг - найдутся те, кто начнёт этим пользоваться (уж искусственно повысить задержку не составит труда). В итоге вылезет куча новых проблем.

Если бы всё было так просто, читеров в онлайн-играх уже давно не было бы. В той же CS процветает Silent Aim и разрабы ничего с этим не могут поделать, хотя у них есть гораздо больше возможностей, чем у тебя. И в той же Арме до сих пор ни мододелы, ни сами разрабы не избавились от всяких мапхаков и прочих читов, работающих на синхре игроков со всей карты. Просто потому что, во-первых, это твой подход будет создавать проблемы для игроков с высоким/нестабильным пингом, а, во-вторых, есть ряд систем, которые работают на этой самой синхре (в CS это прострелы, а в Арме это всякие звуки и многое другое). И реализовать такое можно только в случае, если задержка сведётся к минимуму. Но тогда настанет момент, когда игры просто будут запускаться где-то на серверах разработчиков, а игрок будет получать лишь картинку и тогда, тащемта, читеров не будет вообще (хотя для этого ещё нужно дождаться каких-нибудь квантовых компьютеров, которые вытянут подобные нагрузки).
Довольно верно и в точку сказал, но, я уже реализовать кучу античитов, которые не сильно нагружают сервер и при этом не существуют не на одном из серверов.
Я уже смог убрать полностью АИМ и автоновдки, плюс доводки и сайленты, так же поборол полностью флай и телепорты без единого ложного и многое другое без ложных срабатываний, да проверок уйма, но самп не та платформа которая грузит проц, плюс на моей VDS машинке ещё 95% свободного CPU при онлайне в 100 человек. Так же просторы есть, на счёт проверки углов и всего такого, да, буду значит в синхру пихать и учитывать пинг игроков, иначе никак.
Синхронизацию уже научился отключать, чтобы другие игроки не синхронизировались для тебя, как в тоже время всё остальное синхронится для тебя.
Просто нужно брать и делать, а не говорить, это невозможно, а тут то так и так, в процессе мозга варит.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)