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

https://stackoverflow.com/questions/551892

23-08-2019
|

Вопрос

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

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

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

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

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

1 - я правка:

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

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

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

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

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

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

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

Решение

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

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

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

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

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

Некоторыми распространенными мерами по предотвращению реверсирования являются:

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

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

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

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

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

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

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

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

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

Другие советы

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

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

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

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

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

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

Редактировать:

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow