Просмотр полной версии : Защита от накрутки побед в баттлах в TowerDefence-играх при http-соединении
mikhailk
19.12.2012, 14:46
Никто не решал такую или аналогичную задачу?
Если делать игровой механизм "в лоб", то получается так: игрок расставляет объекты защиты и нажимает "Старт", клиент отправляет на сервер данные на начало боя, потом идут волны противников и клиент сообщает на сервер, чем все закончилось. При этом игрок в процессе игры может активировать те или иные функции у объектов, плюс применять еще какие-нибудь воздействия напрямую - т.е., при одной и той же начальной конфигурации может быть как победа, так и поражение. Очевидно, что подменив сообщение клиента об итогах баттла, игрок может накрутить себе побед, что, в свою очередь даст ему дополнительные бонусы и позволит занять первые места в топах с откровенно нереальными результатами. Я наблюдаю, что в некоторых TowerDefence-приложениях по этой причине просто отказались от общего топа и плюнули на накрутку.
Однако, если топ все-таки необходим?
На вскидку приходит на ум шифрование ответа клиента ключом, который надо прошить в клиенте так, чтобы без декомпиляции его было не получить, да и с компиляцией непросто (напр., заэмбедить свф-ку). Это какое-то количество "кулл-хацкеров" отсеет, но 100%-ным решением все-таки не является.
FlashRus
19.12.2012, 14:47
Как вариант - генерация байткода на лету.
Уровень вхождения кулл хацкеров в разы упадёт.
А почему активация функций и воздействия не отправляются на сервер?
mikhailk
19.12.2012, 15:15
А почему активация функций и воздействия не отправляются на сервер?
Большая скорость игры. Несколько действий в секунду. Почему я и указал про реализацию приложения с соединением с сервером по http.
Как вариант - генерация байткода на лету.
Не совсем понял, как это тут поможет.
caseyryan
19.12.2012, 15:35
Большая скорость игры.
Не может же быть игра на столько быстрой, что игрок даже не будет успевать кнопки нажимать.
Как решал такой вопрос я. При стрельбе из пулеметов или автоматов, получалось слишком много трафика, если отсылать каждый выстрел и проверять его, да еще и лишняя нагрузка на сервер при парсинге, поэтому пришел к решению отправлять на сервер данные при начале стрельбы и при окончании. Сервер начинает все это просчитывать параллельно, не синхронно с клиентом, так как это не особо критично. Количество потраченных патронов на сервере и клиенте может отличаться, но это в подобных играх как правило не имеет значения. То есть при старте стрельбы шлется сообщение вроде: tY:125|tY:456|546|cX100|cY345 где первые 2 блока - координаты цели, далее код персонажа (уникальный, на случай если их много), ну и его координаты. Это конечно псевдокод, но идея должна быть понятно. Сам клиент начинает просчитывать попадания сам, а по окончании стрельбы посылает серверу сообщение об окончании и свои результаты попаданий, а сервер сравнивает с тем, что получилось у него. И если результаты хотя бы примерно сошлись, то принимает клиентские, если нет, ставит свои.
П.с. я делал, конечно же, на сокетах.
mikhailk
19.12.2012, 15:46
Не может же быть игра на столько быстрой, что игрок даже не будет успевать кнопки нажимать.
Ну, вот можно посмотреть движок той же "Осады" (я ее не рекламирую, просто как пример). Там монстры прут десятками, если не сотнями, на поле десяток-другой-третий ловушек и защитников, которые отрабатывают и сваливаются либо в куллдаун (воины), либо требуют немедленной перезагрузки при наличии ресурсов (ловушки). Иногда за одну секунду игрок активирует 3-5 ловушек/защитников (у кого какая координация), а каждое применение ловушки может вызвать уничтожение нескольких монстров, иногда больше десятка.
Все это гнать на сервер - я себе слабо представляю, что там с трафиком будет.
Вот идея с байткодом мне на самом деле понравилась. Надо только докрутить ее до стадии реализации.
Можно еще придумать промежуточную валидацию и всякие контрольные суммы. И прогонять их случайно.
Если объем большой, то стоит наверно отправлять полностью лог действий пользователя, а на сервер прогонять всю игру по такому же алгоритму заново и сверять результаты.
mikhailk
21.12.2012, 16:36
Если объем большой, то стоит наверно отправлять полностью лог действий пользователя, а на сервер прогонять всю игру по такому же алгоритму заново и сверять результаты.
Не только лог действий пользователя. Еще и вражеских юнитов логировать придется. А не дай бог модель на сервере разойдется с моделью на клиенте?
Можно еще придумать промежуточную валидацию и всякие контрольные суммы. И прогонять их случайно.
Чтобы убедиться, что игра имела место?
Типа, клиент во время баттла шлет какой-нибудь рандомный мусор, по окончанию баттла все это собирает в одну строку, хэширует MD5 (предварительно, возможно, закрывает ключом, который в нем прошит), и подписывает полученным хэшем отправляемый результат баттла? Сервер, конечно, может посчитать подпись и сравнить с пришедшей.
Не вижу, чем этот метод более стоек, чем, например, просто зашифровать отправку результата баттла заэмбеденным ключиком, хотя выглядит забавно.
ЗЫ. Можно, конечно, еще сервер более активно в эту схему включить.
caseyryan
21.12.2012, 17:52
Что-то слишком много заморочек ради такой игры. Банить читеров просто и убирать их из топа. Самих пользователей к жалобам подключить.
Логировать ботов не нужно. Если их действия завязаны на рандом, то делать свой рандом инициализируемый временем начала боя, например. На сервере инициализировать такой же рандом тем же числом. ТОгда при одинаковой логике всё будет одинаково.
А не дай бог модель на сервере разойдется с моделью на клиенте? И? Эту серию можно продолжить:
- Не дай бог на клиенте ошибка будет.
- Не дай бог на сервере ошибка будет.
- Не дай бог инет отвалится.
- Не дай бог база рухнет.
не и тд.
Странный подход какой-то. Тестирование для того и существует, что бы находить баги перед выкладкой.
Не только лог действий пользователя. Еще и вражеских юнитов логировать придется. Можно не всю игру логировать, а куски. Скажем начальное состояние и серию действий, через какой-то промежуток снимать новый оттиск данных и опять серию действий и тд. Зависит от объема. Но в TD объем данных должен быть не большой, тем более если его в бинарном виде отправлять.
caseyryan
21.12.2012, 23:24
На сервере инициализировать такой же рандом тем же числом. ТОгда при одинаковой логике всё будет одинаково.
Чисто теоритически. В реальности этого добиться практически невозможно. Расхождения всегда будут.
Чисто теоритически. В реальности этого добиться практически невозможно. Расхождения всегда будут.
Погуглите random seed
caseyryan
23.12.2012, 18:32
Котяра, а это тут при чем?
Можно даже с клиента слать те же числа, и вообще обойтись без рандома на сервере. Я говорю о другом. Допустим на клиенте произошло какое-то притормаживание, и что-то пошло слегка не так. На сервере при этом данные будут уже расходиться. Практически невозможно сделать систему, которая на сервере и на клиенте сможет все в точности одинаково посчитать, даже не смотря на одинаковые входные данные. Вот о чем я.
Я сам на эти грабли наступал. Результаты были очень близкими (почти всегда), но иногда расходились довольно серьезно.
mikhailk
23.12.2012, 19:52
+1
Считать нужно в одном месте. В идеале, конечно, на сервере.
Эти вопли "я победил, а мне не защитали" еще хуже проблем из-за читерской накрутки.
В общем, как резюме, целесообразно считать на клиенте, поставить несложную защиту от школоты, а отдельных продвинутых хакеров отстреливать индивидуально, по возможности пристегнув какой-нибудь простенький механизм их фильтрации (чтобы серверный программист не шерстил скриптами базу, выясняя, по праву Пупкин занимает место в топе или накрутил его).
Непонятно тогда, почему этого никто не делает.
Практически невозможно сделать систему, которая на сервере и на клиенте сможет все в точности одинаково посчитать, даже не смотря на одинаковые входные данные. Вот о чем я.
Я сам на эти грабли наступал. Результаты были очень близкими (почти всегда), но иногда расходились довольно серьезно.2+2 всегда 4
caseyryan
24.12.2012, 15:36
iNils, Вы же отлично понимаете, о чем я говорил. К чему это сообщение?
При больших объемах данных, которые еще и меняются с ходом игры, невозможно будет получить точные показатели. И чем их больше, тем расхождения с клиентом будут серьезнее.
Как невозможно, когда возможно?
...невозможно будет получить точные показатели. И чем их больше, тем расхождения с клиентом будут серьезнее.
Если опираться на время, а не на fps, то вполне возможно.
Если опираться на время, а не на fps, то вполне возможно.
Да без разницы таймер или фпс. Когда все завязано на математику, все можно восстановить на сервере. Проблемы могут быть только с чисто флешовыми возможностями. Например определение столкновения с помощью BitmapData.hitTest ()
Как раз эти проблемы решаемы на уровне архитектуры. А вот с fps могут быть проблемы при лагах, т.к. события все равно придут и отличить их от чита, когда бот успевает за один кадр выполнить кучу действий будет проблематично.
Когда пользователь активирует ловушку.
Пример. Анимации по ENTER_FRAME. Появляется лаг. В это время пользователь пытается активировать несколько ловушек. Все мышиные события придут скопом, перед ENTER_FRAME.
caseyryan
24.12.2012, 18:55
Что-то от темы ушли, по-моему. iNils, да, для какой-нибудь чисто математической игры можно получить точные результаты. А для такой как здесь - нет. Хоть на fps завязывай, хоть на таймер.
Допустим произошел какой-то взрыв, персонажи разлетелись по сторонам. Как эту ситуацию можно воспроизвести на сервере, чтобы все было в точности? Особенно если разлет персонажей завязан на рандом.
Хотя, это наверное не подходящий пример для тауэр дефенс.
Ну, допустим стрельба под разными углами, используются синусы, косинусы, даже для поворота векторов. Эти числа будут хоть и не значительно но различаться. Теперь представим сколько раз такое может произойти в течение игры, и получим результат отличный от того, что посчтиал клиент.
Скорее всего, при грамотном коде, разница не будет очень значительной и можно будет этим принебречь, но идентичными результаты точно не будут.
А время событий?
Добавлено через 2 минуты
Особенно если разлет персонажей завязан на рандом.Рандом указан в логах
Ну, допустим стрельба под разными углами, используются синусы, косинусы, даже для поворота векторов. Эти числа будут хоть и не значительно но различаться.С какой стати? Синус as3 не равен синусу php?
mikhailk
24.12.2012, 19:00
Мне все равно кажется, это больше теория, нежели практика. Ну, допустим, перевели мы целиком все вычисления в модель (а как, собственно, еще потом обсчитывать на сервере?). И посчиталось в нашей модели, что гоблин вышел из точки А и дошел до точки В (ловушка) за 1500мс, после чего был уничтожен ловушкой. На ловушке, соответственно, отработала анимация (300мс) и количество зарядов ловушки уменьшилось на 1. При этом мы все потестили и выяснили, что при падении ФПС до 15 все работает штатно.
Однако, у пользователя оказался слабый компьютер, на котором, к тому же, очень не вовремя запустился Касперский, в результате на пару секунд ФПС упал практически до нуля. Что увидит пользователь по прошествии этих двух секунд? Гоблин еще стоит на месте, а по данным модели он уже 500 мс как труп. Гоблин до ловушки еще не дошел, а она уже сработала и количество зарядов снизилось на 1.
А время событий?
В смысле?
mikhailk, логика не должна зависеть от фпс. Даже в EnterFrame есть getTimer.
В смысле?В смысле время когда произошли мышиные события.
На ловушке, соответственно, отработала анимация (300мс) и количество зарядов ловушки уменьшилось на 1. При этом мы все потестили и выяснили, что при падении ФПС до 15 все работает штатно.
При чем тут анимация ловушки? Она с какого боку тут влияет. Количество зарядов меняется сразу, а не после анимации. Вместе с событием отправляется timestamp.
Что увидит пользователь по прошествии этих двух секунд? Гоблин еще стоит на месте, а по данным модели он уже 500 мс как труп. Гоблин до ловушки еще не дошел, а она уже сработала и количество зарядов снизилось на 1.
Гоблин исчез, все остальные переместились на то место в котором должны были бы оказаться. Появился лаг (что-то я зарапортовался, под тем что я раньше назвал лагом, надо подразумевать фризы), но синхронизация при этом не пострадала.
Добавлено через 2 минуты
mikhailk, логика не должна зависеть от фпс. Даже в EnterFrame есть getTimer.
В смысле время когда произошли мышиные события.
Это как раз то, о чем я и говорю. Логика зависит от getTimer, а не от номера кадра.
В общем, мы говорим об одном и том же.
mikhailk
24.12.2012, 19:23
mikhailk, логика не должна зависеть от фпс. Даже в EnterFrame есть getTimer.
Абсолютно не спорю.
Просто я что-то не вижу, чтобы игрушки, где бегает много маленьких монстров, делались именно так. Как раз наоборот, я наблюдаю, что при падении производительности все эти толпы начинают замедленно двигаться, а не пропадать и появляться в новых местах, где они должны быть по данным модели.
И ловушки отрабатывают не тогда, когда им пришло время по расчетам, а когда медленно ползущий монстр таки до них доберется. Т.е., совершенно очевидно проверяется пересечение флэшовых объектов.
Просто я что-то не вижу, чтобы игрушки, где бегает много маленьких монстров, делались именно так.
В скольких из них есть защита от читов?
mikhailk
24.12.2012, 19:49
В скольких из них есть защита от читов?
Нигде ее не вижу, если честно.
А во многих играх по этой причине и общего топа нет (кстати, не только в TD).
Намекаете, что простого решения нет?
Если предложенное решение сложное, то нет.
mikhailk
24.12.2012, 19:57
Если предложенное решение сложное, то нет.
Можете показать хоть одну игру, где сделано именно так?
Похожие принципы реализуются в многопользовательских играх. Там конечно все сложнее, так как приходится синхронизировать не только сервер, но и состояния у всех игроков. Ну и естественно, все бегает не на http.
mikhailk
24.12.2012, 20:23
Ну и естественно, все бегает не на http
У меня нет вопросов, как сделать это при постоянном соединении.
У меня был вопрос, как это можно сделать, оставаясь в рамках http-протокола.
Все рассуждения и велись в рамках http. В начале игры посылаете (или получаете) seed для рендома, в конце игры (или в процессе, как вам удобнее) посылаете лог событий с отметкой времени от начала игры. В конце игры сервер просчитывает симуляцию (упрощенную естественно, без графики, анимаций и прочей незначащей ерунды) и выдает вердикт: читер или нет.
За время обсуждения темы можно было сокет сделать.... и не париться....
mikhailk
25.12.2012, 01:04
Все рассуждения и велись в рамках http. В начале игры посылаете (или получаете) seed для рендома, в конце игры (или в процессе, как вам удобнее) посылаете лог событий с отметкой времени от начала игры. В конце игры сервер просчитывает симуляцию (упрощенную естественно, без графики, анимаций и прочей незначащей ерунды) и выдает вердикт: читер или нет.
Так я и не спорю.
Я просто реализаций таких не вижу.
А если все элементарно, но почему-то никто не делает, значит, видимо, не так элементарно?
Так я и не спорю.
Я просто реализаций таких не вижу.
А если все элементарно, но почему-то никто не делает, значит, видимо, не так элементарно?
1. А как это можно увидеть просто так, не занимаясь хаком игры? Или вы их постоянно хакаете?)
2. Возможность реализации, не означает, что это будут реализовывать. Может не нужно, может руководство не желает оплачивать дополнительный труд (элементарно то элементарно, но писать все равно нужно), может еще что.
mikhailk
25.12.2012, 10:45
1. А как это можно увидеть просто так, не занимаясь хаком игры? Или вы их постоянно хакаете?)
На самом деле, это довольно просто, когда Вы сами занимаетесь сходной деятельностью. Например, в момент, когда идет баттл, Вы перезагружаете клиента и смотрите, куда и как откатилось приложение. Можно сделать определенные выводы, не так ли? Или если Вы видите общий/недельный/дневной топ среди друзей, но почему-то он отсутствует для всех игроков, хотя объем контента и количество играющих явно позволяют тащить приложение на одном сервере. Тоже можно сделать совершенно очевидные выводы.
Например, в момент, когда идет баттл, Вы перезагружаете клиента и смотрите, куда и как откатилось приложение. Можно сделать определенные выводы, не так ли?Можно было сделать вывод, что восстановления состояния игры не было поставлено как задача.
Или если Вы видите общий/недельный/дневной топ среди друзей, но почему-то он отсутствует для всех игроков, хотя объем контента и количество играющих явно позволяют тащить приложение на одном сервере. А я делаю вывод, что мотивировать человека улучшать свой результат проще среди друзей, так как разрыв между результатом игрока и лучшим результатом среди его друзей будет меньше, чем между результатом игрока и лучшим результатом среди вообще всех игроков.
И кстати, выбор в пользу сравнения результатов среди друзей делает реализацию защиты ненужной, так как среди друзей хакать может аукнуться.
Тоже можно сделать совершенно очевидные выводы.
Странные у вас выводы. Напоминает анекдот, где ученый делает вывод, что таракан без ног не слышит.
Поэтому я еще раз повторю, что реализовать данную проверку можно. Но то что ее не делают (может и делают, но мы это не замечаем, и доводы выше никак не доказывают обратное), на это могут быть разные причины.
Как пример расскажу историю. В 2005 году мы делали для одного клиента игрушки, каждый месяц новая игра. То есть, за 22 рабочих дней, мы должны были придумать суть игры, детализировать ее, нарисовать, написать код, протестировать. И при этом у нас были еще задачи по другим клиентам, поэтому из 22 дней, на игру оставалось максимум 10 (две недели).
И была одна игра, где нажимая определенным образом на клавиши нужно было заставить персонажа быстро разогнаться и далеко прыгнуть. Результат потом попадал в общий рейтинг и по результатам недели, победитель получал приз - ящик пива. Игру сделали и запустили на сайте заказчика.
Через неделю стали появляться нереальные результаты и другие игроки стали на это жаловаться. Тогда я в первые и применил запись полных логов действий пользователя (в запутанном формате) и их отправку вместе с результатом, чтобы потом можно было выяснить, что действия были реальными. Но... я не зря указал время, которое отводилось на создание игры. Его просто не было, и никто не собирался делать проверку результатов на сервере. Менеджеры решили, что по времени проще брать победителя, брать его лог, вручную прогнать на флеше, если проверку проходил, то победитель, если нет, то брали следующего из списка и тд.
mikhailk
25.12.2012, 12:49
А я делаю вывод, что мотивировать человека улучшать свой результат проще среди друзей, так как разрыв между результатом игрока и лучшим результатом среди его друзей будет меньше, чем между результатом игрока и лучшим результатом среди вообще всех игроков.
И кстати, выбор в пользу сравнения результатов среди друзей делает реализацию защиты ненужной, так как среди друзей хакать может аукнуться.
Видели Вы хоть одного геймдиза, который добровольно отказался бы от общего топа? :)
Общий топ отсутствует по двум основным причинам - из-за читеров, с которыми не могут справиться, и из-за архитектуры системы, в которой все игроки расписаны по нескольким несвязанным между собой серверам (в целях масштабирования системы), а до написания сервиса, интегрирующего некоторые данные просто руки не дошли. Во втором случае, естественно, и френдленты внизу нет, поскольку друзей может раскидать по разным серверам.
Менеджеры решили, что по времени проще брать победителя, брать его лог, вручную прогнать на флеше, если проверку проходил, то победитель, если нет, то брали следующего из списка и тд.
Кстати, идея мне понравилась. Сделать менеджерам стендик, в который они будет скармливаться лог действий пользователя и пусть себе проверяют в свое удовольствие.
http://vk.com/app1832640
НОЛЬ защиты.
Топ общий, в пределах допусков. Хакай как хочешь.
Правда ТОП реализован на АПИ ВК, куда так просто без СИЛЬНОГО хака не влезешь. Может, в этом дело?
mikhailk
25.12.2012, 13:24
Правда ТОП реализован на АПИ ВК, куда так просто без СИЛЬНОГО хака не влезешь. Может, в этом дело?
Любой запрос к серверу ВК от имени клиента можно элементарно подделать.
Со своего аккаунта, естественно.
Ну как видите - хаков не наблюдается.
mikhailk
25.12.2012, 17:34
Ну как видите - хаков не наблюдается.
3400 установок.
Хакеры не реагируют на такие приложения.
А у тебя сколько установок? :)
http://vk.com/app1832640
НОЛЬ защиты.
Топ общий, в пределах допусков. Хакай как хочешь.
Правда ТОП реализован на АПИ ВК, куда так просто без СИЛЬНОГО хака не влезешь. Может, в этом дело?
лол, это ж бабл гам (т.е. пародия на нашу старую игру Вгороде), Дарк не ты случаем делал? ;)
Ессно я и делал. Я из ВГороде и надергал всю графику.
Собак мочить по игре именно поэтому и надо :))))))))
mikhailk
27.12.2012, 00:40
А у тебя сколько установок? :)
У меня лично установок нет, я же в составе команды работаю.
А так по разному. У последнего чуть больше 250 тысяч, у предыдущего где-то под шестьсот, если мне память не изменяет. Ничего выдающегося, чем имело бы смысл хвастаться.
Но что касается читеров и хакеров - иногда они проявляются где-то на отметке 45-50 тысяч, иногда после 100. На мой взгляд. Сужу по долбежке в сервер.
Так именно по "долбежке в серв" и киляйте сатрапов. Статистически. :)
mikhailk
27.12.2012, 11:03
Так именно по "долбежке в серв" и киляйте сатрапов. Статистически.
Сейчас этой проблемы нет, поскольку 100% вычислений проводятся на сервере, т.е., вопрос чисто защиты сервера. Все, что может прислать хакер на сервер, может прислать и обычный пользователь через клиент, так что выигрыш, который имеет хакер, заключается в увеличении количества игровых сессий за счет автоматизации (обычный игрок не способен играть 24 раза в сутки через каждый час, ему спать надо, а программа - может). Но издержки несущественны. Кроме того, уже не превый раз наблюдаю занятную тенденцию - читеры/хакеры сначала закидывают в приложение 200-300 голосов, а потом уже шкодят. Т.е., получается "он, конечно, сукин сын, но это наш сукин сын". :)
В прошлом участвовал как-то в проекте, где были парные гонки по кольцевым трассам и там защитить ничего не удалось (простого варианта не нашлось и заказчик принял решение не тратить на защиту времени), естественно, достаточно быстро пришли накрутчики, поскольку за первые места в топе были заявлены реальные призы.
А данную тему я завел с исключительно практическим вопросом - есть целые классы игр, где вычисления все равно приходится вести на клиенте (TD-лишь один класс из них) и было бы удобно для всех, если была надежная возможность как-то верифицировать итоги баттлов/соревнований без последующего воспроизведения этих баттлов/соревнований на стороне сервера.
Очевидно (мне, по крайней мере), если баттл ограничен по времени (например, 1 минута, после которой любой ответ клиента считается невалидным), а клиент-серверный обмен построен таким образом, что сообщение клиента с итогами баттла зависит от данных сервера, которые постоянно меняются, и каждый новый баттл требует нового осмысления для хакера, что ему присылать на сервер (т.е., автоматизация существенно затруднена), то хак такой игры просто будет не интересен из-за своей сложности. Останется пара психов, которых можно будет без проблем отстрелить из базуки.
клиент-серверный обмен построен таким образом, что сообщение клиента с итогами баттла зависит от данных сервера, которые постоянно меняются, и каждый новый баттл требует нового осмысления для хакера, что ему присылать на сервер (т.е., автоматизация существенно затруднена), то хак такой игры просто будет не интересен из-за своей сложности.Где содержится логика работы с этими данными?
Можно разобраться как работать с поступающими данными от сервера, написать свой swf и подменять им тот, что требуется в игре. Допустим это какойто плагин к браузеру, который видит, что урл совпдает с заданным и подменяет его на локальный. В итоге - хакер получает свою флешку в которую засунул данные от сервера и генерит что ему нужно.
mikhailk
27.12.2012, 19:05
Где содержится логика работы с этими данными?
В самих данных, передаваемых сервером, очевидно.
Я же не случайно указал ограниченное время, за которое хакер должен прислать правильный ответ.
У военных в системах связи применяется аналогичный подход. Шифр перехваченного сообщения гарантированно взламывается за три дня, но ценность информации в сообщении существует в пределах доведения приказа до исполнителя, а это время измеряется минутами. Поэтому такой уровень защиты от взлома всех устраивает.
Это в какой армии такие "шифровки" применяются? :eek:
mikhailk
27.12.2012, 19:12
В нашей. :)
Но это уровень подразделения. Выше - все как у всех.
Сейчас, в ходе перевооружения, надеюсь, и там поменяют.
Однако, я про подход. Ценность информации устаревает раньше, чем будет осуществлен взлом. Вполне себе подход.
Если по мнению российской армии шифр гарантированно взламывается за три дня, то он будет взломан в пределах минут. :)
mikhailk
27.12.2012, 19:19
Если по мнению российской армии шифр гарантированно взламывается за три дня, то он будет взломан в пределах минут
Какая разница, что там в армии?
Вон, в конфликте 2008г. с Грузией, наши доблестные вояки пользовались вообще открытой связью через местных сотовых операторов и ничего.
В самих данных, передаваемых сервером, очевидно.
Я же не случайно указал ограниченное время, за которое хакер должен прислать правильный ответ.Он будет присылать его моментально.
Добавлено через 6 минут
У военных в системах связи применяется аналогичный подход. Шифр перехваченного сообщения гарантированно взламывается за три дня, но ценность информации в сообщении существует в пределах доведения приказа до исполнителя, а это время измеряется минутами. Поэтому такой уровень защиты от взлома всех устраивает.Нет ничего общего. У военных вы перехватываете зашифрованное сообщения (никто не гарантирует, что шифр может будет взломан за 3 дня, более того, шифр может быть вообще не взломан). Здесь же у вас есть программа, которая это сообщение шифрует.
mikhailk
27.12.2012, 20:19
Он будет присылать его моментально.
Да, в случае автоматизации.
Значит, нужно добиться, чтобы в процессе взлома каждый раз присутствовал человеческий фактор.
Ага, все действия пользователя сопровождаются капчей. :)
Да, в случае автоматизации.
Значит, нужно добиться, чтобы в процессе взлома каждый раз присутствовал человеческий фактор.
А как он будет присутствовать в оригинальной флешке?
Победить хакера можно только давая каждый раз новую флешку.
mikhailk
27.12.2012, 20:25
Победить хакера можно только давая каждый раз новую флешку.
Если бы у меня было решение, я бы его обсуждать не стал, поскольку это было бы ноу-хау. :)
Но у меня есть подозрение, что заэмбедив в клиент достаточно зашифрованных данных и используя что-нибудь вроде динамической генерации кода, можно сделать некоторые интересные вещи.
Psycho Tiger
27.12.2012, 20:37
Если честно, я до сих пор не понимаю, в чем проблема.
В любой игре есть поток входа – это то что юзер нажимает на клавиатуре и щелкает мышкой. Если в игре подразумевается какой-то рэндом – то и последовательность рэндома всегда можно повторить (как сказал Котяра – гуглить random seed). Если игра получает ещё данные "извне", такие как действия других пользователей, если игра онлайн – всё сложнее, но это не наш случай. А для простоты скажем, что и рэндома у нас нет.
Итак, если каждое действие (построить, проапгрейдить, продать) юзера логировать вместе со временем, то в TD получается полная реплика игры. Если на "вход" посадить уже этот лог вместо пользователя – игра сыграется 1 в 1 как должна была сыграться.
Так вот. Если слать этот лог и пусть сервер сыграет "сам с собой", то он получит результаты.
Sooooooooo, в чем проблема?
mikhailk
27.12.2012, 23:28
Если честно, я до сих пор не понимаю, в чем проблема.
Проблема в том, что предлагается частное решение, а интересно общее.
Допустим, необходимо сделать контейнер-обертку с типовым настраиваемым ситибилдером, типовым социальным сервисом и подключаемым баттловым движком, который и будет придавать игре специфику. Иногда TD, иногда стенка на стенку, иногда еще чего - не суть. Хоть сбор грибов в сосновом лесу. В ситибилдере игрок прокачивается, в баттлах - реализует накопленный потенциал. Если решить задачу верификации в общем виде, то и сервер будет типовой. Если нет, то потребуется по одному сервису верификации под каждый движок баттла.
Psycho Tiger
28.12.2012, 00:48
Ну сделай из моего варианта общее решение. Что игре кормится некоторый IControlInput, который может быть реальным игроком, а может уже записанными действиями.
Общее решение проблемы = реплика действий юзера на сервере, что сервер сам считает результат.
Какая абстракция в постановке задачи, такая и в ответе. А то общность из серии "Пишу движок для шутера, но хочу сделать его универсальней, чтобы если что переделать в тетрис."
Работает на vBulletin ® версия 3.7.3. Copyright ©2000-2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Copyright © 1999-2008 Flasher.ru. All rights reserved.