Какие методы обычно используются для защиты SWF от декомпиляции или, по крайней мере, предотвращения кражи кода / ключей? - PullRequest
2 голосов
/ 30 декабря 2010

Поскольку общеизвестно, что SWF-файлы легко декомпилировать, если я распространяю SWF с защищенными ключами внутри или каким-то ценным кодом, как мне его защитить?

РЕДАКТИРОВАТЬ: я думаю, что очень легко декомпилировать SWFпотому что он был закодирован в SWF и затем запущен.То же самое происходит с компиляцией и выполнением Java.Означает ли это, что даже Java-коды недостаточно безопасны?

Почему тогда Java гораздо более надежна и надежна, а SWF нигде не считается безопасным?

Ответы [ 5 ]

5 голосов
/ 30 декабря 2010

Краткий ответ: НЕ ДЕЛАЙТЕ этого.Даже с запутыванием кода или хранением данных в байтовом массиве НЕТ СПОСОБА препятствовать тому, чтобы определенный (и способен) получить что-либо и все из вашего источника.

Какой тип безопасного ключа вы пытаетесьположить в свой SWF?Для чего он будет использоваться?

2 голосов
/ 31 декабря 2010

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

Защита кода и IP - это другой вопрос.Здесь запутывание и «шифрование» (т. Е. Все, что делается для предотвращения правильной работы декомпиляторов) являются допустимыми методами.Если ваш код достаточно запутан, конкурентам будет очень трудно украсть его или узнать слишком много о внутренностях вашего кода.Это просто невозможно.Черт, пытаться выучить чужой код достаточно сложно, и поэтому пытаться расшифровать код, который выглядит как loc_12312++; if (loc_23423) loc_4345();, просто не стоит никому времени.

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

Редактировать

Мой опыт работы с инструментами обфускации Flex заключается в том, что для получения того, что вам нужно, вам нужно довольно сильно подправить запутывание.Простое указание программному обеспечению для запутывания переименовывать все переменные, классы и т. Д. Обязательно нарушит работу вашего приложения, если только это не очень просто.Таким образом, вы должны выбрать, какие пакеты и классы запутать и настроить различные другие параметры, чтобы получить работающее приложение.

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

alt text

1 голос
/ 30 декабря 2010

Я бы переосмыслил то, что вы помещаете в SWF.Тем не менее, если вы не видите других вариантов, NitroLM имеет SWF-шифратор, который позволяет шифровать SWF. Sharify является альтернативной службой.

Теоретически вы можете написать свой собственный механизм для шифрования SWF-файла и свой собственный "EncryptedSWFLoader".Конечно, я подозреваю, что любой ключ в SWF, скорее всего, будет тем, что вам нужно отправить обратно на сервер;а то, что кто-то прослушивает пакеты - с помощью такого инструмента, как ServiceCapture или Charles - с большей вероятностью будет источником "утечки ключей", чем дешифрования SWF.

0 голосов
/ 30 декабря 2010

Редактировать: Игнорировать этот ответ: не заметил ' Распределение ' часть **

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

Как это распространяется?

0 голосов
/ 30 декабря 2010

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

...