Защита моего кода от обратного проектирования

Question

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

Моей ситуация, как Simucal описывает в своем (отлично) ответе here:

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

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

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

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

Answer 5

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

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

Посмотрите на него, если кто-то захочет, они могут его получить.

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

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

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

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

Answer 6

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

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

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

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

Для получения кода потребуется несколько уровней безопасности.

Answer 7

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

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

Answer 8

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

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

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

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

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