Защита флешки.
 

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

Так вот возник вопрос:

А можно ли защитить код flash приложения или нет?

Нормальное флэш-приложение имеет еще и серверную часть. Которую вытащить значительно сложнее.
А без нее флэшка - это дырка от бублика... Соотв. к чему париться? :)

Ну, блин я понимаю что кое-что может храниться на сервере, но дживок то будет в файле флешки :(((

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

Имхо, КРАСТЬ __движок__ без мануалов и т.п. можно только очень маленький простенький и в конечном счете нафик никому не нужный вне рамок узкоспециализированного применения.
Если движок огромный и навороченный - крастье его это все равно что винду декомпилять.
Соотв - стырить можно, нормально юзать - малореально. Пока вор его освоит - я уже напишу более новый и лучший. имхо.

Нажал да)) Защищаться от какого-то неведомого нехорошего человека не имеет смысла. А защищаться от вполне конкретных с именем и фамилией очень даже можно )))

Не согласен, можно украсть что-то большое и иногда даже до релиза и это плохо!
Что от декомпиляторов невозможно спастись???

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

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

О чем голосование вообще? Можно ли защитить флешку или стоит ли защищать флешку?

А можно ссылку на "супер-мега адское приложение на флеше" которое хоть кто нибудь хотел бы декомпилировать и украсть оттуда код?

После смерти покажут :D

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

У меня код не разу не воровали, арт воруют часто, но мне не жалко, я в своё время тоже графику воровал.

От кого защищать приложение? От новичков, которым просто интересно как все работает?
Продвинутые кодеры вряд ли будут тырить код. А серьезные операции нужно проводить на сервере.
На счет графики вообще можно не париться. Ее можно стырить абсолютно из любого приложения, и никакие водяные знаки не помогут. От любого водяного знака можно легко избавиться в фотошопе

п.с. В чем суть опроса?

Пожалуй, самый правильный ответ — все зависит от самой флэшки, но преимущественно защита не нужна.

Защита флэшки:
да
нет

а) защищаете ли вы флэшки
б) помогает ли защита
в) нужна ли защита

Могу дать ссылку но... нельзя...

Ну расскажи в двух словах что там такого уникального что всем так хочется заиметь.

Неужели банк-клиент на ас3? )

Например вот эти товарищи очень чётко смогли организовать прозрачность для мыши растровых картинок в прозрачных участках
http://vkontakte.ru/app612925
А посмотреть как они это сделали проблематично :(

Как-то так
http://dougmccune.com/blog/2007/02/0...nt-png-images/

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

Нужно ли прятать?
"А вдруг чел сопрет мою идею и сделает свой проект на 10% быстрее, чем мог бы и конкуренция среди подобных приложений подымется на 0.0001%" - всетки сомнительный стимул. Если бы им все руководствовались - на этом форуме никто бы никому не отвечал - зачем конкурентов плодить.

Я про эту же игру писал :о)))

Печалька
Вложение 26497

Во Альтернатива 8 вышла, теперь можно сказать.
Альтернативу 8 можно было вытащить из дэмки MaxRacer.

Просто хочу уточнить: пробежаться по мувикам с верхнего по нижний до первой "встречи" с непрозрачным пикселом — это "проблема", во имя решения которой нужно декомпилить чужие приложения?

Вообще да, сделать это аккуратно проблема. Например как сделать чтобы посылались мышиные события, если мувик под мышкой сместился или вообще его снесли, а мышку не двигали - на энтерфрейм повесить? Вот интересно сделали так авторы или придумали что-то по-хитрее.

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

P.S. Вы сами то эту проблему с прозрачностью решили? Может тему в AS3 ветке создать?
P.S2. Вот эти товарищи http://vkontakte.ru/rules_of_war, например, не осилили, или не слишком надо было.

"Мне бы ваши проблемы" ©

посмотри здесь:
http://blog.mosessupposes.com/?p=40
демо:
http://www.mosessupposes.com/utiliti...ePNG_demo.html

в 90% случаях, её нет смысла защищать. Я бы стал об этом думать, если у меня сложная авторизация пользователя. Кодированные пароли с ключами и т.п.

Вам решить проблему(придумать варианты) или декомпильнуть?

Вот вам еще вариант - трейсим и отрисовываем картинку и нормально перекрываем области
http://wahlers.com.br/claus/blog/as3...er-as3potrace/

Про поиск пути вообще куча исходников и библиотек в сети.

Спасибо, правда я на это раньше натыкался - отпугнуло создание битмап-даты для объекта и наличие обработчика ENTER_FRAME.
Если второе прочтение кода по ссылке не поможет -
повешу наверно свое пробегание по всем объектам под курсором на EnterFrame - один фиг пользователь активно мышкой водит, так что перевешивание с MOUSE_MOVE на ENTER_FRAME может и не просадит ничего.

Проблему. Код "чужого" приложения читать весьма интересно - но для этого можно декомпильнуть и что-то другое :)

Короче, хватит про прозрачный PNG - если не осилю - тему в AS3-ветке создам.

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

Что я там хочу видеть? Комментарии по предложенной библиотеке:
- отрисовка вектора, судя по демке нехило жрет проц (хотя удивительно что оно вообще так быстро работает)
а если картинка анимированная - каждый кадр так перегонять?
- отрисованный вектор будет жрать в разы больше проца при ренреринге, чем PNG
Итого просто повесив свою проверку на ENTER_FRAME я секономлю гораздо больше, чем при использовании этой чудо-либы.

http://www.flasher.ru/forum/showpost...44&postcount=9
http://www.flasher.ru/forum/showpost...4&postcount=16
Три страницы флуда. Кто нибудь ответит на вопросы, о чем вообще опрос?

- Там есть исходники https://gist.github.com/940219, автор зачем-то еще накладывает blurFilter с хорошим качеством, вобщем оптимизировать есть куда.
Если картинка анимированная, тогда надо смотреть по ситуации - возможно экономичнее использовать метод с прозрачностью. Вообще нет универсальных решений, есть те, которые, больше подходят в данной ситуации.

- cache as bitmap (как самый простейший вариант) никто не отменял. Да и не факт, что без этого будет "жрать в разы больше проца при ренреринге", там не такой навороченный рисунок выходит.



@alatar
Тут не флуд, а просто уже другое обсуждают ;)

Все-таки решил опробовать подход http://blog.mosessupposes.com/?p=40
Внимательно перечитал код
Там они ухитрились не использовать getObjectsUnderPoint (а он глючный)
- от совершенно неприемлемого создания битмап-даты удалось избавиться
- ON_ENTER_FRAME, как оказалось, работает не на всех объектах в постоянном режиме, а лишь на тех, в прямоугольные границы которых попадает мышка в данный момент.
Т.е. вполне годное решение, если напильником обработать.