В чем разница параметров bypass?

space2pacman

Постоялец
Местный
Сообщения
327
Розыгрыши
0
Репутация
252
Реакции
256
Баллы
1 083
В чем разница параметров bypass talk_select и quest_accept ?

Стартовый квест на карту в C1. В стартовом месте для людей войнов есть 5 NPC. Master Roien и его помощники. У всех 4-х можно взять одинаковый квест.

Пример для Carl (html)

HTML:
<html><head><body>
Master Carlin:
<br>
Welcome to Cedric's Training Hall. I will be teaching you the basics of combat.
<br>
Please click on <font color="LEVEL">Quest</font>, in your Chat window.
<br>
<a action="bypass -h quest_accept?quest_id=201">Quest</a>
</body></html>

При выполнении запроса bypass передается quest_id. 201 - Это ID квеста Fighter tutorial. После этого начинается выполнение квеста.

Но у большинства NPC вызов квеста проиходит через bypass -h talk_select тем самым вызывая в AI event TALK_SELECTED

Пример для Roien (html)
HTML:
<html><head><body>
Grand Master Roien:
<br>
Welcome. I am Grand Master Roien, of Cedric's Training Hall.
<br>
This school was established by the renowned Paladin Sir Cedric, loyal subject of King Raoul the Unifier, to train young Fighters. One day, perhaps, in your travels you will be able to meet Sir Cedric, whom I have the honor to call my uncle, in the Kingdom of Aden.
<br>
<a action="bypass -h talk_select">Quest</a>
</body></html>

Для чего такая логика? talk_select это абстрактная вещь для вызова диалога? И где-то может быть квест а где-то просто общение? Все решает AI?
 
В чем разница параметров bypass talk_select и quest_accept ?
В принципе нет разницы в том как они передаются на сервер. Разница есть только в том как байпасы будут использоваться для определенного NPC. Так что нужно смотреть код для AI (скрипты для ПТС) где все это обрабатывается.

Bypass это просто передача данных через текстовую строку по типу командная строка. То есть где-то есть код который прикреплен к NPC и знает как и кто сейчас использует его. Данные передаются на сервер и там уже по логике для NPC будет это все обрабатываться.
 
Они триггерят разные NASC-хендлеры в NPC сервера.
TALK_SELECTED
QUEST_ACCEPTED
 
Правильно ли я понимаю, что принимая команду talk_select я сканирую окружение игрока. И если npc рядом есть то я вызываю его AI?

Таким образом мне не только не надо нигде хранить инфу а с кем я говорил но и проверять дистанцию до npc?

Я сначала думал где информация о том с кем я веду общение. Думал будет что-то bypass talk_select?npcId=7008
 
Не нужно сканировать. Когда генерируеться HTML, сервер должен запомнить все линки или байпасы которые были сгенерированны и ассоциировать их с определенным NPC . То есть когда байпасс (ну тот же линк) пройдет на сервер, сервер сможет понять что стаким байпасом делать и какому NPC это все отправлять. В L2J байпасы обычно выглядят по шаблону npc_<objectId>_bypass, то есть каждый байпас имеет приставку с уникальным id для NPC. Но это всего лишь один вид проверки.

В большинстве случаев у нас всегда будут NPC при показании какой-либо HTML. Иногда такой информации просто нет, например при работе с административными командами. Поэтому нужно тоже определить как и в таком случае обрабатывать байпасы на сервере.

Насчет проверок. Нужно проверять как и дистанцию от NPC так и сами байпасы. Например можно изменить сам байпас и использовать тот же objectId в примере с L2J. Поетому у ниx и есть дополнительные проверки в самих квестах/скриптах, так как все можно немного изменить.

Можно также кодировать байпасы, что я и использую на своем сервере. То ест никто, никогда не видит настоящего байпаса в HTML. Например в HTML будет линк "bypass -h x234bs" а на сервере это все переводится в команду "Quest 777 Complete". Уже подобное где-то было здесь на форумах, но там просто индексировали линки, что немного отличаеться от того что я делаю (использование nonce).
 
Игрок может получить HTML с байпассом только от NPC. ObjectID этого НПЦ атомарно сохраняется в плеере и при получении байпасса со стороны клиента, так же атомарно извлекается по этому ObjectID. Если ты поговорил с другим НПЦ - он заменил ссылку на последнего НПЦ. Сервер не должен доверять информации с клиента ни при каких условиях, поэтому все проверки валидности байпассов только на стороне сервера в логике скриптов НПЦ.
 
Но байпасс можно подменить. По мне так логика сканировать окружение имеет место быть, как считаете? Вопрос в том все ли NPC находятся далеко друг от друга? Нет ли в мире л2 вплотную стоящих NPC?
 
Ну подменили байпасс. Что с того? Какой байпасс НПЦу можно прислать невалидно так, чтобы он что-то сделал? Если там конечно какой-то кастомный НПЦ, который итемы выдает, принимая аргументы в виде циферок из рандомных байпассов, но тут уже сам себе злобный Буратино.
 
Есть близкостоящие NPC, но конечно с различными npc Id.

Насчет байпаса. Да, если нет даже простой проверки, можно подменить. Но и обратное тоже возможно. Например если мы видим другие NPC, и знаем как и что нам нужно для изменения байпаса, то можно воспользоваться ситуацией которую вы описали (сканирование npc вокруг игрока): высылать байпасы на другой NPC даже с ним не поговоривши через HTML.
 
Ну например открывать хтмл Маммона, в неделю, когда их нету и это получится, без проверок, так как ты открываешь диалог напрямую, по ссылке из того же пакетхака. И проверка на неделю ssq там не нужна уже. Да много чего в юношестве ворочал через подмену мультиселлов и хтмл байпассов на серверах)
 
Ну я подозреваю, что это относится по большой части к мусорным сборкам, где на уровне сервера не предусмотрена валидация входных данных. Я сотню раз видел байпассы в кастомных и даже обычных НПЦ, где забиты координаты для ТП, например «bypass -h 67363 66252 -3553», или даже «bypass -h Scripts:getReward 57 10000», или даже «bypass -h Buff 1048 2»(в оверах на олимпе был например у нпц).
В том же ПТС вообще нет валидации байпассов как таковой, более того, по идее ты можешь открыть любой html отправив правильный пакет со стороны клиента, но при этом каждый чих внутри ИИ валидируется и практически нет ситуаций, когда можно прислать левый байпасс и получить профит.

Это как вместо PreparedStatement юзать Query напрямую, а потом удивляться, что рандомный васян себе ГМа выдал через клановый форум)
 
То есть решение хранить в игроке инфу с тем с кем он общался последний раз (ID NPC)
 
От подмены байпасов не защитит, но пригодится, например, если добавить функционал по ограничению расстояния между NPC и игроком.
Как вариант, можно сохранять хэши экшнов, которые были отправлены последний раз с хтмлкой. А когда получаешь байпасс - смотреть, есть ли такой в списке хэшей. Вроде что-то подобное сейчас на джава эмулях делают.
 
Ну например на оффе, пока не сделали явную привязку мультиселов к конкретным нпс, можно было спокойно вызвать любой существующий список у любого нпс подставляя нужный ид в байпасс вида bypass -h menu_select?ask=-303&reply=<id>, т.к. ask равный -303 и отвечающий за показ мульиселлов обрабатывается в одном из самых базовых аи, а значит доступен по сути у любого нпс

Ну а в сборках на яве, разве что за исключением каких нибудь самых древних, давно запилено кэширование байпассов и замена их на спец. байпассы перед отправкой диалога клиенту, ну и само собой при получении байпасса уже от клиента, идет попытка обратно извлечь оригинальный, закэшированный байпасс по полученным данным. Все это в итоге и пресекает любые попытки как-то подменить байпассы и вызвать что-то не то.
 
Последнее редактирование:
Да, но уже даже в ХФ там идет привязка листов к конкретным НПЦ.
Я больше к тому, что если единственный барьер между валидным и не валидным запросом байпасса - это наличие его в хранилище, то это очень серьезная дырка, т.к для того, чтобы байпасс завалидировался через кеш, достаточно, чтобы сервер отправил его в теле страницы html в клиент. Для этого подойдут любые редактируемые поля, куда можно ввести свою инфу. Тот же КБ с его клановыми объявлениями, итем-брокер на овероподобных сборках, который парсит и выводит содержимое окон частных лавок в HTML, всякие встроенные рынки, аукционы и прочее, где разрабы поленились добавить фильтр допустимых символов на ввод. На самом деле, потенциальных дырок еще больше, но я не буду о них писать тут.
Поэтому, кеширование байпассов можно считать просто как дополнением к защите, усложняющим поиск дыр, но никак не панацеей, и следовательно проектировать все кастомные байпассы так, чтобы они как минимум оперировали заранее забитыми данными, а не позволяли вводить произвольные переменные, а как максимум - валидировали еще все запросы на уровне кода, сверяясь, а возможен ли этот байпасс в этой ситуации.

Главное правило для безопасного проектирования любой ММО игры - КЛИЕНТ ВРАГ! ЕМУ НЕЛЬЗЯ ДОВЕРЯТЬ!
 
Ну байпассы с подстановкой данных из полей ввода и т.п. само собой не кэшируются, но если после получения подобного байпасса от клиента разработчик поленился нормально проверить и отфильтровать полученные данные, то он ССЗБ.
 
Можно кешировать. Проблема в том что кешируемая часть не будет представлять всю строку отсылаемую через пакет байпаса, а только ее начало. Но это как раз и не критично так как такие байпасы всеравно нужно проверять на правильность. И такие байпасы достаточно легко можно найти в HTML так как они используют переменные со знаком $. Кстати вот такие байпасы и представляют опасность, так как в любом случае нужно тщательно проверять кто и как переслал такой байпас. И насчет combobox, можно нагенерировать комбинации если он используется как дополнение в строке.
 
Данный сайт использует cookie. Вы должны принять их для продолжения использования. Узнать больше…