Защита исполняемого файла от обратного инжиниринга?

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

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

Некоторые вещи, о которых я думал до сих пор:

• Внедрение кода (вызов фиктивных функций до и после реальных вызовов функций)
• Обфускация кода (искажение бинарного кода)

• Напишите мои собственные процедуры запуска (сложнее привязать отладчиков)

  void startup();  
  int _start()   
  {  
      startup( );  
      exit   (0)   
  }  
  void startup()  
  {  
      /* code here */  
  }

• Проверка во время выполнения для отладчиков (и принудительный выход при обнаружении)

• Функциональные батуты

   void trampoline(void (*fnptr)(), bool ping = false)  
   {  
     if(ping)  
       fnptr();  
     else  
       trampoline(fnptr, true);  
   }

• Бессмысленные распределения и освобождения (стек сильно меняется)

• Бессмысленные фиктивные звонки и батуты (тонны прыжков на выходе разборки)
• Тонны литья (для запутанной разборки)

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

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

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

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

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

Safe Net Sentinel (ранее Аладдин). Однако, предостережения - их API отстой, документация отстой, и то и другое великолепно по сравнению с их инструментами SDK.

Я использовал их аппаратный метод защиты ( Sentinel HASP HL ) в течение многих лет. Для этого требуется запатентованный USB-брелок, который действует как «лицензия» для программного обеспечения. Их SDK шифрует и запутывает ваш исполняемый файл и библиотеки и позволяет связывать различные функции в вашем приложении с функциями, записанными в ключе. Без ключа USB, предоставленного и активированного лицензиаром, программное обеспечение не может расшифровать и, следовательно, не будет работать. Ключ даже использует настраиваемый протокол связи USB (вне моей компетенции, я не специалист по драйверам устройств), чтобы затруднить создание виртуального ключа или вмешательство в связь между оболочкой времени выполнения и ключом. Их SDK не очень удобен для разработчиков, и довольно сложно интегрировать добавленную защиту с автоматическим процессом сборки (но возможно).

До того, как мы внедрили защиту HASP HL, было 7 известных пиратов, которые сняли «защиту» dotfuscator с продукта. Мы добавили защиту HASP в то же время, что и серьезное обновление программного обеспечения, которое выполняет тяжелые вычисления на видео в реальном времени. Как я могу судить по профилированию и бенчмаркингу, защита HASP HL ​​только замедлила интенсивные вычисления примерно на 3%. С тех пор, как это программное обеспечение было выпущено около 5 лет назад, не было найдено ни одного нового пиратского продукта. Программное обеспечение, которое оно защищает, пользуется большим спросом в своем сегменте рынка, и клиенту известно о нескольких конкурентах, активно пытающихся провести реинжиниринг (пока безуспешно). Мы знаем, что они пытались получить помощь от нескольких групп в России, которые рекламируют услугу по нарушению защиты программного обеспечения,

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

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

Лучшие приемы против дизассемблера, в частности, для наборов команд переменной длины слова, в ассемблере / машинном коде, а не в C. Например,

CLC
BCC over
.byte 0x09
over:

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

Я думаю, что это было в начале «Языка ассемблера» Майкла Абраша, где он показал простой анти-дизассемблер и анти-отладочный трюк. У 8088/6 была очередь на предварительную выборку, у вас была инструкция, которая изменила следующую инструкцию или на пару вперед. Если пошагово, то вы выполнили модифицированную инструкцию, если симулятор набора команд не полностью смоделировал аппаратное обеспечение, вы выполнили измененную инструкцию. На реальном оборудовании, работающем нормально, настоящая инструкция уже будет в очереди, и измененное расположение памяти не вызовет никакого повреждения, если вы не выполняете эту строку инструкций снова. Возможно, вы все еще можете использовать такой трюк сегодня, когда конвейерные процессоры извлекают следующую инструкцию. Или, если вы знаете, что оборудование имеет отдельный кеш команд и данных, вы можете изменить количество байтов вперед, если вы правильно выровняете этот код в строке кеша, модифицированный байт будет записан не в кеш инструкций, а в кеш данных, и Имитатор набора команд, который не имел надлежащих имитаторов кэша, не сможет работать должным образом. Я думаю, что программные решения не помогут вам продвинуться далеко вперед.

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

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

Также прочитайте книгу Кевина Митника «Искусство обмана». Такой человек может взять трубку и попросить вас или коллегу передать секреты системы, думая, что это менеджер, другой сотрудник или инженер по аппаратному обеспечению в другой части компании. И ваша безопасность взорвана. Безопасность - это не только управление технологиями, но и управление людьми.

Взять, к примеру, алгоритм AES . Это очень, очень публичный алгоритм, и он ОЧЕНЬ безопасен. Зачем? Две причины: он был рассмотрен многими умными людьми, и «секретная» часть - это не сам алгоритм - секретная часть - это ключ, который является одним из входных данных алгоритма. Это гораздо лучший подход для разработки вашего протокола с использованием сгенерированного «секрета», который находится за пределами вашего кода, а не для того, чтобы сделать сам код секретным. Код всегда можно интерпретировать независимо от того, что вы делаете, и (в идеале) сгенерированный секрет может быть поставлен под угрозу только в результате грубого перебора или воровства.

Я думаю, что интересный вопрос Почему вы хотите запутать свой код?» Вы хотите, чтобы злоумышленникам было трудно взломать ваши алгоритмы? Чтобы им было труднее находить уязвимые ошибки в вашем коде? Вам не нужно было бы запутывать код, если бы код изначально был не взломанным. Корень проблемы - взломанное программное обеспечение. Исправьте корень вашей проблемы, а не просто запутайте ее.

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

Создание трудного для обратного проектирования кода называется обфускацией кода.

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

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

a = useless_computation();
a = 42;

сделай это:

a = complicated_computation_that_uses_many_inputs_but_always_returns_42();

Или вместо этого:

if (running_under_a_debugger()) abort();
a = 42;

Сделайте это (где running_under_a_debuggerне должно быть легко идентифицируемой функции, которая проверяет, выполняется ли код под отладчиком - он должен смешивать полезные вычисления с обнаружением отладчика):

a = 42 - running_under_a_debugger();

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

some_function();

сделайте это, когда вы узнаете точное ожидаемое расположение битов в some_data_structure:

goto (md5sum(&some_data_structure, 42) & 0xffffffff) + MAGIC_CONSTANT;

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

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

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

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

Рекомендуемое чтение:

• Библия безопасности: Инженерия безопасности Росс Андерсон
• Библия обфускации: тайное программное обеспечение Кристиана Коллберга и Ясвира Награ

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

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

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

Прочитайте http://en.wikipedia.org/wiki/Security_by_obscurity#Arguments_against . Я уверен, что другие, вероятно, могли бы также дать лучшие источники того, почему безопасность по неизвестности - это плохо.

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

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

• Сахай, Гарг, Джентри, Халеви, Райкова, Уотерс, Кандидат, Незаметность, Обфускация и Функциональное шифрование для всех цепей (21 июля 2013 г.).
• Сахай, Воды, Как использовать запутывание в неразличимости: надежное шифрование и многое другое .
• Сахай, Барак, Гарг, Калай, Панет, Защита от запутывания от алгебраических атак (4 февраля 2014 г.).

Вы можете найти некоторую искаженную информацию в этой статье журнала Quanta и в этой статье IEEE Spectrum .

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

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

Чтобы узнать себя, прочитайте академическую литературу по обфускации кода . Кристиан Коллберг из Университета Аризоны является авторитетным ученым в этой области; Салил Вадхан из Гарвардского университета также проделал хорошую работу.

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

Недавно появилась статья под названием « Запутывание программ и одноразовые программы ». Если вы действительно серьезно относитесь к защите своего приложения. В целом статья посвящена теоретическим результатам невозможности с использованием простых и универсальных аппаратных средств.

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

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

Обновление: новое понятие запутывания, названное неразличимым запутыванием, может смягчить результат невозможности (статья)

Если кто-то хочет потратить время, чтобы перевернуть ваш двоичный файл, то вы абсолютно ничего не можете сделать, чтобы остановить его. Вы можете сделать, если умеренно сложнее, но это все. Если вы действительно хотите узнать об этом, получите копию http://www.hex-rays.com/idapro/ и разберите несколько двоичных файлов.

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

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

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

1. Вполне вероятно, что «новые пользователи» не хотят платить, а используют Ваше программное обеспечение?
2. Возможно ли, что существующие клиенты нуждаются в большем количестве лицензий, чем они имеют?
3. Сколько готовы платить потенциальные пользователи?
4. Хотите ли вы предоставлять лицензии для пользователя / одновременных пользователей / рабочей станции / компании?
5. Ваше программное обеспечение нуждается в обучении / настройке, чтобы быть полезным?

Если ответ на вопрос 5 «да», не беспокойтесь о нелегальных копиях. Они не будут полезны в любом случае.

Если ответ на вопрос 1 «да», то сначала подумайте о ценах (см. Вопрос 3).

Если вы отвечаете на вопросы 2 «да», то вам может подойти модель «оплата за использование».

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

• Новых пользователей привлекает модель ценообразования (мало пользы -> мало платят)
• Здесь практически нет «анонимных пользователей», потому что они нуждаются в обучении и настройке.
• Никакие программные ограничения не отпугивают потенциальных клиентов.
• Существует постоянный поток денег от существующих клиентов.
• Вы получаете ценные отзывы о разработке от своих клиентов, благодаря долгосрочным деловым отношениям.

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

Сначала защищенный код на виртуальной машине казалось невозможным для обратного инжиниринга. Themida Packer

Но это уже не так безопасно ... И независимо от того, как вы упаковываете свой код, вы всегда можете создать дамп памяти любого загруженного исполняемого файла и разобрать его с помощью любого дизассемблера, такого как IDA Pro.

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

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

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

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

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

Что бы человек ни собирал, его можно разобрать.

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

Если вы хотите что-то защитить от RE, вы должны знать, по крайней мере, общие методы, используемые RE.

Таким образом слова

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

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

(Существуют примеры того, как программное обеспечение использует защиту не по назначению, делая такую ​​защиту практически несуществующей. Чтобы избежать расплывчатости, я приведу вам пример, кратко описанный в Интернете: второе издание Oxford English Dictionary на CD-ROM v4. Вы можете прочитать о не удалось использовать SecuROM на следующей странице: Оксфордский словарь английского языка (OED) на компакт-диске в 16-, 32- или 64-разрядной среде Windows: установка на жесткий диск, ошибки, макросы обработки текста, работа в сети, шрифты и и так далее )

Все требует времени.

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

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

В деловом разговоре вы можете сказать, что это все о задержке конкуренции, насколько это возможно.

(Посмотрите красивую презентацию Серебряной иглы в Skype от Филиппа Бионди и Фабриса Дескло, показанную на Black Hat 2006).

Вы знаете, что есть много вещей о RE, так что начните читать. :)

Я говорил о виртуализации, поэтому я дам вам ссылку на один примерный поток от EXETOOLS FORUM : Лучший защитник программного обеспечения: Themida или Enigma Protector? , Это может немного помочь вам в дальнейших поисках.

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

Сказав, что есть вещи, которые вы должны сделать, такие как:

• Используйте максимально возможный уровень оптимизации (обратный инжиниринг - это не только получение последовательности сборки, но и понимание кода и его перенос на язык более высокого уровня, такой как C). Высокооптимизированный код может последовать за вами.
• Сделайте структуры плотными, не имея больших типов данных, чем необходимо. Перестройка членов структуры между официальными выпусками кода. Переупорядоченные битовые поля в структурах также можно использовать.
• Вы можете проверить наличие определенных значений, которые не следует изменять (например, сообщение об авторских правах). Если байтовый вектор содержит «vwxyz», вы можете иметь другой байтовый вектор, содержащий «abcde», и сравнить различия. Функция, делающая это, не должна передавать указатели на векторы, а использовать внешние указатели, определенные в других модулях как (псевдо-C-код) "char * p1 = & string1 [539];" и "char p2 = & string2 [-11731];". Таким образом, не будет никаких указателей, указывающих точно на две строки. В коде сравнения вы сравниваете для « (p1-539 + i) - * (p2 + 11731 + i) == некоторое значение». Взломщик подумает, что сменить string1 безопасно, потому что никто, кажется, не ссылается на него. Похороните тест в каком-то неожиданном месте.

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

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

Но 3 дополнительных примечания:

1. Возможно сделать реверс-инжиниринг невозможным, НО (и это очень очень много, но), вы не можете сделать это на обычном процессоре. Я также много занимался разработкой аппаратного обеспечения и часто использовал FPGA. Например, на Virtex 5 FX установлен процессор PowerPC, и вы можете использовать APU для реализации собственных кодов операций процессора на вашем оборудовании. Вы можете использовать эту возможность для реального дешифрования инсталляций для PowerPC, которые недоступны извне или другому программному обеспечению, или даже выполнить команду на оборудовании. Поскольку FPGA имеет встроенное шифрование AES для своего потока битов конфигурации, вы не можете выполнить его реинжиниринг (за исключением того, что кому-то удается сломать AES, но тогда, я думаю, у нас есть другие проблемы ...). Таким образом, производители оборудования IP также защищают свою работу.

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

3. Сделайте вашу программу неотлаживаемой / неуправляемой. Попробуйте использовать какое-либо обнаружение отладки и примените его, например, в некоторой формуле oder, добавляя содержимое регистра отладки к магической константе. Гораздо сложнее, если ваша программа выглядит в режиме отладки, если она работает в нормальном режиме, но делает совершенно неправильные вычисления, операции или что-то другое. Например, я знаю некоторые эко-игры, которые имели очень неприятную защиту от копирования (я знаю, что вы не хотите защищать от копирования, но это похоже): украденная версия изменила добытые ресурсы после 30 минут игры, и внезапно вы получили только одну ресурс. Пират просто взломал его (то есть реверс-инжиниринг) - проверил, работает ли он, и Воли выпустил его. Такие небольшие изменения поведения очень трудно обнаружить, особенно если они не появляются мгновенно для обнаружения, а только задерживаются.

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

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

Это один из примеров совершенно запутанного программного утверждения, демонстрирующего мою точку зрения:

printf("1677741794\n");

Никогда нельзя догадаться, что на самом деле это

printf("%d\n", 0xBAADF00D ^ 0xDEADBEEF);

Есть интересная статья на эту тему, которая доказывает некоторые результаты невозможности. Это называется «О (Im) возможности запутывания программ» .

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

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

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

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

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

Groetjes Альберт

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

Вы можете сделать это, полагаясь на программу остановки («останавливает ли программа X?»), Которая в общем случае не может быть решена. Добавление программ, которые трудно рассуждать в вашей программе, делает вашу программу трудной для рассуждения. Такие программы легче построить, чем разорвать их на части. Вы также можете добавить код в программу, которая имеет различные степени сложности для рассуждения; отличным кандидатом является программа рассуждений об псевдонимах («указатели»).

У Коллберга и соавторов есть статья («Производство дешевых, отказоустойчивых и скрытых непрозрачных конструкций»), в которой обсуждаются эти темы и определяются различные «непрозрачные» предикаты, из-за которых очень сложно рассуждать о коде:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.1946&rep=rep1&type=pdf

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

Обфускатор DashO Java, похоже, использует похожие идеи. http://www.cs.arizona.edu/~collberg/Teaching/620/2008/Assignments/tools/DashO/

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

КОНЕЦНАЯ ЦЕЛЬ . Моей конечной целью для большинства программ является возможность продажи различных лицензий, которые будут включать и выключать определенные функции в моих программах.

ЛУЧШАЯ ТЕХНИКА : Я считаю, что создание системы хуков и фильтров, таких как WordPress, является абсолютным лучшим методом, который пытается сбить с толку ваших оппонентов. Это позволяет вам шифровать определенные ассоциации триггеров без фактического шифрования кода.

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

ЗНАЙТЕ СВОИХ КРЕКЕРОВ : Знайте это: Основная причина взлома кода не в злонамеренном распространении лицензий, а на самом деле потому, что НУЖДАЕТСЯ в том, чтобы изменить ваш код, а им на самом деле НЕ НУЖНА распространять бесплатные копии.

НАЧАЛО РАБОТЫ : отложите небольшой объем кода, который вы собираетесь зашифровать, остальной код должен попытаться втиснуться в ОДИН файл для повышения сложности и понимания.

ПОДГОТОВКА К ШИФРОВАНИЮ : Вы собираетесь шифровать по слоям с моей системой, это также будет очень сложная процедура, поэтому создайте другую программу, которая будет отвечать за процесс шифрования.

ШАГ ПЕРВЫЙ : запутывайте, используя base64 имена для всего. После этого зашифруйте код base64 и сохраните его во временном файле, который впоследствии будет использоваться для расшифровки и запуска этого кода. Есть смысл?

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

ШАГ ВТОРОЙ : Вы будете читать этот временный файл как строку и затемнять его, затем base64 и сохранять во второй временный файл, который будет использоваться для дешифрования и рендеринга для конечного пользователя.

ШАГ ТРЕТИЙ : Повторите шаг два столько раз, сколько вы хотите. Как только у вас все получится, без ошибок дешифрования, вы захотите начать строить мины для своих противников.

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

ЗЕМЛЯ ДВОЙНАЯ ВТОРАЯ : Зависимости. Вы не хотите, чтобы ваш оппонент мог запускать первый уровень, без 3-го, 4-го или 5-го уровня или даже самой программы, для которой он был разработан. Поэтому убедитесь, что в первый слой включен какой-то сценарий уничтожения, который будет активирован, если программа отсутствует, или другие слои.

Я уверен, что вы можете придумать свои собственные мины, повеселиться с ними.

ВЕЩЬ, ЧТОБЫ ЗАПОМНИТЬ : Вы можете на самом деле зашифровать свой код вместо base64. Таким образом, простой base64 не сможет расшифровать программу.

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

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

УДАЧИ!

Кто-нибудь пробовал CodeMorth: http://www.sourceformat.com/code-obfuscator.htm ? Или Фемида: http://www.oreans.com/themida_features.php ?

Позже один выглядит более перспективным.