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

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

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

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

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

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

1st edit:

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

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

2nd edit:

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

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

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

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

Ответ 1

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

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

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

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

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

Некоторые общие антиреверсивные меры:

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

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

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

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

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

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

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

Вот как происходит кража источника.

Никто не будет сидеть и переворачивать все 100 000 LOC, чтобы украсть значительную часть вашего скомпилированного приложения. Это будет просто слишком дорого и слишком много времени. Приблизительно в 90% случаев они будут переворачивать скучный, не секретный для отрасли код, который просто обрабатывает нажатия кнопок или пользовательский ввод. Вместо этого они могли бы нанять своих собственных разработчиков, чтобы переписать большую часть их с нуля за меньшие деньги и просто обратить вспять важные алгоритмы, которые сложно разработать и которые дают вам преимущество (т.е. Функция предложения музыки).

Ответ 2

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

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

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

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

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

Ответ 3

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

EDIT:

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

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

В конце концов, невозможно перестроить конструкцию.

Ответ 4

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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