Сниффается траффик, в момент отдачи ключа еще сервером и устанавливается соединение с сервером от имени запущенной флэшки. Запущенная флэшка заливается потоком требований на открытие соединения, чтобы наверняка не пролезла к серверу.

>>Запущенная флэшка заливается потоком требований

нафига?
простой робот, запущенный на том же php на локальной машине,
и страницу с сервака возьмет, и html пропарсит в поисках ключа.

я делал так: внутри флэхи есть некий длинный пароль (потом работает SWFencrypt), серверу отдаем цифру набранных в игре очков и md5 от строки пароль+очки, на сервере сравниваем хэши. Всё.

Допустим мы качнули её регетом или ещё как :confused:

блин, да дайте уже хакеру приз, чтоб отстал.

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

Несколько комментариев ко всему вышесказанному:
1. md5 морально устарела. Это ненадёжный алгоритм и не стоит им пользоваться
2. sha1 постепенно утрачивает надёжность, благо сообщения о нахождении коллизий уже поступали. Соответственно, стараемся переходить на sha2.
3. Как я понял цель - убедиться, что критические данные поступают из надёжного источника, то есть из не вломанной игры. Проблема в том, что не стоит переносить обработку критических данных на клиент. Может быть стоит открыть сокет соединение и передавать на сервер инфу обо всех действиях и назад забирать результат расчётов. В итоге flash код не будет иметь никакой секретной информации (то есть не будет расчитывать результаты, а заниматься только визуальной частью), поэтому проблема его взлома не будет стоять так остро.

по первым двум пунктам, ерунда-с. ну, пара китайских учёных нашла несколько коллизий на специально подобранных для этого данных. дальше что? кому удалось найти коллизию для мд5 в общем случае хотя бы в эн (где эн больше 1) раз быстрее, чем перебором? или что, если завтра очередной китайский гений таки додумается до этого, он сразу бросится ломать твою флешку ради ста уёв? или же он из наивно-альтруистических побуждений выложит свой сорц на http://breakMD5here.com/ ? люди переводят массу кода на шаХ по тем же причинам, что не едят курятину - паника совершенно беспочвенна.

Не считаю себя экспертом в криптографии, соответственно ссылаюсь на авторитетные источники, например Брюса Шнайера. Находим в них его отношение к md5 и к sha1. Вполне возможно, что он ошибается, но я бы прислушался к его мнению.

А он пишет, сколько нужно времени на взлом md5 ?
То есть если допустить, что каждому 5(10)-ти символьному паролю соответствует 33-х символьный "крэк", и оба они дают на выходе md5 одинаковые значения, что быстрее найти ?

12345

Замечательно, практическая криптография Брюса Шнайера.

1. Смотрим на год издания.
2. Смотрим блог Шнайера.
3. Смотрим ссылки, например "MD5 is dead".
4. Делаем выводы сопоставляя даты.
5 (опционально). Изучаем сайт и понимаем, что пользоваться стоит свежей информацией.

а ничего, что они сгенерили *ОБА* документа? если один из документов вне их контроля, угрозы по прежнему нет.

вот как обстоят дела в этом случае. только люди, обладающие ботнетами, могут в принципе претендовать на взлом мд5.

это... а почему бы не использовать проектор(projector)?

Товарищ, вы вообще о чем? Проектор защитит так же, как и в случае с обычной .swf

ясно... :) извините... ;) просто я подумал что там все запутаннее чем в свф... ну всмысле плеер плюс свф... может их как нить покаверкать ? так что бы невозможно было бы декомпилить... ладно бредовая идея... :) еще раз извините

я по поводу мд5, я был не прав таки...

так и в итоге-то, к чему пришли? я тут решаю подобную задачу.. мыслей 0.

И при плохом коннекте все это вылетит.
Хотя это не проблема, такое и так часто случается. Я думаю необходим способ восстановления разорванного соединения (не по инициативе сервера или клиента).

Сорри за пост, но не могу пройти мимо.. :)

1) Надежный путь СУЩЕСТВУЕТ, и имя ему - RSA. Можно много изобретать велосипедов, но в конце-концов придете именно к этому (Если, конечно, придете, а не застрянете раньше, все-таки не у всех научная степень по математике..)

2) В конкретной задаче (флеш-игра и отправка очков на сервер) вполне можно обойтись элементарным, ни капельки не криптографически стойким алгоритмом (так что обсуждения про MD5 здесь не к месту), а именно брать Score, умножать его на какое-то простое число A и прибавлять другое число B (B может не быть простым, но должно быть меньше A). И итоговую сумму отправлять на сервер, а на сервере уже размещать всю логику по защите от взлома, причем логика эта сведется к двум элементарным проверкам:
Что присланное число при делении на A дает в остатке B
Что приславший его не был замечен в читерстве до этого.

Второй пункт, правда, не совсем элементарный, тут можно на самом деле много всего проверять и учитывать (IP, User-Agent, сессию, логин и т.д.) но в любом случае это делается НА СЕРВЕРЕ, а значит злоумышленник не имеет доступа к коду и не знает, что там происходит. И даже досконально разобравшись в клиентском алгоритме, будет долго ломать голову, почему же все-таки оно не работает.. (потому что копать будет не там).

Насчет использования вместо y=Ax+B других функций (md5, sha1 и так далее) - ДО ЖОПЫ. Все равно код находится на стороне клиента (со всеми паролями и исходными значениями), все равно его можно повторить в "своей" флешке, все равно это НИКОГДА не будет криптографически стойко, поэтому разницы от использования той или иной функции на практике нет.

Чтобы усложнить хакеру жизнь, можно числа A и B не хранить непосредственно в коде, а "вычислять" долгим и запутанным алгоритмом (еще и размазанным по всему мувику, а не содержащемуся в одном месте). Причем можно сначала писать этот алгоритм от фонаря, а потом просто взять число, которое он вернет - а хакеру придется весь алгоритм разгребать (ну, или выдрать декомпайлером, так что повторюсь, лучше не хранить весь код в одном фрейме)... Но еще раз говорю, это лишь усложнит ему задачу, но НЕ СДЕЛАЕТ ЕЕ НЕВЫПОЛНИМОЙ.

Если нужен надежный путь - смотрите начало поста. Правда, RSA придется реализовывать самостоятельно (я на AS еще готовой реализации не видел, но есть куча на яваскрипте - переделать займет полчаса) и работать он будет ооочень медленно, учитывая как вообще все на флеше работает. Но насколько я знаю это единственное решение данной задачи (задача-то частая, на самом деле), которое изобрело человечество.

Upd:
Кстати, вот еще подумал, что асимметричный ключ вообще-то реализован в https:// - так что может быть можно отсылать данные с помощью GetURL, а не LoadVariables() - и тогда стандартная PHP-шная реализация сессий в общем и будет гарантом аутентичности данных..

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

имхо лучшая защита от лома - хранить и обрабатывать инфу на стороне сервера. От клиента отсылать инфу: куда нажали, что нажали, скока раз нажали и получать информацию о том, что можно нажать, где нажать, скока раз нажать (образно говоря)

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

эту проверку учесть при отправке результата.

сервер сравнивает результаты (он уже знает про проверку)

читеров сразу банить с вытекающими последствиями.

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

как предложение?

Тоже столкнулся с такой проблемой и кажется нашел выход.

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

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

Пока не вижу способа заломать этот алгоритм. Если конечто не учитывать возможность взлома сервака и записи в нашу папку чужой флэшки :) Это уже маразм будет.

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

Теперь осталось придумать, как запускать флэшку, когда она находится физически в нужном каталоге на серваке, а не в кэше браузера на диске пользователя. ;)

А флэш вобше может работать с файлами? Непосредственно создавать их? :bye:

Разве что локальные шареные объекты, только в одной папке, и только на клиенте :)

Полный крах моей теории :away:

:) http://flasher.ru/forum/showpost.php...85&postcount=6 описание способа защиты для такого типа игрушек, как вам надо. Но требует внесения довольно значительных изменений в саму игру...

...и только если это Windows Projector (exe).