Как обфускать строковые константы?

Ответ 1

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

Я стараюсь защитить его

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

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

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

Ответ 2

Есть способы делать то, что вы хотите, но это не дешево, и это непросто.

Стоит ли это?

При рассмотрении вопроса о том, следует ли защищать программное обеспечение, сначала нужно ответить на ряд вопросов:

• Насколько вероятно, что это произойдет?
• Какова ценность для кого-то еще вашего алгоритма и данных?
• Какова стоимость приобретения вами лицензии на использование вашего программного обеспечения?
• Какова их стоимость для репликации вашего алгоритма и данных?
• Какова стоимость для них обратной инженерии вашего алгоритма и данных?
• Какова стоимость защиты вашего алгоритма и данных?

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

Итак, это приводит к вашему вопросу

• Как вы защищаете свой алгоритм и данные?

Уныние

Obfuscation

Вариант, который вы предлагаете, запутывающий код, беспорядок с экономикой выше - он пытается значительно увеличить стоимость для них (5 выше) без увеличения стоимости для вас (6). Исследование, проведенное Центром зашифрованных функций, провело ряд интересных исследований по этому вопросу. Проблема заключается в том, что, как и при использовании шифрования DVD, он обречен на провал, если есть достаточный дифференциал между 3, 4 и 5, и в конце концов кто-то это сделает.

Обнаружение

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

Защита

SaaS - Программное обеспечение как услуга

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

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

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

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

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

Защитные ключи для защиты программного обеспечения

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

Новый код. Перенос ключей (например, SenseLock ^{& dagger;}), похоже, способен делать то, что вы хочу хотя. С помощью этих устройств вы берете код из своего приложения и переносите его на защищенный процессор. Как и в случае с SaaS, ваше приложение будет связывать данные, передать их на ключ (возможно, USB-устройство, подключенное к вашему компьютеру) и прочитать результаты.

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

^{& крестик; Это был первый пример, который я смог найти при поиске в google.}

Надежная платформа

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

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

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

Заключение

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

Ответ 3

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

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

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

[изменить]

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

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

Ответ 4

@Том Галлен дал правильный ответ.

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

Что касается алгоритма: не компилируйте свой алгоритм во время компиляции, а во время выполнения. Чтобы это сделать, вам нужно указать интерфейс, содержащий методы для алгоритма. Интерфейс используется для его запуска. Затем добавьте исходный код для алгоритма в виде зашифрованной строки (встроенный ресурс). Расшифруйте его во время выполнения и используйте CodeDom для его компиляции в .NET-класс.

Ключи: обычный способ хранения запасных частей вашего ключа в разных местах приложения. Сохраните каждую часть как byte[] вместо string, чтобы немного их найти.

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

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

Ответ 5

Недавно я прочитал очень простое решение для OP.

Просто объявляйте свои константы как строки readonly, а не const string. Так просто. По-видимому, константные переменные записываются в стеке в двоичном виде, но записываются как обычный текст, тогда как строки readonly добавляются в конструктор и записываются как байтовый массив вместо текста.

т.е. Если вы его ищете, вы его не найдете.

Это был вопрос, верно?

Ответ 6

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

Ответ 7

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