Защита моего кода от обратного инжиниринга

Question

Как обсуждалось в подобных вопросах здесь и здесь Я хочу защитить свой код от обратного инжиниринга.

Моя ситуация, как Симукал описывает в своем (превосходном) ответе здесь :

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

У меня именно такая ситуация. Сложный инженерный алгоритм, элегантный и ценный для нашей конкретной области.

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

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

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

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

В идеале я хотел бы защитить все свое приложение, но есть две основные проблемы, которые затрудняют использование обычных обфускаторов и сторонних упаковщиков:

1. Приложение предлагает интерфейс плагина, и поэтому некоторые сборки (и интерфейсы / классы) не должны быть запутаны и упакованы

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

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

Answer 1

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

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

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

Почему бы вам просто не сконцентрироваться на том, чтобы сделать свой продукт максимально качественным? Цель состоит в том, чтобы оставаться впереди толпы, а не блокировать их вообще. Быть первым, кто предоставит вам лучший продукт в конкурентной группе, и обеспечит вам процветание гораздо больше, чем бесполезные усилия по бесполезной защите (IMNSHO).

Это только мое мнение. Я могу ошибаться Я был не прав прежде, вам нужно только спросить мою жену: -)

Answer 2

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

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

И, конечно, вы всегда можете подать патент на свое изобретение и защитить себя на законных основаниях.

Answer 3

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

Это часть рассуждений о том, почему они выпустили исходный код BCL вместо того, чтобы держать его в секрете.

Answer 4

Если ваш код настолько чувствителен, поместите его так, чтобы никто не смог его найти.

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

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

Для дополнительной меры запутайте этот код.

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

Answer 5

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

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

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

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

все это компромисс между трудностью для вас и сдерживанием для нескольких плохих яблок против потенциальной потери из-за воровства / плагиата

удачи, и дайте нам знать, что вы решите!

Answer 6

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

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

Смирись с этим, если кто-то хочет, он может иметь это.

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

Я мог бы исправить используемый мной декомпилятор, чтобы он переименовал все в пространство имен A_name вместо простого A, и тогда поток функций мог бы выскочить прямо в графы трассировки вызовов Eclipse.

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

Итак, вы можете скрыть это от случайно заинтересованных людей, конечно.

Answer 7

Большинство обфускаторов позволяют вам указать, какие методы / классы вы хотите сохранить от запутывания. Например, SmartAssembly позволяет помечать методы или классы атрибутами, в то время как другие позволяют выбирать методы в пользовательском интерфейсе для исключения из процесса. Вы должны иметь возможность достаточно хорошо контролировать процесс, и вы можете съесть свой пирог и съесть его.

Однако при использовании отражения вы столкнетесь с проблемами.

Answer 8

Я слышал хорошие комментарии о Spices.Net Obfuscator . Он должен быть в состоянии значительно увеличить время, необходимое для достижения алгоритма.