Загрузка SWF в контейнер с защитой от скачивания
 

Всем привет.
Хочу сделать хоть какую-то защиту своего проекта. Прочитал уже много статей по защите, про всякие методы запутывания, обфускаторы и т.д., понимаю что защититься полностью не получится никогда, но можно хотя бы отсеять часть неугомонных.
В общем есть контейнер, скомпилированный в *.exe и *.dmg.
Рабочий swf всегда будет подгружаться с сервера в этот контейнер при запуске.

1) Возможно ли реализовать так, чтобы swf грузился только в этот контейнер, но нельзя было скачивать отдельно, например, через браузер? Понятно, что профи и это обойдет, но все же..

2) Где-то встречал статью, что swf можно передавать в виде байткода - но как это реализовать? Или я что-то недопонял..

Заранее спасибо за советы.

1)идентифицировать на сервере кто запрашивает.Но эта скорее психологическая защита т.к. нажатие ctrl+shift+i и заглядывание в вкладку network вскроет всю схему.
2)тыц

undefined, а как смогут заглянуть во вкладку network, если контейнер десктопный?

можете пройтись по swf файлу обычным xor и расшифровать уже при загрузке бинарника в клиент

любой снифер - это и есть вкладка network

Шли из контейнера какой-то "секретный" ключ. Только получив который, сервер отдаст SWF. Используй https.

Дальше информация к размышлению ->
Вопрос: какой смысл его как-то защищать? В приложении есть что-то особенное? Какие-то супер алгоритмы, которые все мечтают заполучить? Или там вся логика работы, включая подготовку к записи в базу данных на клиенте?

На счет алгоритмов, как правило они никому нафиг не нужны. В сети и так полно всевозможных алгоритмов и ответов на форумах, так что можно найти практически все, что угодно.

По поводу какой-то важной логики, ее нужно делать на сервере. Работу клиента тут надо минимизировать.

Запросы, которые шлет флешка, в каком бы контейнере она не была, можно довольно легко перехватить. Даже если это будет по https. Чтобы перезватить https запросы, можно установить отладочный хром или огнелис, сделать логирование tls ключей, а потом сормить этот файлик wireshark'у. Вуала, трафик расшифрован.

Кстати, по собственному опыту взлома подобных флешек могу сказать, что запущенную флешку можно выдернуть даже из оперативки. Правда не в формате swf, а csw, но все равно поддающемся декомпиляции. Для этого даже есть готовые проги. Не помню как точно называется та, что использовал я, по-моему swf dupm или swf dumper. Но она с успехом дергала защищенную флешку из оперативки

Вывод. Профессионал взломает, если захочет. А от новичка будет достаточно простой обфускации

caseyryan, https да, собираюсь подключить comodo, это мне еще предстоит разобраться как оно работает - никогда не подключал, и уж тем более как потом еще swf будет общаться с сервером через этот протокол... Буду разбираться.
Насчет ключа - получается прийдется слать один и тот же ключ, чтобы его можно было идентифицировать на сервере?.. Или как-то можно идентифицировать генерируемый?
По поводу смысла защищать: приложение платное. Авторизация через соцсети и покупка ключей на сервере. Приложение запускается и требует ввести ключ. Вот хотелось бы немного защитить приложение.

Точно так же как по http, в логике флешки не меняется абсолютно ничего, кроме адреса, к которому она будет слать запросы
Если так, то самый разумный вариант, который мне приходит в голову - ассиметричное шифрование
Естественно, генерировать приватные и публичные ключи с помощью флешки занятие глупое. Она скорее всего "умрет" в процессе, так как он очень тяжелый. Но для этого можно использовать openssl.
То есть клиент присылает данные для покупки проги, например свой email и еще что-то. Ты генерируешь с помощью openssl и своего приватного ключа ему код доступа и отправляешь обратно. Он вводит в прогу те же данные, свой email и/или что-то еще, например номер телефона, главное чтобы это было использовано тобой при генерации ключа, и код доступа.
А дальше, прога клиента, которую ты ему продал, уже имея вшитый публичный ключ расшифровывает им код доступа и если расшифрованная строка совпала с той, что использовалась при шифровании (в данном случае его email), то все ок, если нет, то шлем его подальше и обрубаем прогу.
Код программы стоит обфусцировать, чтобы затруднить поиск алгоритмов расшифровки.
Но это, конечно же, не дает надежной защиты.
Мне как-то раз приходилось взламывать одно платное ANE для андроида (каюсь :D). Так там разработчик использовал как раз такой подход. Взломать его удалось буквально за 15 минут. Просто декомпилировал jar архив внутри, увидел, что код не обфусцирован и довольно понятен, импортировал этот декомпил в Android Studio, выпилил код проверки, и снова собрал. Дальше обновил jar внутри ane, и приложение излечилось от жадности)
Скажу честно, если бы код был обфусцирован, и алгоритм защиты спрятан получше, я бы не стал возиться, так как делал это больше из любопытства, чем от необходимости

По поводу обфускаторов - посмотрел, что-то они все больно дорогие.. Из всех приглянулся secureSWF, но как-то уж дорого-богато )
Расскажите пожалуйста, хотя бы вкратце, а как swf шифруется с помощью XOR ? Это весь код шифруется или только какие-то переменные?... Следовательно SWF лежит на сервере зашифрованная, а контейнер подгружает ее и уже расшифровывает, зная ключ?..

djken
Да, всё верно, подгружаете зашифрованную swf с сервера как ByteArray, выполняете xor декодирование и загружаете полученный ByteArray в Loader.loadBytes().

А ключ для xor где хранить? Опять же на клиенте. Это не защита. Кстати, даже если вшивать в другую swf, а ту вшивать как байт массив в овновную, то такая матрешка новыми версиями того же JPEXS уже вскрывается. То есть вшитые флешки там будут храниться как наборы байт, которые можно извлечь и снова декомпилировать. Так что не прокатит уже.

Забудь про xor, если делаешь патное приложение. Тем более, как я уже сказал выше
То есть все эти xor'ы останутся на этапе загрузки, а плеер / air будет воспроизводить уже рас-xor-ренную флешку)

JPEXS умеет извлекать из оперативки. Там уже рабочее приложение после всех распутываний из матрёшек и xor'ов. Никак не сделаешь защищенную от взлома флешку. Как только приложение станет пользоваться популярностью, то для него сделают кряк. И будут через него распространять свои malware.