Любые обратные инженеры имеют опыт работы с secureSWF?

Question

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

Я слышал о secureSWF (http://www.kindisoft.com/),), и они перечисляют некоторые «пользовательские комментарии». Однако они настолько оптимистичны, что им трудно доверять. Нет ни одного пессимистического комментария (даже о, например, пользовательский интерфейс или поддержка), так что что-то говорит мне, что они могут не публиковать их все. Из моего опыта, даже лучшие компании время от времени имеют своего рода критику.

Итак, любой реверс-инженер здесь, мог бы рассказать мне, насколько вы опытны в работе - и удалось ли вам реверс-инжинировать защищенный файл secureSWF? Если так, сколько времени это заняло у вас примерно? Вы бы порекомендовали это программное обеспечение?

Заранее большое спасибо.

Answer 1

Правило 1:

Любой, обладающий умом и решимостью, всегда получит ваш код / ​​ключи / источник / файлы / данные
Все, что вы делаете, просто увеличивает потенциальное время / усилия, необходимые для компрометации

С SecureSWF или без нее люди пойдут на неприятности?

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

1. Никто на самом деле не проверил его самостоятельно, и, следовательно, его безопасность не может быть оценена.
2. Люди проверили это, это очень эффективно, и люди не опубликовали результаты

Я думаю, что первое более вероятно. Если вы сказали, что делает приложение Flash, то эти пункты могут быть более конкретными.

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

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

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

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

Flash - это одна из тех вещей, например, JavaScript, где так много, что вы можете сделать , и действительно ли это имеет значение? Что хорошего в логике приложений без других ссылок в цепочке?

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

В любом случае, удачи!

Answer 2

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я работаю на Kindisoft.

secureSWF - лучший обфускатор ActionScript. Я считаю, что в этом нет абсолютно никаких сомнений: https://www.mochiads.com/community/forum/topic/which-obfuscator-should-i-use-as3

http://asgamer.com/2009/why-how-to-encrypt-your-flash-swf

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

Запутывание не является шифрованием. Это должен быть односторонний процесс. Когда вы переименовываете идентификаторы, оригинальные имена больше не существуют. Единственный способ вернуть их - угадать. То же самое относится к запутыванию потока управления. Изменение инструкции и изменение способа выполнения кода в байт-коде не соответствует тем же правилам ActionScript. Учтите следующее:

// swapping the values of a and b
var t = a;
a = b;
b = t;
// will be compiled to something similar to:
get a
set t;
get b;
set a;
get t;
set b;
// and will be obfuscated to something similar to:
get a
get b
set a
set b
// then it can become:
goto l1:
l2:
set a
set b
goto l3
l1:
get b
get a
swap
goto l2
l3:...
// after that it becomes:
goto l1:
l2:
set a
set b
goto l3
get b
dup
add
l1:
get b
get a
swap
goto l2
l3:...
// and finally (? denotes an unprinted char)
goto l1:
l2:
set ?
set ?
goto l3
get ?
dup
add
l1:
get ?
get ?
swap
goto l2
l3:...

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

Но возможно ли это? Конечно, это так. Если у вас есть что-то настолько важное, что злоумышленники пойдут на все эти неприятности, то это определенно не должно выполняться в потенциально враждебной среде (клиент). Хотя это помогает, запутывание не должно рассматриваться в основном как мера безопасности. Более подробную информацию можно найти здесь: http://en.wikipedia.org/wiki/Security_through_obscurity

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

Я надеюсь, что предоставил достаточно технического контента, чтобы поддержать мои взгляды. Теперь вернемся к бесстыдному маркетингу :). Скачайте демо-версию и протестируйте ее самостоятельно. Это не ограничено по времени и полностью функционально, за исключением водяного знака, который мы оставляем на обработанных файлах. Поскольку мы обращаемся за помощью к людям на форумах и stackoverflow.com, наша служба технической поддержки определенно превосходит ожидания;)

Более подробную информацию можно найти здесь: http://www.kindisoft.com/secureSWF/faq.php

Answer 3

У меня нет большого опыта работы с мракобесами, но несколько месяцев назад меня попросили попробовать пару из них для конкретного проекта (на самом деле это была довольно простая многопользовательская игра). Я попробовал SecureSWf и Amayeta SWFEncript (обе пробные версии, которые были полностью функциональны, если я правильно помню).

У обоих были некоторые проблемы с более "продвинутыми" функциями. Если бы я выбрал просто переименовать идентификаторы, все было бы гладко. Но даже с настройками по умолчанию (минимум обфускации потока управления) один из обфускаторов выдает недопустимый байт-код, то есть он будет отклонен верификатором игрока. Это создает исключение, и это все. Я действительно не могу вспомнить, какой из них, но это не удалось, как только вы запустите SWF.

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

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

Тем не менее, я думал, что добавлю другую перспективу, о которой не часто говорят.

Answer 4

Взгляните на компиляторы с открытым исходным кодом, такие как SWFMill и Haxe http://haxe.org/, они сгенерировали различный байт-код в своем окончательном SWF-файле и могут привести к сбою многих популярных декомпиляторов. Очевидно, что код может быть получен так же, как обычный SWF-файл, скомпилированный в Adobe, но многие декомпиляторы просто не будут работать с ним, поэтому, если вы хотите увеличить «необходимое количество усилий», я бы посоветовал вам взглянуть на это решение. и, возможно, создать что-то, смешивающее все это.