Comments 30
а где XenoCode?
имею академический интерес, коллеги, по следующему вопросу:
зачем вообще защищать код программными средствами?
имеется в виду скомпилированный в том, или ином виде код, а не исходники
зачем вообще защищать код программными средствами?
имеется в виду скомпилированный в том, или ином виде код, а не исходники
Все очень просто: .NET сборки компилируются в промежуточный IL код который достаточно просто просмотреть с помощью либо встроенного ildasm, либо через reflector (тут можно даже посмотреть код уже не в виде IL, а в виде c#, vb, c++ и прочих кодов). А уж потом через .net runtime этот код переводится в реальном времени в машинный код. Вот поэтому и существует множество обфускаторов которые не позволяют смотреть этот IL код.
Спасибо, это как раз понятно; что такое промежуточная компиляция знаю очень хорошо — в свое время работал джава-программистом.
Но всё равно не понимаю: дизассемблерам лет сто в обед.
В любом случае, код выдернутый из скомпилированного (не важно в IL или в машкод) проекта и даже возвернутый на язык высокого уровня не удобен в работе, в том смысле, что это не исходник и трудоемкость его использования весьма высока. А от взлома защиты (регкода или еще чего-то в этом духе) оно не спасает.
Собственно в этом и вопрос: зачем создавать себе дополнительный геморой? Можно сформулировать его по-другому: приведите, если не сложно, пример где применение обфускатора было бы оправдано.
Я вполне понимаю, зачем использовать обфускаторы в интерпретируемых языках (джаваскрипт, классик асп, пхп), но какие плюсы в защите они дают при компиляции (пусть даже промежуточной), понять не могу: кульный хацкер взламать всё равно сможет, дикий юзер и пароль с екселя снять не сможет.
Но всё равно не понимаю: дизассемблерам лет сто в обед.
В любом случае, код выдернутый из скомпилированного (не важно в IL или в машкод) проекта и даже возвернутый на язык высокого уровня не удобен в работе, в том смысле, что это не исходник и трудоемкость его использования весьма высока. А от взлома защиты (регкода или еще чего-то в этом духе) оно не спасает.
Собственно в этом и вопрос: зачем создавать себе дополнительный геморой? Можно сформулировать его по-другому: приведите, если не сложно, пример где применение обфускатора было бы оправдано.
Я вполне понимаю, зачем использовать обфускаторы в интерпретируемых языках (джаваскрипт, классик асп, пхп), но какие плюсы в защите они дают при компиляции (пусть даже промежуточной), понять не могу: кульный хацкер взламать всё равно сможет, дикий юзер и пароль с екселя снять не сможет.
Мне видится ровно один use case: защита от кражи какого-нибудь «ноу-хау». Но тогда оное НХ проще спрятать в либу, собранную в native code.
Еще может быть стыдно за качество кода :).
А от кряка все равно никто не спасается, да и код проще писать заново, чем красть.
PS> Да, если кто-то считает, что я не прав/не все назвал, пожалуйста, сообщите об этом путем написания ответов к этому комментарию.
Спасибо.
Еще может быть стыдно за качество кода :).
А от кряка все равно никто не спасается, да и код проще писать заново, чем красть.
PS> Да, если кто-то считает, что я не прав/не все назвал, пожалуйста, сообщите об этом путем написания ответов к этому комментарию.
Спасибо.
По нынешним временам: НХ надо уносить на свой сервер и продавать как сервис, тогда вероятность взлома стремится к нулю. А если уж НХ надо отдавать в полное распоряжение пользователя, тогда только нейтив код, без вариантов.
Про свой сервер — полностью поддерживаю, но, сами понимаете, это не всегда возможно.
На самом деле ответ подобного уровня паранойе (ибо НХ лучше патентовать, это лучшая защита для подобного рода решений имхо) было предложено.
Израильтяне в 2007 году развели Microsoft по крупному и продали ей технологию secureIL за 80 лимонов, которую уже MS широко разрекламировала в тоне «ну уж теперь проблем с защитой IL не будет».
Вот здесь есть информация об этой технологии.
Суть технологии такова — IL инструкции заменяются на совершенно другой набор secureIL инструкций, то есть сборка становится недоступна для ILDASM. Чтобы запустить подобную сборку, необходимо иметь дополнительную надстройку над .NET которая производит обратный процесс secureIL-> MSIL и передает управление в .Net. Вроде все просто, сложность тут одна — надо иметь надстройку. Но шума было много и производителей обфускаторов пользователи терзали вопросами по поводу этой приблуды. История закончилась тем, что технология не пошла, даже на корпоративном уровне. Все достаточно просто — коли есть набор secureIL инструкций, ничто не помешает производителям декомпиляторов в конце концов этот набор возпроизвести в своих машинках и начать декомпиляцию защищенных подобным образом сборок.
Израильтяне в 2007 году развели Microsoft по крупному и продали ей технологию secureIL за 80 лимонов, которую уже MS широко разрекламировала в тоне «ну уж теперь проблем с защитой IL не будет».
Вот здесь есть информация об этой технологии.
Суть технологии такова — IL инструкции заменяются на совершенно другой набор secureIL инструкций, то есть сборка становится недоступна для ILDASM. Чтобы запустить подобную сборку, необходимо иметь дополнительную надстройку над .NET которая производит обратный процесс secureIL-> MSIL и передает управление в .Net. Вроде все просто, сложность тут одна — надо иметь надстройку. Но шума было много и производителей обфускаторов пользователи терзали вопросами по поводу этой приблуды. История закончилась тем, что технология не пошла, даже на корпоративном уровне. Все достаточно просто — коли есть набор secureIL инструкций, ничто не помешает производителям декомпиляторов в конце концов этот набор возпроизвести в своих машинках и начать декомпиляцию защищенных подобным образом сборок.
Ну почему же. Наиболее рапространенным способом ломания сборок является подделка сборок.
ILDASMом дизассемблировал, почистил защиту и ILASM-ом собрал. Если сборка подписана — подписал другим ключем. Это немного сложнее, если продукт идет с несколькими сборками — и все необходимо переподписывать, и менять хэш публичного ключа подписи (PublicKeyToken), но тут все просто — этот хэш нетрудно сгенерировать или скопировать.
Так что защита нужна больше от того, чтобы продукт завтра на варезнике не появился. А это как раз Tamper-Defense.
ILDASMом дизассемблировал, почистил защиту и ILASM-ом собрал. Если сборка подписана — подписал другим ключем. Это немного сложнее, если продукт идет с несколькими сборками — и все необходимо переподписывать, и менять хэш публичного ключа подписи (PublicKeyToken), но тут все просто — этот хэш нетрудно сгенерировать или скопировать.
Так что защита нужна больше от того, чтобы продукт завтра на варезнике не появился. А это как раз Tamper-Defense.
Попробуйте сами посмотреть какой код показывает рефлектор. Он очень даже удобен в работе. Как-то раз приходилось восстанавливать свой же код (исходник потерялся, сборка осталась). Все кроме комментариев и автоматически генерируемых свойств было на месте, причем последнее это скорее недоработка рефлектора. Восстановление в первозданном виде заняло минут 10.
Правда, сейчас еще всякие лямбды затрудняют декомпиляцию, но далеко не всегда они используются настолько плотно.
Паранойя конечно ни к чему, но иногда обфускатор очень даже не лишний.
Правда, сейчас еще всякие лямбды затрудняют декомпиляцию, но далеко не всегда они используются настолько плотно.
Паранойя конечно ни к чему, но иногда обфускатор очень даже не лишний.
Уже приводил этот пример, еще разок. Берем софтину с ценником в районе $4k, .Net, связана с телефонией. Рефлектором, мозгом и руками, за пару часов, софт превращается в собственный проект, который компилится с сырков, вычищен от привязки к железу и т.д. — реальный пример из жизни. И, более того, в 60% случаев на моей памяти — после дизасма Reflector'ом получается компилируемый проект.
UFO just landed and posted this here
про WinLicense тоже незаслуженно забыли
Еще есть The Enigma Protector. Хорошо заворачивает .NET
И в гибкости настроек силен.
И в гибкости настроек силен.
И .NET Reactor забыли. Хотя это один из самых доступных по цене вариантов и, похоже, не самый плохой.
Точнее, сейчас заметил что он упоминается в разделе «протекторы». Однако, насколько я понимаю, его можно использовать и как классический обфускатор.
Практически все производители протекторов предлагают обфускатор (или ведут разработку, то есть стремятся предложить) и рекомендуют его использовать в связке с протектором.
Это делается из-за главной уязвимости всех протекторов (пожалуй, кроме Саламандера, тут посложнее, но возможно) — легкости получения незащищенной протектором сборки после запуска. Ну и кроме этого — большинство протекторов не получится использовать на сборках-библиотеках.
Ну и что такое классический обфускатор? Это изменение имен классов, и возможно codeflow-obfuscation. Слабовато при нынешних средствах декомпиляции. CodeFlow опознается на раз, имена обфусцированных членов можно подвергнуть деобфускации(не сильно это помогает, но по минимуму имена станут читабельными). Это не защита, это некоторое усложнение.
Это делается из-за главной уязвимости всех протекторов (пожалуй, кроме Саламандера, тут посложнее, но возможно) — легкости получения незащищенной протектором сборки после запуска. Ну и кроме этого — большинство протекторов не получится использовать на сборках-библиотеках.
Ну и что такое классический обфускатор? Это изменение имен классов, и возможно codeflow-obfuscation. Слабовато при нынешних средствах декомпиляции. CodeFlow опознается на раз, имена обфусцированных членов можно подвергнуть деобфускации(не сильно это помогает, но по минимуму имена станут читабельными). Это не защита, это некоторое усложнение.
На мой взгляд, хороший обфускатор — Eazfuscator.NET. Плюсы: бесплатен, интегрируется в VS, есть String Encryption, Control Floq Obfuscation, AntiILDasm, шифрование stack trace, поддерживает настройку через атрибуты (например, можно задать пароль для шифрования или исключить определенный класс для работы с сериализацией).
если еще есть необходимость, готов помочь инвайтом
зы статья понравилась
зы статья понравилась
Для MVP не то что скидки, а скорее «все бесплатно».
Посмеялся по поводу Spices.Net и про их секреты :) Особенно в свете того, что исходники схемы лицензирования с комментариями лежали у них на ftp в практически открытом виде.
Мало кто занимается мобильными приложениями, но именно в этой области защита _кода_ очень нужна.
.Net Compact Framework. Каждое приожение на WM старается выделиться из общей массы, как по набору функций, так и по внешнему виду.
Если я сегодня прикрою свою сборку, то завтра повторить мой код один в один простые программеры уже не смогут. А если и смогут, то будут проходить всё тот же путь отлова ошибок. Следовательно пара месяцев у меня есть на продажу приложения. За это время можно и новый функционал написать.
Правильно сказали — обфускация и прочие защищалки не от снятия защиты и регистрации, а для защиты интеллектуальной собственности.
.Net Compact Framework. Каждое приожение на WM старается выделиться из общей массы, как по набору функций, так и по внешнему виду.
Если я сегодня прикрою свою сборку, то завтра повторить мой код один в один простые программеры уже не смогут. А если и смогут, то будут проходить всё тот же путь отлова ошибок. Следовательно пара месяцев у меня есть на продажу приложения. За это время можно и новый функционал написать.
Правильно сказали — обфускация и прочие защищалки не от снятия защиты и регистрации, а для защиты интеллектуальной собственности.
Знакомый и популярный demand, но обфускаторщики не сильно смотрят в сторону CF просто по трем причинам — маленький рынок и ущербность CF (ей и сегодня далеко до взрослой, начиная с диагностики) и на этом рынке нет победителя, будущее его непонятно (к тому же стоит посмотреть долю WinMobile на рынке мобильных устройств, да и вообще судьбу мобильных осей — тут нет такой стабильности как с Windows-Linux-MacOS в десктопных вещах).
Сейчас смотрят в сторону технологии Silverlight, которая может стандартизовать как-то приложения для всех мобильных и не мобильных устройств, а также механизмы «доставки» до устройства, разворачивания и общей среды вне зависимости от оси. Если слухи о покупке Adobe Microsoft-ом реальны, то вполне SL может заменить и флеш технологии и стать стандартом. Вот тогда уж все завертится…
Сейчас смотрят в сторону технологии Silverlight, которая может стандартизовать как-то приложения для всех мобильных и не мобильных устройств, а также механизмы «доставки» до устройства, разворачивания и общей среды вне зависимости от оси. Если слухи о покупке Adobe Microsoft-ом реальны, то вполне SL может заменить и флеш технологии и стать стандартом. Вот тогда уж все завертится…
Например, .Net Reactor прекрасно справляется и с .Net CF, и с Silverlight приложениями :)
Это как посмотреть.
1. 16 kb приложение превращается в 77 kb. А это для CF приложений это критично. Для SL — тем более.
2. Приложение становится неверифицируемым (собственно при применении всяких штучек и другие обфускаторы это делают)
3. Самое непонятное — у 64 битных сборок уже нет инициализирующего кода (jump-а передающего управление mscoree, это сделано из соображений безопасности, чтобы не было соблазна перехвата.) Будет ли корректно запускаться в 64-битной среде такое приложение? Сомневаюсь. Протекторы на этих джампах инциализации сидят все. То есть защита anyCPU приложения под вопросом.
4. Возможностей для диагностики — 0.
5. Такое приложение требует full trust на машине клиента. Не всякая среда даст такой уровень для приложения.
Это я к тому, что вокруг защиты есть много всяких дополнительных вещей и требований. И кроме защиты приложения, необходимо задумываться как его обслуживать, работать с exceptions и диагностировать. Может так получиться, что хорошо защищенное приложение станет кошмаром для пользователя (вот кстати случай про MS-вскую cliSecure). То есть нужен некий баланс.
1. 16 kb приложение превращается в 77 kb. А это для CF приложений это критично. Для SL — тем более.
2. Приложение становится неверифицируемым (собственно при применении всяких штучек и другие обфускаторы это делают)
3. Самое непонятное — у 64 битных сборок уже нет инициализирующего кода (jump-а передающего управление mscoree, это сделано из соображений безопасности, чтобы не было соблазна перехвата.) Будет ли корректно запускаться в 64-битной среде такое приложение? Сомневаюсь. Протекторы на этих джампах инциализации сидят все. То есть защита anyCPU приложения под вопросом.
4. Возможностей для диагностики — 0.
5. Такое приложение требует full trust на машине клиента. Не всякая среда даст такой уровень для приложения.
Это я к тому, что вокруг защиты есть много всяких дополнительных вещей и требований. И кроме защиты приложения, необходимо задумываться как его обслуживать, работать с exceptions и диагностировать. Может так получиться, что хорошо защищенное приложение станет кошмаром для пользователя (вот кстати случай про MS-вскую cliSecure). То есть нужен некий баланс.
Sign up to leave a comment.
Защита .NET приложений — всё же, во что заворачивать селёдку?