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

Я размышлял о том, как защитить свой код 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);  
     }
    
  • Бесцельные выделения и освобождение (много изменений в стеке)

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

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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

Безопасный Чистый Sentinel (ранее Aladdin). Предостережения - их API отстой, документация отстойная, и оба они великолепны по сравнению с их инструментами SDK.

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

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

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

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

Ответ 4

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

CLC
BCC over
.byte 0x09
over:

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

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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;

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

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

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

Ответ 9

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

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

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

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

Ответ 10

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

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

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

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

Ответ 11

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

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

Ответ 12

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

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

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

Ответ 13

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

Ответ 14

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

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

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

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

Если вы ответите на вопросы 2 "да" , то модель "платить за использование" может быть подходящим для вас.

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

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

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

Ответ 15

Защищенный код на виртуальной машине, по-видимому, невозможно было перестроить сначала. Themida Packer

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

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

Ответ 16

Возможно, лучшая альтернатива по-прежнему заключается в использовании виртуализации, которая вводит другой уровень косвенности/запутывания, необходимый для обхода, но, как сказал 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?. Это может немного помочь вам в дальнейших поисках.

Ответ 17

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

Но еще 3 примечания:

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

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

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

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

Ответ 18

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

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

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

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

Ответ 19

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

Ответ 20

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

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

printf("1677741794\n");

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

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

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

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

Ответ 21

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

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

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

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

Гротес Альберт

Ответ 22

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

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

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

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

Я не видел специальные методы Collberg, применяемые к производственному коду, особенно не исходный код C или С++.

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

Ответ 23

ПЕРВЫЙ ВЗЯТЬ, ЧТОБЫ ПОМНИТЬ О СООТВЕТСТВИИ С ВАШИМ КОДОМ. Не весь ваш код должен быть скрыт.

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

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

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

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

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

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

STEP ONE: Обфускация с использованием имен base64 для всего. После этого base64 зафуффицирует код и сохранит его во временном файле, который позже будет использоваться для дешифрования и запуска этого кода. Есть смысл?

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

STEP TWO​​strong > : вы будете читать в этом временном файле в виде строки и обфускации, затем base64 и сохраните его во втором временном файле, который будет использоваться для дешифрования и рендеринга для конечного пользователя.

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

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

LAND MINE TWO​​strong > : зависимости. Вы не хотите, чтобы ваш оппонент мог запускать слой один, без слоя 3 или 4 или 5, или даже с реальной программой, для которой он был разработан. Поэтому убедитесь, что внутри одного слоя вы включаете какой-то kill script, который активируется, если программа отсутствует, или другие слои.

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

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

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

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

УДАЧА!