Сразу скажу что к flash отношения я не имею, но возможно в ближайшее время придется столкнуться. ( я по часли java, oracle и тд).

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

Как я уже сказал, работы с технологией flash у меня нет, поэтому прошу прощения за наивные, возможно, вопросы.


Собственно вопросы:
1) Нужно разработать обучающую систему на флешь, и  защитить контент, предоставляемый через идентификацию пользователей. Нет защиты - разработка теряет смысл.
Интересно послушать комментарии, я знаю что некоторые американские компании, например, предоставляют такого рода контент и защищают как могут, видел что используют динамическую загрузка flash из другого flash.

2) Есть ли у технологии флешь возможность писать client-server приложения в принципе, и в частности с поддержкой сессии.


Обычно советуют следующие общие шаги , для защиты в принципе.

- Use Actionscrip obfuscator like SWF Protector
- Server side protection by using htaccess URL rewrite and hotlink preventing rules that will hide/mask the URL to your SWF
- Encryption with As3crypto library
- Load SWF at Runtime. Just embed an SWF as a ByteArray into the loader SWF and it can be loaded through Loader.loadBytes().
Reply With Quote

Особенно интересен последний пункт, можно ли что-то выжать из динамической загрузки?

Также слышал о выпуска Adobe Flash Access 2.0 но пока не разобрался чего с его помощью можно добиться.

Спасибо

Все верно пишут. По-поводу последнего пункта я тут примеры приводил.

Надо учитывать следующую вещь. Флеш Плеер (браузерный) требует строго определенный байт-код. ФП находится на стороне клиента. Поэтому защитить ваш байт-код строго говоря невозможно, а все рекомендации выше - создать условия, когда будет ЭКОНОМИЧЕСКИ не выгодно ломать защиту (но ФАКТИЧЕСКИ это сделать можно).
Но если использовать НЕ браузерный ФП, то можно сделать что-то и поинтереснее. Но пользователю придется скачивать вашу надстройку, что для коммерческих обучающих систем вполне приемлемо.

 предлагаю один способ защиты самого swf-файла.
если это локальное приложение (swf записанный в exe), то можно нагрузить его всяким бесполезным мультимедийным содержимым (а проще говоря, раздуть в весе) мег до 100-150...
мало какой декомпилятор переварит такой кусок инфы...

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

Zeleboba

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

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


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

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


Это наиболее распространённый метод - наиболее часто с ним сталкиваюсь в последние годы.


И в принципе, и в частности. Сайтов на флеше, в том числе динамических, ты можешь найти в Сети немало. В том числе и таких, которые использую аутентификацию. И помимо client-server приложений на флеше, можно сделать и приложения с поддержкой сессии.


Про Adobe Flash Access я ничего не слышал, а упомянутые тобою советы - это рабочие и распространённые методы защиты флешки. Которые, как я уже сказал, предназначены лишь для усложнения процесса доступа к контенту (и их можно обойти). Так что полноценная возможность защитить флеш-контент есть лишь для локального контента, но не для флешек распространяющихся в Сети.

Как я уже сказал выше, полностью защитить флеш-контент при распространении в Интернете невозможно. Зато это можно сделать при распространении локально (в частности, в виде exe-шников).

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

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

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

Спасибо за ответы, довольно подробно написали.
Много хороших идей.

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

Поправте меня если что не так.

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

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


2) Честно говоря в голову не приходило делать работу с флешом автономной, пока не назвали такой вариант. То есть  в этом случае вся логика находится у пользователя на машине.
Но идентификация ему все равно нужна. То есть эта автономная флеш в своем коде должна коннектиться к серверу для идентификации, а иначе отказываться работать.
Что в этом случае можно сделать если нет логина/пароля? Нужно декомлилировать и убирать проверку идентификации из кода. Что можно этому противопоставить уже написали выше.

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

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


Спасибо за ответы, без сомнения они полезны.

Вариант 1 - в общем стандартный вариант защиты. Но от кражи контента он спасает только экономически. Флеш клиент он на то и клиент, что его придется скачать пользователю, а значит к нему будет доступ для декомпиляции.
Вариант 2 о котором я писал выше не совсем законный. Вам придется создать СВОЮ оболочку, куда будет внедрен адобовский ФП (вот этого-то и нельзя делать по условиям лицензии адоба). В ВАШЕЙ оболочке моно получать доступ к сети и забирать из сети ЗАШИФРОВАННЫЙ контент, который будет внутри оболочки расшифровываться и скармливаться в ФП.
Стойкость защиты тут будет зависеть от оригинальности оболочки и ее зашифрованности.
Например, старфорс ставит жирный крест на попытках взлома такой оболочки (да и адоб не увидит там свой ФП, если в последнем нет какой-нибудь хитрой аутентификации - но вряд ли вы сделаете что-то такое, что заставит адоб присматривать за вами)
(хотя появился очень интересный опенсорсный проект, направленный как раз на то, чтобы обойти ограничение адоба - http://code.google.com/p/extprojector/downloads/list) - да здравстует alexcon314!!!