SWF в bytearray из PHP-скрипта

я использую AMFPHP для потоковой передачи контента с моего сервера в мое приложение Flex, поскольку Flash является клиентской технологией, и я хотел бы затруднить захват защищенных файлов людьми, поэтому я создал систему, которая передает файлы swf на другой флэш-плеер, Я провел все тесты в потоке URL-адресов, теперь я хочу передать swf-файл проигрывателю как bytearray.. так как я думаю, что его безопаснее и труднее взломать, и в будущем я даже мог бы сделать собственное шифрование, если я стал лучше знакомиться с байтами и битами .. в любом случае, мой метод лучший? (SWF в ByteArray?) или есть лучше? если метод bytearray является лучшим, я столкнулся с проблемой вывода файла swf в правильном формате, я использую очень примитивный метод..

        $file = file_get_contents($file); 
        $byteArr = str_split($file); 
        $byteArr = array_map('ord', $byteArr);
        $return['fileBin']->data = $byteArr;

и я возвращаю переменную $return...

ваша помощь очень уважаема и ценится.

Рами


php apache-flex bytearray amfphp
person Rami GB    schedule 07.11.2010    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Hm...

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

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

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

Еще один хороший способ — токенизировать запросы (+1). т.е. в PHP вы создаете «токен» и записываете его в файл списка токенов. Токен будет состоять примерно из 32 буквенно-цифровых символов. Этот токен также будет передан запрошенному объекту/странице SWF, который сразу же будет использовать его в запросе. Запрос работает ТОЛЬКО с валидным токеном, то есть с тем, который был записан в token-list. При использовании моментально удаляется. Кроме того, для каждого токена может быть ограничение по времени. Вроде 15 или 20 секунд. Если к тому времени он не используется, удалите его. На стороне пользователя (если загрузка слишком длинная) необходимо будет перезагрузить (хотя и не вручную - может быть какой-то скрипт или iFrame для перезагрузки только SWF), если лимит времени был превышен.

EDIT: автор вопроса задал по-другому - его цель, по-видимому, состоит в том, чтобы сделать запрошенный SWF-файл доступным/загружаемым ТОЛЬКО приложением-загрузчиком. Ничего больше. Так:

Боюсь, это сложно, но... На самом деле невозможно сделать что-то, что невозможно взломать/взломать. К счастью, это проще сделать в сетях (хотя они чаще подвергаются атакам) или в Интернете. Вы НЕ МОЖЕТЕ сделать что-то, что может быть загружено только вашим приложением. Если подумать - это невозможно даже логически - в обоих случаях (запрошенный пользователем И запрошенный приложением) компьютер пользователя запрашивает один файл, и этот запрос легко отследить и воспроизвести или просто перехватить. Декомпиляция SWF-файлов будет использоваться, если какой-либо из первых двух не работает. Немного о противодействии всем возможностям:

А) отслеживать и копировать

Это легко сделать с помощью таких инструментов, как Firebug в FF или не менее хороший (действительно) Inspector в Safari. С их помощью легко увидеть, что было запрошено, заголовки и ответ (к счастью, невозможно загрузить запрошенный файл - он не записывается, если это не html или обычный текст MIME), а также заголовки ответов.

Нет смысла запутывать URL-адрес запроса в коде, если он в конечном итоге будет отображаться в соответствии с запросом в консоли одного из этих инструментов. Решения будут:

  1. сделать запрос только один раз (показано выше - токенизация)
  2. используйте специальный заголовок для запроса, например «Соединение: keep-alive» — это значительно усложняет задачу для обычных злоумышленников, потому что они часто просто копируют URL-адрес и запрашивают его в браузере — но соединение там будет автоматически «Соединение». : close", проверьте это в коде на стороне сервера и принимайте только запросы проверки активности (или ваши "специальные") запросы
  3. используйте протокол, отличный от HTTP - к сожалению, это включает в себя функции сокета на стороне сервера для связи через порты, отличные от HTTP 80 ... большинство поставщиков серверов не позволяют пользователям делать это, но если вы можете - и хотите безопасности - сделайте это - не не использовать какой-либо известный протокол, а скорее то, что соответствует вашим потребностям - в конце концов, вы контролируете как серверную, так и клиентскую стороны, поэтому связь может осуществляться как угодно

Б) перехват

Это атака немного более высокого уровня, но если злоумышленник опытен и имеет НЕКОТОРЫЕ ресурсы, это не так сложно сделать. По сути, это связано с наличием прокси-сервера (отсюда и ресурсы - потребность в сервере с включенными сокетами, который у меня есть :D), который он будет использовать для подключения через свой браузер. Однако прокси будет не только пересылать контент, но и одновременно записывать его. Противодействие:

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

В) декомпиляция

Это даже не так сложно сделать — декомпиляторы SWF сейчас не являются чем-то новым, и любой код из вашего приложения находится в свободном доступе для злоумышленника. Даже если вы используете другой протокол, злоумышленник может с меньшими или большими усилиями взломать его. Решения:

НЕТ — вы можете просто усложнить задачу злоумышленнику — запутать свой код, иметь его много (если вы действительно ХОТИТЕ безопасность... хаос может быть просто вашим друг), используйте кросс-клиентские кросс-серверные запросы для фактического кода - динамически загружаемые вторичные SWF-файлы, которые загружают код...

person Aurel Bílý    schedule 07.11.2010
comment
я проголосовал за ваш ответ и помощь, но, к сожалению, это не то, что я ищу, я перефразирую свой вопрос, скажем, у меня есть файл, файл SWF, который я хочу транслировать только на свой SWF-плеер, используя класс загрузчика, как лучше всего сделать этот swf загружаемым только приложением flex? я знаю, что заголовки могут быть подделаны, и установка токена не усложнит ситуацию, поскольку люди с отладчиками, такими как firebug, смогут узнать запросы, сделанные между приложением flash и сервером ... :( я застрял здесь! - person Rami GB; 07.11.2010
comment
Боюсь, это не совсем просто... Редактируя мой ответ, я думаю, это будет более длинный ответ. - person Aurel Bílý; 07.11.2010
comment
Сделанный. Он действительно длинный, но он охватывает множество потенциальных угроз и решений. - person Aurel Bílý; 07.11.2010
comment
чувак ты гений! Спасибо! я собираюсь использовать другой метод протокола, это даже не приходило мне в голову: D, и, конечно же, запутать мой плеер .. еще раз спасибо за длинный ответ, я собираюсь попробовать возиться и объединить некоторые идеи, которые вы при условии :) - person Rami GB; 07.11.2010
comment
:D Нет проблем... Я должен, наконец, сделать этот девблог для них :D - person Aurel Bílý; 07.11.2010