Онлайн-игры и защита от лома
 

Этот вопрос имеет отношение больше к девелопингу в целом, нежели непосредственно к флэш-дизайну/программингу.

Идея такова. Делается достаточно простая азартная аркадная флэш-игра. Однопользовательская. При наборе определенного количества очков информация об этом отправляется на сервер. Азартность заключается в соревновательном принципе, учитываются рейтинги игроков и распределяются места (хотя те же принципы разработки потом могут быть применены и к любой многопользовательской игре). Требуется исключить любые возможности для мошенничества. Позже планируется победителям выдавать ценные призы, и следовательно, это вопрос не только политический, но и коммерческий.

Хотелось бы услышать предложения, КАК это можно сделать?? (Будем считать, что мы не заморачиваемся на технические аспекты, без разницы, как это будет реализовано - если это имеет значение, я намерен использовать пхп, если потребуется, то пхп-турбин).

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

Пара общих принципов ясна. Идентефикаторы сессий, действительные лишь некоторое время - их можно вытащить, ручками или автоматизированно, декомпилируя скрипт, и потом подсунуть серверу. Генерируемые сервером .as или .swf файлы - хотелось бы потом проверить, соответствовал ли тот .as/.swf файл, который отвечал за игровой процесс тому файлу, который отсылал серверу инфу о результатах игры.. проверка контрольной суммы файла на соответствие идентификатору сессии - как это грамотно можно сделать, я еще не придумал, и пока идей никаких.

Из общих принципов пока что реализации с достойным уровнем безопасности не получается. Никаких вспомогательных материалов по данной теме я найти не смог. Трудно идти первым в таком щекотливом вопросе. Просьба помочь хорошей идеей или советом.

подозреваю, что ток сессии+реферрер...

реферрер подделать можно проще простого

2nuran

Научи, а?

2Exie

Насчет обусфикаторов - да, после них в AS ты уже не отконвертишь, но можно увидеть p-code (низкоуровневые команды, исполняемые плеером), я в последнее время обдумываю идею того, что если написать p-code - кодер и изучить p-codе, то это откроет новый уровень возможностей писанины/декомпиляции, т.к. ты будешь кодить/декомпилить на уровень ниже всяких защит. Пока я подобной инфы не встречал (хотя Декомпилер показывает p-code). Есть также вариант усложнить взломщику жизнь: сделать шифрованную флешку-контейнер, которая будет грузить (опять же, шифрованную) флешку-клиент. Также, хорошим вариантом является импорт готовой флешки в Shockwave, к нему я декомпилеров не встречал, однако, если ты выберешь этот путь, то ты должен понимать, что только у 50% юзверей есть Shockwave - плеер. Итог: зачем мне холодильник, если я не курю ;)

2Ion:
В направлении п-кода я еще не ковырял. Похоже, придется. Спасибо.

Самый ламерский способ (да, я им регулярно пользуюсь %)) - прописать в Регет поле реферер и затребовать урл с необходимым гет- или пост-запросом %)) Для Файрфокса есть приличный плугин по управлению деятельностью браузера.

Кстати, по поводу директора я тоже подумывал, но надеялся, что дело не зайдет так далеко. Разберусь в перспективе поподробней.
..да, то что надо. Вариант не из приятных (в лучшем случае половина юзеров согласится загрузить шоквейв-плугин, если его еще нет), но с технической точки зрения то, что надо. Посмотрел, шоквейв до сих пор никто не научился декомпилить. Еще нужно добавить мудреный алгоритм шифрования важных игровых переменных, которые хранятся в памяти.

Да, реферер подделать очень легко - например, можно просто самому написать скрипт, который через сокет соединяется с сервером и отправляет ему нужный реферер.

А 100% защиты быть не может! Ведь теоретически можно узнать, как работает любая флешка(автор топика это упоминал), значит, можно модифицировать ее алгоритм под свои нужды.

Согласен, даже самую лютую, старфоровскую защиту от дизасма можно выломать, что уж говорить про Флеш. А насчет шифрования переменных памяти - х3, я думал всегда, что смотреть память флеша и понимать, что там хранится довольно тяжело. Насчет Дира: если половина согласится качать плеер, то это не так плохо: у 50-и% есть, ещё 25% скачают, итого 75%

А вообще следует смотреть, стоит ли игра свеч? В большинстве случаев можно обойтись и не слишком сложной защитой, чтобы любой, вооружившись декомпилером, не мог сломать ее. Если для кого-то затраты, потраченные на взлом, будут казаться меньше возможных результатов, то он все-равно тебя сломает%)

Интересным вариантом является написание алгоритма типа md5 или sha1 - сервер посылает юзеру строку при каждом обмене инфой, клиент должен возвратить зашифрованную этим алгоритмом строку вместе с данными.

Ну и в чем заключается такая защита?

"Интересным вариантом является написание алгоритма типа md5 или sha1 - сервер посылает юзеру строку при каждом обмене инфой, клиент должен возвратить зашифрованную этим алгоритмом строку вместе с данными."

ты имеешь в виду такую схему ,когда сервер передает флеше уникальный "ключ", по которому кодится информация?

ION в своем стиле - "сломать все, что ломается" 80)
Если хошь действительно хорошую защиту, похоже, выход один - шифрование...
Помню, пару лет назад нам в универе препод с гордостью на лице рассказывал про md5 и sha1 и еще много про че. Я не гуру в этом, но свое с лекций унес. Ведь многие банковские софтинки и прочие системы на этих алгоритмах построены...
На взлом ключа на 128 (ну знаете, у механиков ключи на 15, а у ITшников ключи на 128... представляю, лет так через 10 - сынок, подай-ка мне ключ 64 на 128?) уйдет вся жисть 80)
Кстати, интересный вопрос. Очень актуальный... Очень интересно было бы взглянуть на решение!

kost@, в случае с играми не обязательно взламывать шифр и ключ - в нашем случае же не требуется получить точный результат. достаточно простым перебором закидать сервер случайными комбинациями, и смотреть, пока результат не удовлетворит - допустим ,если мы передаем зашифорванные набранные очки, то достаточно будет засабмитить подбором любое достаточно большо число.

spoof ? )

Именно так. Вряд ли ценный приз (если он будет) будет больше 100 баксов. Если не будут ломать "из принципа", то шансы у системы достаточно высоки %))
Сделаю расширенную систему определения попыток "побаловаться" с сервером, потому что сначала юзеру придется "прощупывать" сервер, отправляя вслепую кривую инфу, а там мы его сцапаем и сделаем внушение.. кулхацкера это остановит.

В том и проблема, что обмен инфой с сервером идет:
1) при начале игры
2) в конце игры, когда на сервер отсылается результат.
Вся логика приложения идет на стороне клиента в экшнскрипте, а, следовательно, ее можно подменить как частично, так и полностью.
Это необходимые условия для "аркадной" игры, иначе она превратится в "пошаговую", а там уже можно расположить всю логику на стороне сервера, и это будет панацеей.

ну вот, я зря шевелил мозгами...

Почему именно в клиенте а не на сервере? У всех платных игр логика как раз на сервере и находиться.

Потому что:
Иначе бы у меня не возникло и темы для обсуждения.
Под "аркадной" понимается: арканоид, тетрис, прицельная стрельба по Бин Ладену из пистолета Макарова и т.п.

а что если с помощью coldFusion логику во флешку загружать?

Ануткыть, поподробнее об этом

Это и есть серверная логика.. не подходит. Тот же server-side actionscript.
Мы не можем каждый раз отправлять сообщение об ударе теннисной ракеткой по мячику на сервер, чтобы сервер просчитывал, куда этот мячик летит, что сделал с этим мячиком оппонент и вернул данные по тому, как сейчас движется мячик сейчас.

Тогда можно так: передаешь конечные данные после просчета и начальные данные, чтобы сервер их проверял

Начальные данные у нас - "начало игры, такой-то уровень сложности". Конечные - количество очков.

Ну и соответственно если это тетрис (к примеру), то ещё передаешь всю историю игры: в каком порядке летели фигуры, что игрок нажимал и когда; а сервер рассчитывает, сколько игрок должен был набрать очков за такую игру и сравнивает с реальными очками

я тоже имел ввиду такой вариант, когда обдумывал на досуге алгоритм "защиты", можно будет аргументировано доказать дисквалификацию

Я так в играх и делаю. И чем сложнее механника действие пользователя, тем сложнее будет разобраться + шифрую результат по md5 умноженный на некоторое число известное серверу (хотя от декомпилинга это не помогает).

Каждый имеет право не использовать.

Придется для каждой игры писать механику дважды: один раз на флеше, второй раз на PHP. И в таком случае не получится универсальной системы для сохранения очков, если у нас на сайте много игр и для всех нужно сохранять очки.

Смотря, что считать универсальностью.
Была сделала серия игр, везде было md5, но использовалось разное правило (на сервере, завести для новой игры это займет минут 5)
Механики для php не писалась. Просто рядом с результатом в базу писался лог действий. Потом лог всех победителей пропускался через механнику той же игры (просто вместо действий пользователя использовались данные лога) и смотрелась реальность ситуации. Времени опять же занималось мало.

Да еще, зная максимальные параметры которые можно достичь в том или ином участке, можно также отсекать попытки при которых эти значение привышены.

Юзер генерит последовательность из длинных палок и складывает их горизонтально %)) Это к примеру.
Впрочем, все равно спасибо. Это наиболее приличное решение. В сочетании с другими методами защиты даст неплохой результат.

Благодарю. Этого вполне достаточно. Засунуть во флэшового робота лог и глазками посмотреть, насколько игровой процесс соответствовал реальности - задача вполне посильная, если победителей не сто на дню. А если их будет по сто на дню, то и модерирующий состав можно нанять %))

Есть ли способы разобрать что в файле после обсфускачивания прогой SWFEncrypt ?

Если в п-коде рубишь, то, наверное, да

Запускаем игру N раз ( не более 10, для начала).
Смотрим, что и когда летит к серверу.
В случае тетриса - кольцуем "лог игрового процесса" :)

А что касается шифрования... Алгоритм - двухсторонний, иначе не восстановишь лог для анализа.
В общем, отдавать на клиент "все" и получать "в конце результат" - имхо, здоровенная такая дыра.

аркадная игра
 

У меня проблема та же, аркадная игра в реальном времени, и нужно защитить данные.
Я решил идти по следующему пути, что скаченная Flash-ка c сервера была бы бесполезна.

Сделал так (если кто укажет на недостаток механизма, буду только признателен)

На HTML странице, там где загружается Flash. Flash-ке передается от сервера некий ID (ключ).

<PARAM NAME=FlashVars VALUE=”id=asd398djs783jd8213nd” >

Который сервер генерирует, следующим образом (php)
$id = md5(Session_id() . time());

(md5 тут уже лишний, но это просто для разнообразия).
Тут же сервер в базу заносит пометку, с этим кличем.

Как только Flash-ка загрузилась, она соединяется с сервером по средствам XMLSocket-ов (в качестве сервера скрипт на Perl) и отсылает ID. Сервер принимает ключ, смотрит есть ли он в базе, если есть, то удаляет эту запись и оставляет connect. Если нету, то делает disconnect клиенту.

Был бы очень признателен, если бы прокомментировали ;)

Хотя, как уже было сказано, можно взломать все что угодною Уверен есть брешь и тут :(

заменяем в этом тексте "Flash-ка" на "подделанная Flash-ка". что меняется?

возьмите, например, мой славный дум3. я ж могу обычным винраром посмотреть его карты и найти коды от всех дверей. могу и в консоли "ноклип" набрать, на худой конец. но почему-то этого не делаю.

имхо, не стоит делать анализ лога игры для победителей, достаточно сделать публичный "реплэй оф зе виннэр гэйм", и пусть все видят, какой хакер крутой. на худой конец, если реплэй получится у него реалистичным и красивым, то приз он по-своему заслужил; почему бы и не воздать за его нечеловеческие старания.

Ну и, а ключа то она не знает. Принцип.
HTML > Flash > В первом же фрейме Flash конектится и отдает ключ.

Ну сделали мы поддельную flash-ку. Но как мы узнаем какой ключ щас в базе на сервере ждет коннекта.

Допустим мы зашли через сайт открыли нормальную Flash-ку. Скопировали ее клич, и записали в поддельную, но нормальная Flash-ка уже соединилась и ключ уже больше не действителен. :confused:

Ладно, проехали, способы все равно есть, в любом случае :(