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

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

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

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

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

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

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

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

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

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

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

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

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

25.02.2009 05:38:36
Чем это отличается от многих вопросов, которые были заданы ранее? stackoverflow.com/questions/506282/… и stackoverflow.com/questions/106794/…
George Stocker 25.02.2009 05:41:01
Я спрашиваю, как защитить относительно небольшую часть моего кода, встроенного в сложное приложение (с архитектурой плагинов). Хотя этот вопрос похож на другие вопросы (и я на них ссылался), я задаю очень специфический сценарий. (небольшая часть кода)
Patrick Klug 25.02.2009 05:43:21
На самом деле это не обман, но я действительно удивляюсь, почему у людей возникают такие иллюзии, что у них есть какой-то невероятно ценный маленький алгоритм. Даже если алгоритм замечательный, он не делает программу, кроме того, алгоритмы должны быть бесплатными для всех, и вы должны держать своих клиентов на уровне качества и обслуживания.
Robert Gould 25.02.2009 06:01:00
Согласен. Даже если кто-то сможет увидеть алгоритм, ему нужно будет правильно понять другие вещи (например, пользовательский интерфейс, чтобы использовать его). Я не говорил, что это единственное, что ценно, и что оно представляет ценность (или даже интерес) для кого-то за пределами нашего домена.
Patrick Klug 25.02.2009 06:07:04
Кажется, отсутствует постоянный эксперт-реверс-инженер SO Cody Brocious (пользователь 4977). Я бы все-таки попробовал упаковку, это важная защитная мера, которая гораздо эффективнее, чем запутывание. Убедитесь, что ваши плагины по-прежнему работают с ним. Точно так же вы можете сделать, как говорит Стивен, и немного
mmcdole 25.02.2009 06:11:06
8 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

3
5.08.2009 14:36:15

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

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

3
25.02.2009 05:43:21

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

-2
25.02.2009 05:52:41
Может быть, днем, макс. Если это действительно корпоративный шпионаж, это не будет более помехой, чем запирание двери вашего экрана, пытаясь не допустить грабителя. Почти все приложения, которые я читал, были запутаны, и я ожидаю этого сейчас.
mmcdole 25.02.2009 06:05:00

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

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

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

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

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

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

2
25.02.2009 05:53:55
Ключ :) Я помню, как однажды видел взломанный ключ для ВЭЖХ (высокоэффективной жидкостной колонки). И я имею в виду, что машина стоит около 30 КБ и поставляется с ключом, поэтому ни у кого не было причин иметь Машину без ключа, но даже тогда кто-то ее взломал ...
Robert Gould 25.02.2009 07:24:11

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

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

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

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

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

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

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

1
25.02.2009 06:03:16

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

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

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

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

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

2
25.02.2009 06:32:46

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

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

0
22.06.2015 17:05:42

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

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

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

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

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

3
25.02.2009 07:02:15
Спасибо. Возможно, у меня сложилось неправильное впечатление, что для меня крайне важно защитить этот код. Это неправда, и я согласен с вами и Робертом в этом. Моя цель состоит в том, чтобы просто сделать это более трудным, чем просто открыть отражатель и переименовать несколько запутанных переменных, чтобы получить результат ...
Patrick Klug 25.02.2009 07:06:39