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

0
Как раз читал минут 20 назад на хабре.
Я там в комментариях зацепился глазом за мысль использовать неявные методы защиты ( тормоза при неудачной проверке, размазанные по коду проверки)
Пришла следующая мысль: А что если использовать слабые места в коде как преимущество? Вот предположим есть дыра, и ты бился два дня чтобы устранить утечку в памяти ( значит место заранее сложное для анализа ). Так вот не устраняем ее намертво, а просто затыкаем пробки в такие места, чтобы в хакнутой версии они все потихоньку и вываливались.
0
Тут главное выявить сам факт хака.
Дальше вариантов будет масса — например включать кэширование для динамической анимации, создавать листенеры, которые не будут удаляться и есть память и процессор и тд.
0
Я ранее еще до флеша такой же подход всегда использовал. Всякие слабые проверки делал где-нибудь на видном месте для отвода глаз, а сложные спустя случайное время там где их уже и не догадаются искать и когда проверка лицензии не сходилась, то еще спустя какое-ниубдь время незаметно так крэшил например игру. В итоге получалось что-то вроде глючной демоверсии :)
+3
а не может этот метод вызвать такого эффекта, что поиграв первый раз во взломанную версию игры и увидев какая она тормозная и глючная, игрок не захочет играть в оригинальную версию где-нить на другом (белом) сайте?
0
Это вопрос грамотной дистрибуции. Нужно чтобы везде была рабочая версия.
Само собой это проблематично при продаже сайтлоков. Тут уже смотреть что выгоднее будет.
+1
Именно поэтому надо делать так, чтобы ломальщик сразу увидел эффект. Вот чтобы прямо с начала запуска все безбожно тормозило. Ведь ломальщик все равно проверяет хотя бы запускает.

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

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

Надо блин что-ли писать сто разных веток исполнения и пускать по ним от рандома. Причем веток не с проверками на урл-лок, а рабочих. Чтобы трейсы сильно отличались. Либо генерить их на лету в виде байткода с разными случайными вариациями как вирусы делают. Ох.
0
может просто писать игры? :)
+1
Естественно, о чем и сказано в начале статьи — здесь должен быть баланс между затратами времени на защиту, затратами хакера на ломку итд. Я лично купил secureSWF + небольшие усилия свои дополнительно. Но думать можно и в свободное время :) Можно так и придумать что-то малозатратное но гадкое :)
0
Только что обошёл url-lock в своей игре обфусцированной SWF Encrypt при помощи Yogda.
Мотратил минуты 3.
Надо с этим что то делать…
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.