Способы защиты flash-приложений

ActionScript

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

http://habrahabr.ru/blogs/Flash_Platform/110686/

+7
abyss
11 января 2011, 01:48

Комментарии (9)

Как раз читал минут 20 назад на хабре.
Я там в комментариях зацепился глазом за мысль использовать неявные методы защиты ( тормоза при неудачной проверке, размазанные по коду проверки)
Пришла следующая мысль: А что если использовать слабые места в коде как преимущество? Вот предположим есть дыра, и ты бился два дня чтобы устранить утечку в памяти ( значит место заранее сложное для анализа ). Так вот не устраняем ее намертво, а просто затыкаем пробки в такие места, чтобы в хакнутой версии они все потихоньку и вываливались.

Psyanim
11 января 2011, 02:14
↓

Тут главное выявить сам факт хака.
Дальше вариантов будет масса — например включать кэширование для динамической анимации, создавать листенеры, которые не будут удаляться и есть память и процессор и тд.

abyss
11 января 2011, 02:22
↑
↓

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

AntKarlov
11 января 2011, 02:30
↑
↓

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

LegendMAN
11 января 2011, 12:43
↑
↓

Это вопрос грамотной дистрибуции. Нужно чтобы везде была рабочая версия.
Само собой это проблематично при продаже сайтлоков. Тут уже смотреть что выгоднее будет.

dlancer
11 января 2011, 13:51
↑
↓

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

А вообще — прочитал статью, почерпнул таки интересное, во-первых про Yogda тулзу, возможно будет полезна.

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

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

scmorr
11 января 2011, 14:00
↑
↓

может просто писать игры? :)

4mlr
11 января 2011, 14:17
↑
↓

Естественно, о чем и сказано в начале статьи — здесь должен быть баланс между затратами времени на защиту, затратами хакера на ломку итд. Я лично купил secureSWF + небольшие усилия свои дополнительно. Но думать можно и в свободное время :) Можно так и придумать что-то малозатратное но гадкое :)