защита роликов от копирования. конкурс.
 

добрый день всем любителям и некоторым профессионалам скрипта.
требуется написать алгоритм защиты .swf-роликов от несанкционированного копирования.

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

требуется сделать так, чтобы этот .swf-ролик шёл только на тех сайтах, которые прописаны в .txt-файле, а на других сайтах выдавал "ahtung! попытка несанкционированного доступа! verbotten!";

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

если кто предложит вариант, который нам понравится (напр. который не удастся взломать), заплатим золотом.

варианты шлите сюда или на webzavod@mail.ru. вообще, если кто-нибудь сталкивался с проблемой защиты .swf-содержимого, пожалуйста, напишите, чего вам удалось добиться и как.

для начала кладём сотню wmz в качестве приза..

Защитить никак нельзя, всё взламываеться. ВСЁ.

Мои мысли по поводу защиты флеша:
1. Ломается все ( !В!С!Е! )
2. Защитить можно только в силу своих возможностей, но нет гарантии, что найдется в мире человек, который всю твою защиту ломанет за полчаса
3. Делал когда-то защиту такую - проверка загруженного URL, запрет кэширования, проверка переменной, полученной из страницы html, далее защита от декомпилирования. Через два или три дня мне принесли мою флешку на диске, со всеми вложениями, красивую такую.... Некоторые фичи там не работаил, но это просто потому, что ломал 10-тикласник (!), и ему впадлу было разбираться, почему не работает какая-то там строчка из 1000.

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

Согласен с предыдущими сообщениями, защита может быть только на уровне "от чайников".
Теперь по теме:
А если концепцию с txt файлом со списком доменов заменить на концепцию использования crossdomain.xml? Тогда можно использовать в качестве разрешения для полной загрузки фильма загружаемую loadVars. И тогда защита сведется к защите файла crossdomain.xml от редактирования, собственно, уже задача переходит с уровня защиты файла Flash на уровень защиты сервера.

а помоему можно защитить и от средней категории флэшеров =), где одногоз нания AS(любой степень сложности) недостаточно, а требуеться знание asm и p-code.

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

Это как бы дополнение к crossdomain.xml + еще какихто извратов на стороне сервера.

Хм, ну тут все понятно, но человек не хочет это делать все сам, а предлагает нам это сделать.

З.Ы. За деньги...

ОпенСоус навсегда.

Смотря сколько он "за денег" дает %)

а скока надо?

побольше на пару порядков, как минимум.
Насколько я помню, Macintosh предлагал то ли 10000$, то ли 20000$ и всё равно взломали. (точнее предлагали за взлом)
Так то ОС была, а здесь жалкий файл, который не зашифрован, никак вообще не защищён.

Дуся, клиентскую программу нереально защитить, она работает на компе пользователя, абсолютно неподвластно воздействию сервера. Ты сама подумай, что можно сделать, если ролик по кадрам снимать фотоаппаратом с экрана монитора? Любой скрипт тоже можно взломать, а байт код as - так вообще без проблем. Было бы желание...

А где гарантия, что не будет финала "не понравился ни один" ?

Ну почему же, могут и написать кого-нибудь. Типа, победил Вася Петров из Кукуево, наши поздравления. Вася будет сильно удивлён.

Защитить нельзя, но можно создать огромное кодличество проблем тем людям, которые будут разбираться в файле.
Но всегда сможет найтись человек (самый терпеливый), который докопается до сути.
По сути, есть 2 варианта что защищать от взлома.
1. Не позволить скачать файл.
2. Не позволить его взломать.

Есть и третий вариант - никому его не давать и держать под подушкой на дискетке (с) (чей-то).

Если взломать можно ВСЕ, то не лучше ли заплатить денег крутым парням, которые будут жестоко наказывать тех, кто будет ломать ваши работы в коммерческих интересах, наводя ужас на остальных пиратов, и отбить охоту заниматься взломом конкретно вашей продукции? Опыт показывает, что это самый эффективный способ защиты от пиратства в России. Правда цена такой защиты не маленькая.

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

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

Вот я могу представить себе сепер проект - сайт, или, скажем, игру, но смысл их ломать? Чтоб понять как работает? Да ради бога! Над юродивыми не смеются, а игры на флеше делать и надеяся что не сломают - изврат. Вон на ранок сходите полюбуйтесь - гиганты игрвой индустрии тратят кк на защиту, а результат - 70 руб за диск... Еслиж баннеры так их вообще делать не особо прибыльно, нежалко, да и они неособо друг от друга отличаются. А вот если дело касаетя серверных программ - то флеш здесь пока вобще не властен.
ИТОГ: пока мы пытаемся создать защиту и выкладываем за ето кровные, нормальные люди творят и наслаждаются жизнью (деньгами).

бред какой-то ...
если кому-то будет нужно... то сломают

тока грубая сила *)

http://www.gotoandplay.it/_articles/...2eb166c309f557

как защитить свф от декомпилера.
прекрасный туториал, который поможет увеличить стоимость взлома вашей свф.
ведь на самом деле все взломают, важно увеличить затраты на взлом =)

З.Ы. главная проблема - это те кому делать нечего =) у них много времени,но мало знаний(иначе работали бы гденибудь), и много лени, если на взлом надо потратить более чем несколько часов, и бесплатные компиляторы не помогают, то задача по моему решена =)

Главная проблема - это те, которым заплатили за взлом.

мне понравился энтузиазм Дуси. :)
ясно вижу толпы программистов, ринувшихся к своим компам решать "конкурсную" задачу за 100 wmz...

объясню некоторые принципы.

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

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

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

есть готовые коммерческие тулзы, которые позволяют автоматически защищать код (amayeta swf crypt, например). но все они слабы против специалиста по байткоду в силу того, что действуют автоматически и не очень изобретательно.

к тому же, ASV5 работает уже довольно умно. простые методы против него не проходят.

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

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

именно. всё упирается в то, СКОЛЬКО заплатили.
всё, что можно сделать в этой области - сделать взлом весьма дорогим.

Точно! А что может быть дороже собственной шкуры? :cool:

Мона еще вставлять текст копирайта во флешку, отправить себе же заказное письмо с кодом, идеей и тд, а затем если сломают подавать в суд :)

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

А вот родился еще один безумный метод в моей не самой умной голове...
Инклудить в код файл с исполняемым на сервере расширением (php, asp, aspx, html...). Флешу глубоко по барабану на это расширение, а вот просмотреть содержимое, например, php файла не так то просто. Либо он выполнится (если вдруг каким-то чубесным образом совпадут синтаксисы php и flash), либо выдаст ошибку, что в принципе равнозначно. Ни имен переменных, ни адресов никто не узнает.

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

всё,что "инклюдится" во флэшку, попадает внутрь флэшки НА ЭТАПЕ КОМПИЛЯЦИИ. то есть, в момент работы программы, этот внешний файл уже не нужен -- всё уже внутри флэшки.

Как это защитить на серваке, если его все равно надо будет к клиенту затягивать:umnik2: ?

Интересно а если swf будет компилироваться на лету, это может помочь чем то защите?

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

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

вобщем сложно это. вряд ли стоит делать это на флэше.

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

ну, тут не в именах переменных дело. нужно что-то более интересное придумывать.

речь о сокрытии _алгоритма_ авторизации, а не только ключика или сессии.

То есть алгоритм должен быть каждый раз новый? :eek: Чего-то я уже запутался, совсем. Но одно ясно, то - что попадает на машину клиента, защитить от чего-то полностью невозможно! ;)

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