Как защититься от SWF-декомпиляторов

Что кроме лени помешает злоумышленнику экспортнуть внедренный swf и скормить его декомпилятору?

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

Если можно, киньте swf который невозможно декомпильнуть. Задайте какой-нибудь переменной какое-нибудь контрольное значение внутри. Публика попробует поломать, тем самым доказав вашу или не вашу правоту.

Не могу скачать. Видимо слишком зашифровано. :-) Положите на народ пожалуйста или что-нибудь «широкое».

UFO appears suddenly?

Буквально недавно обходил более веселую защиту, чем эту. Кроме прочего, исходник был «защищен» от декомпиляции. Зачем это делать? Если что-то исполняется на стороне клиента, он *может* его исследовать/изменить/разобрать.

//class Main
package 
{
    import flash.display.*;
    import flash.events.*;
    
    public class Main extends flash.display.Sprite
    {
        public function Main()
        {
            super();
            if (stage) 
            {
                this.init();
            }
            else 
            {
                addEventListener(flash.events.Event.ADDED_TO_STAGE, this.init);
            }
            return;
        }

        internal function init(arg1:flash.events.Event=null):void
        {
            removeEventListener(flash.events.Event.ADDED_TO_STAGE, this.init);
            var loc1:*=String("UFO appears suddenly");
            return;
        }
    }
}

В Trilix он бинарным файлом. Сохранил и открыл сразу :-)

Спасибо за утро! Движуха мозговая хоть. Приятно. :-)

Отвечая на вопрос из топика — «Просто перестаньте юзать флэш»

Всё, что скачивается на комп юзера может и будет взломано. Это ж аксиома.

Вне зависимости это флеш или хтмл5й

Есть одно ноу-хау у меня:
1)на AS2 делать SWF
2)внутри нее в base64 байткод SWFки на AS3
3)Обфусцируем
4)Делим на части по 250 байт
5)Кодим в base64

6) Распихиваем как текст в кастомное поле EXIF произвольных джипегов.

7) При загрузке ресурсов проверяем каждый загруженный ресурс на наличие EXIF
8) Сливаем все части ведино, переводим в байткод и LoadBytes();

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

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

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

Таким образом мы ограничиваем время на вычисление последовательности и осознание принципа сборки 30-ю сек.

Как спастись от декомпиляторов? Не компилируйте.

Хочешь защитить приложение — делай клиент тонким и переноси всю логику на сервер.

UFO appears suddenly
15 минут. 010Editor + Sothink + тулза для распаковки флешек самопальная(потом только узнал что есть уже готовые).

помнится много лет назад iviv с не менее продвинутыми товарищами (простите, имена уже не вспомню) ваяли какой-то гиперхитрый протектор который базировался на хитрых манипуляциях с байткодом, позволяющих оставить байткод все еще читаемым плэйером, но заставляющий капитально заткнуться декомпиляторы. И вроде даже все было круто и работало… А потом началась чуть-ли не юридическая суета с Burak KALAYCI, который вроде как разобрался с тем как обходить эту защиту. Чем все закончилось за давностью лет уже не упомню, подробности можно в ruflash поискать. А рассказал я это потому что:
— тот метод был совсем уж не детским (не в обиду топикстартеру)
— все равно не устоял, емнип :(
В общем протектить флешки дело неблагодарное, что к клиенту попало, то рано или поздно будет пломано. единственный надежный способ — экономическая нецелесообразность взлома, да и та против упрямого фанатика не поможет. посему не держите в клиентской части ничего ценного, тогда и ломать не станут.

Более-менее нормальная защита возможно при написании некой своей вируальной машины которая будет интерпретировать код в своём языке приходящий с сервера. Естественно там нужно нормальное шифрование и криптографическая подпись запросов и много чего ещё. Уникальная защита = дорогой и уникальный взлом. Простая защита = простой взлом. Взломать можно всё что есть на клиенте.

Разработка декомпиляторов тоже не стоит на месте
Flash Decompiler Trillix показывает все внутренности приложенного файла
Результат (habrastorage)

Хм, после прочтения комментов становится понятно как функционирует игровая индустрия…