Насколько эффективно запутывание?

Question

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

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

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

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

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

---

1-е редактирование:

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

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

---

2-е редактирование:

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

---

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

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

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

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

Вот как кража источника снижается.

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

Answer 2

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

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

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

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

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

Answer 3

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

EDIT:

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

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

Answer 9

Короткий ответ - да и нет; это полностью зависит от того, что вы пытаетесь предотвратить. В двенадцатом разделе Кулинарная книга по безопасному программированию есть некоторые интересные комментарии по этому вопросу на странице 653 (что удобно недоступно в предварительном просмотре книг Google). Он классифицирует защиту от взлома на четыре категории: нулевой день (замедление злоумышленника, поэтому ему требуется много времени, чтобы выполнить то, что он хочет), защита запатентованного алгоритма для предотвращения обратного инжиниринга, «потому что я могу» атаковать и могу не помню 4-й. Вы должны спросить, что я пытаюсь предотвратить, и если вы действительно беспокоитесь о том, чтобы какой-то человек взглянул на ваш исходный код, тогда запутывание имеет определенную ценность. Сам по себе он обычно просто раздражает того, кто пытается связываться с вашим приложением, и, как любая хорошая мера безопасности, работает лучше всего, когда используется в сочетании с другими методами противодействия взлому.