Важно ли запутывать код приложения C ++?

В мире Java это иногда кажется проблемой, но как насчет C ++? Есть ли разные решения?

Я думал о том, что кто-то может заменить библиотеку C ++ конкретной ОС другой версией той же библиотеки, но полной символов отладки, чтобы понять, что делает мой код. Хорошо ли использовать стандартные или популярные библиотеки?

Это также может произойти с некоторой библиотекой DLL под Windows, замененной «отладочной версией» этой библиотеки. Лучше предпочесть статическую компиляцию? В коммерческих приложениях я вижу, что для ядра своего приложения они компилируют все статически, и по большей части dll (динамические библиотеки в целом) используются для предложения некоторых сторонних технологий, таких как антипиратские решения (я вижу это во многих играх). ), Библиотека GUI (например, Qt), библиотеки ОС и т. Д.

Является ли статическая компиляция эквивалентом запутывания в мире Java? В лучшем случае, это лучшее и наиболее доступное решение для защиты вашего кода?

Не тратьте свое время на проигрышные битвы

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

Дальнейшее чтение

Избранные материалы по теме (не все специфичны для C ++, но применяются общие принципы):

StackExchange Ответы

• Дело об обфускации кода?
• Каковы преимущества запутывания кода выпуска?
• Декомпиляторы - мифы или факты?
• Может ли код JS быть зашифрован, что затрудняет копирование?
• Запутывать код C / C ++? ^{(для инструментов для обфускации C ++, если вы действительно должны ...)}

документы

• Код (Де) Запутывание (Маду, Анкарт, Де Босшер)
• Об эффективности преобразований исходного кода для двоичного запутывания (Madou и др.)
• Эффективность обфускации исходного кода: экспериментальная оценка (Ceccato & al., 2009) [ PDF ]
• Качество методов запутывания и запутывания (Witkowska, 2006)

Знаменитые цитаты по запутыванию:

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

Никогда?

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

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

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

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

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

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

Незначительная запутанность

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

Минимизация Javascript является примером этого, хотя он не продается как таковой. Никто в здравом уме не захочет читать и редактировать минимизированный JS-файл, даже если это технически возможно сделать, если вы настроены / достаточно настойчивы.

Аналогично с доставкой приложений Java. Простая упаковка кода в исполняемый JAR-файл остановит большую часть глупости, даже несмотря на то, что в городском парке он имеет всю силу вежливого знака «Пожалуйста, держите подальше от травы».

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

Сильное запутывание

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

Намного лучше думать с точки зрения других решений. Например, вы можете хранить «драгоценности короны» кода на серверах, которые вы контролируете, и разрешать только сервисные вызовы к нему, делая клиента по существу бесплатной раздачей, которая является входной частью для ценных битов. Или вы можете пойти по более контрактному / легальному пути и передавать только исполняемые файлы организациям, которые формально соглашаются не копаться в вашем коде или не выплачивать вам компенсацию, если они это делают (так что это будет своего рода NDA). Цель состоит в том, чтобы создать сильный стимул для хакера, чтобы не взломать, и чтобы пользователи держали код подальше от любых хакеров, не связанных соглашением.

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