Передача неповрежденных данных из Flash-приложения на сервер?

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

Один простой способ - выполнить некоторые операции с данными, такие как хэш, и передать хеш обратно на сервер вместе с данными. Однако это легко сломать кто-нибудь, имеющий доступ к исходному коду клиента.

Изменить: я понимаю, что ничто не может быть взломано, но я хочу сделать это как можно сложнее. Я думаю, что решение @ jcnnghm для шифрования данных с открытым ключом и, при желании, проверки работоспособности и / или пересчета с игровыми журналами, является лучшим вариантом. SSL-шифрование также является хорошей идеей, поскольку это затрудняет расшифровку того, что на самом деле отправляется обратно на сервер.


person pix0r    schedule 05.09.2008    source источник


Ответы (5)


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

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

Обновление: @mark: Flash изначально поддерживает SSL.

person jcnnghm    schedule 05.09.2008

Может ли код, работающий на ненадежной платформе, сохранить свою целостность? Нет, десятилетия неработающих схем защиты от копирования приводят меня к выводу, что это невозможно. Обратный вредоносный код, работающий в надежной песочнице, возможен, но лучшее, что вы можете сделать со своей проблемой, - это сделать так, чтобы людям было неудобно жульничать.

person erickson    schedule 05.09.2008

Ознакомьтесь с пакетом AS3Crypto по адресу http://code.google.com/p/as3crypto/. Я не пробовал, но этот пакет утверждает, что (частично) поддерживает протокол TLS 1.0.

TLS обеспечит безопасный туннель между вашим Flash-приложением и сервером. http://en.wikipedia.org/wiki/Secure_Sockets_Layer

@jcnnghm Обычно вы не хотите использовать шифрование с открытым ключом (RSA, DSA) для массового шифрования данных из-за «большого времени вычислений». Шифрование с открытым ключом должно использоваться на этапах установления связи и согласования ключей в протоколе безопасности, но шифрование массивов данных должно обрабатываться с помощью симметричного шифра, такого как AES и TDES. Так работают протоколы TLS и SSL.

person markus    schedule 05.09.2008

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

Музыкальная и киноиндустрия потратили десятки миллионов на DRM, которую домашние любители взломали за дни / недели. Если они не могут защитить свои вещи ...

person ceejayoz    schedule 05.09.2008

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

Другой подход, который я планировал, - это создание уникальных ключей pr. сеанс игрока (включая какое-то время / дату в качестве значений соли).

Затем через приложение, возможно, периодически отправляя / передавая оценку статуса и получая новый действующий ключ. Если эта синхронизация не удалась, прервите весь сеанс.

Обратной стороной этого может быть слишком много одновременных игроков, которые снижают скорость ответа сервера и, следовательно, создают «ложные таймауты» + оставляя игровой сервер открытым для DoS-атак.

Но что-то с обновлением «сеансового ключа», когда у пользователя есть сеанс, потребует немного дополнительного управления сеансом, но если это заставит читеров работать немного сложнее, я обязательно попробую: o)

С другой стороны, НИЧЕГО не защищено от взлома, поэтому не верьте ему на 100% - какое бы умное решение вы ни придумали.

Последнее замечание также может заключаться в разделении вашего приложения на модули / уровни и т. Д., Чтобы вы не получали доступ ко всем частям кода, просто запустив его.

В настоящее время я планирую построить большой многоуровневый мир, и клиент / игрок будет получать файлы, прикрепленные ТОЛЬКО к той части, в которой находится игрок.

Надеюсь, это принесет пользу вашим мыслям.

person BerggreenDK    schedule 09.08.2009