защитить код флешки от декомпиляции

[chingachgoog]

Сообщение от eGanz

Эта операция замедляет работу?

Вообще чем длиннее имя переменных и т.п., тем дольше флеш думает. Так было ранее, как теперь не знаю (так Гурский думает, но я не проверял)

Есть более простые способы с байт-кодом - см. поиском тут.

[etc]

Сообщение от chingachgoog

Вообще чем длиннее имя переменных и т.п., тем дольше флеш думает. Так было ранее, как теперь не знаю (так Гурский думает, но я не проверял)

На тему длин имен мы уже говорили. К консенсусу не пришли, ибо результаты тестов странные. В целом, от длины мало зависит.

[aksios]

Сообщение от chingachgoog

Вообще чем длиннее имя переменных и т.п., тем дольше флеш думает.

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

[CorC]

Хочу стать "hex маньяком" есть где почитать как это сделать?

[etc]

Боюсь, что подобных консультаций здесь на форуме не будет.

[aksios]

Сообщение от CorC

Хочу стать "hex маньяком" есть где почитать как это сделать?

Ваще на албанских флешовых форумах не в пример нашим по этой теме информации выложено. Целые разделы. Ищи.

[chingachgoog]

Сообщение от aksios

А при чем тут длины переменных?

А как обсфуркатор работает?
Меняет имена на всякую абракадабру. Делает корректно отдекомпилированный код нечитаемым для глаза (но для машины)
Если я правильно понимаю.

Сообщение от aksios

Вот с байткодом флешка может стать не адекватной.

Пока не замечал, "96" работает и защищает на приемлемом уровне.

Сообщение от aksios

А тут игры с hex смещениями - код даже компактней выглядит.

Не понял. Где именно "тут"?

[aksios]

Сообщение от chingachgoog

А как обсфуркатор работает?
Меняет имена на всякую абракадабру. Делает корректно отдекомпилированный код нечитаемым для глаза (но для машины)
Если я правильно понимаю.

Все намного сложнее.

[chingachgoog]

Смысл же тот же остался?
Обсфуркатор поменял имена переменных на нечитаемые и ДЛИННЫЕ и сделал много чего еще (в ссылке видно).
У Гурского было сказано (из бесплатного добавления 20.2. Оптимизация):

Сообщение от Гурский

Производительность кода довольно заметно зависит от длины имен переменных, свойств и функций. Чем длиннее имя, тем больше требуется времени на то, чтобы найти связанный с ним объект данных.
...
Проводить тестирование производительности стоит в тех же условиях, в которых фильм будет работать. Дело в том, что встроенный в среду разработки Flash плеер обладает рядом дополнительных возможностей, поэтому он занимает больше памяти и работает несколько медленнее, чем плеер автономный. Как это не странно, но плеер в Internet Explorer немного более производительный по сравнению с автономным плеером. Однако если открыть два окна браузера со страницами, содержащими swf-фильмы, то скорость выполнения кода резко упадет. Производительность падает даже, если окно браузера с фильмом теряет фокус. Замечено, что плеер для Mac OS значительно более требователен к машинным ресурсам, чем плеер для Windows. Поэтому если ваш клиент работает на Macintosh, стоит быть готовым к тому, что созданный вами фильм будет “тормозить” на его машине значительно более сильно, чем на вашей.

[aksios]

Переменные это самый приметивный уровень. Обычно то, что выглядит даже как переменные не просто "закодировано", а это часть более сложной системы защиты, т.е. имя не абракадабра, а логически заданный кусок кодового сообщения. Т.е. при такой записи набор переменных + операторы которые отображаются никак не соответствуют исходнику.
В отношении Гурского: есть сомнение, что он так лохонулся, что стал сравнивать длины имен переменных в прямом смысле - скока символов букв в названии. Вроде как под имя переменной всегда выделяется одинаковая по размеру ячейка. Скока в ней останется нулей значения не играет.
Скорее речь о локальных переменных внутри еще кучи объектов. Длина имени такой переменной будет длинной, а поиск ее затруднительным.