Насколько эффективна обфускация?

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

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

Я посмотрел на вывод из издания сообщества Программа Dotfuscator: и это выглядит запутанным для меня! Я бы не хотел этого поддерживать!

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

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


1-я правка:

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

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


2-е изд:

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

вычисляя, что 20 KLOC-это работа нескольких месяцев чтобы развиваться, потребуется больше или меньше этого (несколько месяцев), чтобы deobfuscate все это?

нужно ли вообще что-то деобфускировать, чтобы "украсть" его: или разумный конкурент может просто включить его оптом в свой продукт, все еще запутанный, принять это как-это кошмар обслуживания и надеяться, что он нуждается в небольшом обслуживании? Если этот сценарий is возможность затем запутывается .Net-код более уязвим для этого, чем скомпилированная машина код?

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

9 ответов


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

однако, ваш вопрос конкретно о кражи источник, что является интересной темой. В книге Эльдада Эйлиамса:"реверсирование: секреты реверсивной инженерии", автор рассматривает кражу источника как одну из причин обратного проектирования в первых двух главы.

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

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

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

некоторые общие анти-обращая меры являются:

  • запутывание - не делает много с точки зрения защиты вашего источника или предотвращения его взлома. Но мы могли бы не делать это так просто, верно?
  • 3-й партии упаковщиков - целесообразно - один из лучших. Упаковывает исполняемый файл в зашифрованное приложение win32. Предотвращает отражение, если приложение также является приложением .NET.
  • пользовательские упаковщики - иногда пишу свой собственный упаковщик, если у вас есть навыки, чтобы сделать так эффективно, потому что в сцене взлома очень мало информации о том, как распаковать приложение. Это может остановить неопытный огонь. Это учебник дает хорошую информацию о написании собственного упаковщика.
  • держите алгоритмы секрета индустрии с машины потребителей. Выполните их как службу удаления, чтобы инструкции никогда не выполнялись локально. Единственный "надежный" способ защиты.

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

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


вы упомянули, что он взял вас несколько месяцев, чтобы написать ~20kLOC для вашего приложения. Это займет почти на порядок больше времени, чтобы обратить эти эквивалентные 20kLOC из вашего приложения в работоспособный Источник, Если вы приняли минимальные меры предосторожности.

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

Возьмите следующий вымышленный пример: скажем, я только что разработал совершенно новый конкурирующий приложение для iTunes, которое имело массу наворотов. Скажем, потребовалось несколько 100K LOC и 2 лет для разработки. Одна ключевая особенность у меня есть новый способ подачи музыки вам на основе вашего музыкального вкуса.

Apple (будучи пиратами они) получает ветер этого и решает, что им действительно нравится ваша музыка предложить функцию, поэтому они решили отменить его. Затем они будут оттачивать только этот алгоритм, и обратные инженеры в конечном итоге придумают работоспособный алгоритм, который обслуживает эквивалентные предложения с учетом тех же данных. Затем они реализуют этот алгоритм в своем собственном приложении, называют его "гением" и делают свои следующие 10 триллионов долларов.

вот как кражи источник идет вниз.

никто не будет сидеть там и отменить все 100K LOC, чтобы украсть значительные куски вашего скомпилированного приложения. Это будет слишком дорого и отнимет слишком много времени. Около 90% времени они будут обращать скучно, non-industry-secretive код который просто отрегулировал давления кнопки или отрегулировал входной сигнал потребителя. Вместо этого они могли бы нанять собственных разработчиков, чтобы переписать большую часть из них с нуля за меньшие деньги и просто отменить важные алгоритмы, которые трудно разработать и которые дают вам преимущество (т. е. музыка предлагает функцию).


обфускация-это форма безопасность через незаметность, и хотя он обеспечивает некоторую защиту, безопасность, очевидно, довольно ограничена.

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

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

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

Я не верю, что комментарий действительно ссылался на" кражу кода " в том смысле, что ваш код будет украден и использован в другом проекте. Поскольку они использовали слово "взломщик", я считаю, что они говорили о" краже " с точки зрения программного пиратства. Крекеры специализируются на работе вокруг механизмов защиты; они не заинтересованы в использовании вашего исходного кода для каких-либо других целей.


большинство людей склонны писать то, что кажется запутанным кодом, и это не остановило крекеры, так в чем разница?

EDIT:

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

http://en.wikipedia.org/wiki/Polymorphic_code

В конце концов, нет ничего невозможного для декомпиляции.


вы беспокоитесь о людях, крадущих конкретные алгоритмы, используемые в вашем продукте. Либо вы Ярмарка Исаак или вам нужно дифференцировать себя, используя больше, чем то, как вы x++;. Если вы решили какую-то проблему в коде, которую не может решить кто-то другой, озадаченный этим в течение нескольких часов, вы должны иметь докторскую степень в области компьютерных наук и/или патентов для защиты вашего изобретения. 99% программных продуктов не успешных или специальные из-за алгоритм. Они успешны, потому что их авторы сделали тяжелый подъем, чтобы собрать хорошо известные и легко понятые концепции в продукт, который делает то, что нужно их клиентам, и продать его дешевле, чем стоило бы заплатить другим, чтобы сделать то же самое.


посмотрите на это так; редактор WMD, в который вы ввели свой вопрос, был реверсивно спроектирован командой SO, чтобы исправить некоторые ошибки и сделать улучшения som. Этот код был запутан. Вы никогда не остановите интеллектуальных мотивированных людей от взлома вашего кода, лучшее, на что вы можете надеяться, - это держать честных людей честными и сделать его несколько трудным для взлома.


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


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

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


Если вы когда-либо видели выход из дизассемблера, вы поймете, почему обфускация всегда будет терпеть неудачу.


короткий ответ-да и нет; она полностью зависит от того, что вы пытаетесь предотвратить. Двенадцатый раздел Безопасное Программирование Поваренная Книга имеет некоторые интересные комментарии по этому поводу на странице 653 (который удобно недоступен в Google books preview). Он классифицирует анти-вмешательство в четыре категории: нулевой день (замедление атакующего, поэтому им требуется много времени, чтобы выполнить то, что они хотят), защита собственного алгоритма для предотвращения обратного проектирования, "потому что я могу" атаки, и я не могу вспомнить четвертую. Вы должны спросить, что я пытаюсь предотвратить, и если вы действительно обеспокоены тем, что человек смотрит на ваш исходный код, то запутывание имеет некоторую ценность. Используется самостоятельно, это обычно просто раздражение для кого-то, кто пытается возиться с вашим приложением, и, как и любая хорошая мера безопасности, она лучше всего работает при использовании в сочетании с другими методами защиты от подделки.