Комментарии 33
Могу до кучи добавить презентацию Валентина Симонова (habrauser Valyard ) — www.slideshare.net/flashgamm/valentin-simonov-who-cracks-our-games-and-how-that-is-done
Он довольно большой опыт обобщил на эту тему; а презентация эта с доклада на московском Флэшгаме.
Он довольно большой опыт обобщил на эту тему; а презентация эта с доклада на московском Флэшгаме.
В декомпиляторы можно добавить еще Eltima Flash Decompiler
Спасибо, правда я не стал добавлять этот продукт не случайно. Есть мнение, что авторами Eltima Flash Decompiler и Amayeta SWF Encrypt являются одни и те же люди. Eltima сойдёт для быстрой правки различных элементов в незащищённых SWF, однако тут может лучше подойти Sothink SWF Quicker, о котором я, к сожалению, забыл упомняуть в статье, в связке с ASV.
Вау, не знал, что там такой скандал. Я далек от темы Flash, просто хотел поддержать ребят из родного города.
Давно на Хабре таких классных статей по данной тематике не было. Спасибо вам!
Более совершенный анало CryptInt можно глянуть у MochiMedia: MochiDigits
www.mochimedia.com/support/dev_docs#MochiDigits
спасибо за статью =)
www.mochimedia.com/support/dev_docs#MochiDigits
спасибо за статью =)
Программы в нативном коде прошли все эти этапы эволюционной борьбы «защита-взлом» с десяток лет назад. Результаты неутишительные — защита/обфускация кода выполняемого на стороне клиента практически бессмысленна. Очередной виток. Ну-ну.
Создаём инструменты для обфускации? PROFIT! Ломаем то, что наделали обфускаторы? PROFIT! И т.д. и т.п. А идея проста — защита кода на стороне клиента ненужна.
Создаём инструменты для обфускации? PROFIT! Ломаем то, что наделали обфускаторы? PROFIT! И т.д. и т.п. А идея проста — защита кода на стороне клиента ненужна.
Тем не менее, не всегда есть возможность подключения сервера к проекту + не всегда требуется защищать ото всех, иногда достаточно оградиться от тех, кто дальше простых декомпиляторов не пойдёт.
Ну и врядли у кого-то возникнет желание воровать обфусцированный код каких-нибудь самописных и очень занятных движков для использования и дальнейшего дописывания «под себя» в своих проектах.
Ну и врядли у кого-то возникнет желание воровать обфусцированный код каких-нибудь самописных и очень занятных движков для использования и дальнейшего дописывания «под себя» в своих проектах.
github.com/CyberShadow/RABCDAsm
тоже ниче, нагибал им приложение для вконтактика
тоже ниче, нагибал им приложение для вконтактика
Очень хороший и подробный обзор, огромное спасибо!
Мог бы, плюсанул бы )
В избранное и перечитать ещё раз по внимательней обязательно )
Мог бы, плюсанул бы )
В избранное и перечитать ещё раз по внимательней обязательно )
спасибо, занес в избранное
Вот самая надежная защита — привязка к железу. Это конечно ограничивает пользователя и тоже можно взломать, но как вариант.
Библиотека для Flex и Air
code.google.com/p/codegenas3/
Библиотека для Flex и Air
code.google.com/p/codegenas3/
НЛО прилетело и опубликовало эту надпись здесь
ждём статью «способы защиты от flash приложений»
Сегодня политика безопаности flash-приложений такова, что ими сложно как-то навредить.
Раз в год находится какая-нибудь уязвимость и где-то неделю все мы под угрозой.
Последний раз можно было обойти разрешение на использование камеры и микрофона.
Вот помнится во времена Flash 5 под Win '98 можно было винт форматнуть :)
Раз в год находится какая-нибудь уязвимость и где-то неделю все мы под угрозой.
Последний раз можно было обойти разрешение на использование камеры и микрофона.
Вот помнится во времена Flash 5 под Win '98 можно было винт форматнуть :)
Есть еще Flasm — обфускатор.
Бесплатный.
Flasm is a free command line assembler/disassembler of Flash ActionScript bytecode. It lets you make changes to any SWF. Flasm fully supports SWFs produced by Macromedia Flash 8 and earlier Flash versions.
Бесплатный.
Очень круто. Все известные мне способы в одной статье + несколько настоящих ниндзя-техник.
Только почти все можно обойти, если не пользоваться обфускаторами. Я пользуюсь SWF Encrypt, доволен.
Только почти все можно обойти, если не пользоваться обфускаторами. Я пользуюсь SWF Encrypt, доволен.
Я тоже им пользуюсь, но после этой статейки как то не очень он мне уже.
Очень интересно получается, только что обошёл url-lock в своей игре обфусцированной SWF Encrypt при помощи Yogda.
На всё про всё, меньше 5 минут.
Совсем плохо (((
На всё про всё, меньше 5 минут.
Совсем плохо (((
Спасибо за статью! Очень все обобщенно и понятно. Единственное хотел добавить несколько вещей:
1. Лучше писать свои утилиты по защите и не выкладывать их в общий доступ.
2. Делать комплексную защиту с множеством вложений. Потому как если защищать одним способом то его достаточно просто взломать.
3. Есть идея загрузчика с кучей тегов DefineBinaryData, картинок, текста, чисел. Загрузчик составляет результирующий swf из кучи картинок, тегов, строк, чисел(естественно написать надо утилиту которая генерирует такой код). Все шифровать ключами, которые тоже не хранить в открытом виде, тоже шифровать с большой вложенностью в нескольких вложенных swf. Проверять контрольные суммы тегов и swf. И самое главное — сделать так что если даже из памяти и выдерут результирующий swf то он не будет работать, т.к. надо обеспечить плотную работу с загрузчиком. Т.е. и сам загрузчик+оригинальный не будет работать на определенном домене, так и оригинальный swf не будет работать вообще.
1. Лучше писать свои утилиты по защите и не выкладывать их в общий доступ.
2. Делать комплексную защиту с множеством вложений. Потому как если защищать одним способом то его достаточно просто взломать.
3. Есть идея загрузчика с кучей тегов DefineBinaryData, картинок, текста, чисел. Загрузчик составляет результирующий swf из кучи картинок, тегов, строк, чисел(естественно написать надо утилиту которая генерирует такой код). Все шифровать ключами, которые тоже не хранить в открытом виде, тоже шифровать с большой вложенностью в нескольких вложенных swf. Проверять контрольные суммы тегов и swf. И самое главное — сделать так что если даже из памяти и выдерут результирующий swf то он не будет работать, т.к. надо обеспечить плотную работу с загрузчиком. Т.е. и сам загрузчик+оригинальный не будет работать на определенном домене, так и оригинальный swf не будет работать вообще.
То, что доктор прописал. Про генерацию байткода вообще не знал.
Отличнейший подбор, но ничего не поможет, игры, особенно клиент-серверные так и будут коммуниздить.
Кстати, отчего не упомянули их в обзоре? Самые большие баталии воров и авторов, как мне кажется, происходят именно на этом поле — там тоже раздолье: уже не передают информацию в открытую через 80 порт, все шифруют/солят, добавляют в ответ и запрос неверные/ничего не значащие параметры и т.п.
Кстати, отчего не упомянули их в обзоре? Самые большие баталии воров и авторов, как мне кажется, происходят именно на этом поле — там тоже раздолье: уже не передают информацию в открытую через 80 порт, все шифруют/солят, добавляют в ответ и запрос неверные/ничего не значащие параметры и т.п.
В этой статье я старался писать больше о самом клиенте, чем о клиент-серверном взаимодействии, да и в количестве текста был ограничен, т.к. хотел всё в один пост уместить, чтобы не разбросано было, но всё равно, спасибо, что заметили про шифрование трафика — это, безусловно, также относится к средствам защиты во flash.
as3abc собирать не позволяет. Только парсить. Шедевральный дизассемблер/ассемблер это rabcdasm, регулярно пользуюсь, быстрый, простой, показывает и cinit и scripts. Он гораздо мощнее чем yogda и тем более nemo404. Ну и как же не упомянули abcdump с ключом -D
А ещё к методам защиты от декомпиляции можно отнести написание в байткоде валидных с точки зрения AVM2, но невозможных с точки зрения actionScript3 конструкций, таких как например вызов constructsuper из метода. Нормально работает, декомпилируется как super() в коде метода и не компилируется никак. Ещё множество таких конструкций придумать можно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Способы «защиты» flash-приложений