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

210

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

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

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

graphitemaster
источник
172
«Однако текущий протокол, над которым я работаю, никогда не должен быть проверен или понятен для безопасности различных людей». -- Удачи с этим.
Янтарь
62
Вы можете сделать ваше приложение трудным для обратного проектирования. Вы не можете сделать это невозможным, пока у другого парня не окажется в ваших руках значительная часть ваших битов. Тщательно следите за обеспечением полной безопасности, особенно если на карту поставлены жизни - вы не можете доставить.
Майкл Петротта
127
Если ваш компьютер может понять код, то может и человек.
Гонки легкости на орбите
78
Сделайте код открытым исходным кодом, и никто не будет его перепроектировать.
пользователь неизвестен
28
«Безопасность по неизвестности никогда не работала».
bot47

Ответы:

151

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

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

Стивен Кэнон
источник
14
Я понимаю это, и я прочитал несколько статей о безопасности Skype, которые я объяснил, и я размышлял над теми же идеями, которые Skype уже испробовал как способ не предотвращать, а защищать мой протокол. То, что оказалось достаточно достойным, учитывая очевидные обстоятельства для Skype.
графитмастер
8
Skype на самом деле является первым примером, который приходит на ум, поэтому я рад, что вы уже пытаетесь подражать их методам.
Рикет
176

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

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

янтарный
источник
113
+1. Читайте о славных днях защиты от копирования на Apple II, постоянно обостряющейся войне между обфускаторами и взломщиками, сумасшедших трюках с шаговым двигателем дискеты и недокументированными инструкциями 6502 и так далее ... спать, потому что вы не собираетесь реализовывать что-либо почти настолько сложное, и все они в конечном итоге взломали.
Немо
2
Проще использовать симулятор и получить лучшую видимость, чем пытаться перепроектировать визуально или с помощью дизассемблера. Если безопасность не встроена в используемое вами оборудование, я думаю, что в среднем от двух дней до двух недель уходит на то, чтобы перепроектировать и победить практически все, что выходит. Если на его создание и реализацию у вас уходит более двух дней, вы потратили слишком много времени.
old_timer
5
Единственное разумно работающее DRM сегодня - это комбинация ключа и интернет-сервера, проверяющего, что только один экземпляр ключа активен в один момент времени.
Торбьерн Равн Андерсен
2
@Rotsor: Компьютер не может этого понять, потому что мы не смогли свести этот тип интеллекта к алгоритму (пока), а не потому, что существует какой-то физический или технологический барьер. Человек может понять это, потому что он может сделать все, что может компьютер (хотя и медленнее), а также разум .
Адам Робинсон
3
В этот момент кто-то попытается перепроектировать компьютер, если он не доступен только в среде, которой вы управляете.
Янтарь
41

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, можно обойти.

RyanR
источник
19
Примечание модератора. Комментарии к этому ответу были удалены из-за того, что они перешли в антагонистический шум.
Тим Пост
2
+1 за опыт, но я бы хотел повторить, что он не идеален. Maya (3D suite) использовала аппаратный ключ (не уверен, что это был HASP), который долго не сдерживал пиратов. Когда есть желание, есть способ.
Роберт Фрейзер,
1
AutoCAD использует аналогичную систему, которая была взломана много раз. HASP и другие, подобные ему, будут сохранять честность честных людей и предотвращать случайное пиратство. Если вы создаете следующий продукт на несколько миллиардов долларов, у вас всегда будет с чем взломать. Все дело в уменьшении отдачи - сколько часов усилий стоит взломать защиту программного обеспечения, а не платить за это.
RyanR
6
Я также хочу вмешаться с точки зрения кого-то, кто использовал защищенное программное обеспечение HASP. HASP - это королевская боль в заднице для конечного пользователя . Я имел дело с Dallas iButton и Aladdin HASP, и оба были действительно глючными, и программное обеспечение случайно перестало работать, требуя отключения и повторного подключения HASP.
Фальшивое имя
4
Кроме того, стоит отметить, что меры безопасности HASP не обязательно являются более безопасными, чем запутывание кода - конечно, они требуют другой методологии для обратного инжиниринга, но их можно полностью отменить - См .: flylogic.net/blog/?p=14 flylogic.net/blog/?p=16 flylogic.net/blog/?p=11
Фальшивое имя
22

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

CLC
BCC over
.byte 0x09
over:

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

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

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

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

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

Старожил
источник
1
Кроме того, вам не нужно иметь доступ к исходному коду (или даже к разобранному исходному коду), чтобы найти дыру в безопасности. Это может быть случайно или с использованием того факта, что большинство дыр возникают из-за одних и тех же проблем в коде (например, переполнения буфера).
asmeurer
2
Есть большие проблемы с самоизменяющимся кодом. Большинство современных ОС / оборудования не позволят вам сделать это без очень высоких привилегий, могут быть проблемы с кешем, а код не является поточно-ориентированным.
Мартин Джеймс
1
С современными процессорами x86 подобные трюки часто ухудшают производительность. Использование одной и той же ячейки памяти в качестве части более чем одной инструкции, вероятно, будет иметь эффект, подобный неправильно предсказанной ветви. Самоизменяющийся код заставляет процессор отбрасывать строки кэша, чтобы поддерживать согласованность между кэшем инструкций и данных (если вы выполняете измененный код гораздо чаще, чем изменяете его, он все равно может быть выигрышным).
Джил
2
Я столкнулся с этим 20 лет назад. У нас ушло почти полчаса, чтобы понять, что случилось. Не очень хорошо, если вам нужна более длительная защита.
Бо Перссон
1
«настоящая инструкция уже будет в очереди, а измененная ячейка памяти не вызовет какого-либо повреждения», пока между ними не произойдет прерывание, очистка конвейера инструкций и появление нового кода. Теперь ваша путаница вызвала ошибку для ваших законных пользователей.
Бен Фойгт
21

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

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

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

Фил
источник
3
+1 для здравого смысла: зачем себе, если вы можете просто разработать лучшую систему.
Некролис
1
Как я всегда говорю, если вы сохраняете все на стороне сервера, это более безопасно
liamzebedee
20

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

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

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

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;

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

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

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

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

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

Жиль "ТАК - прекрати быть злым"
источник
1
@ Жиль, это твое утверждение, которое очень сильно, так что бремя доказывания лежит на тебе. Тем не менее, я приведу простой пример: 2+2может быть упрощен компилятором 4, но декомпилятор не может вернуть его обратно 2+2(что, если это действительно было 1+3?).
Роцор
7
@Rotsor 4и 2+2обсервационно эквивалентны, поэтому они одинаковы для этой цели, а именно, чтобы выяснить, что делает программа. Да, конечно, декомпилятор не может восстановить исходный код, но это не имеет значения. Это вопросы и ответы о восстановлении поведения (то есть алгоритма, а точнее протокола).
Жиль "ТАК - перестань быть злым"
1
Вам не нужно ничего делать, чтобы восстановить поведение. У вас уже есть программа! Обычно вам нужно понять протокол и что-то изменить в нем (например, заменить 2 в 2+23 или заменить на +a *).
Роцор
1
Если вы считаете все поведенчески эквивалентные программы одинаковыми, то да, компилятор ничего не может сделать, потому что он выполняет только преобразование идентичности. Декомпилятор также бесполезен, так как это снова преобразование идентичности. Если вы этого не сделаете, то 2+2-> 4является допустимым примером необратимого преобразования, выполняемого компилятором. Делает ли это понимание более легким или более сложным - отдельный аргумент.
Роцор
2
@ Жиль, я не могу расширить твою аналогию с яблоком, потому что я не могу представить себе структурно отличное, но поведенчески эквивалентное яблоко. :)
Rotsor
13

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

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

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

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

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

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

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

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

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

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

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

TNE
источник
7

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

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

Норман Рэмси
источник
7

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

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

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

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

Мохаммад Алагган
источник
6

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

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

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

Брайан Макин
источник
6

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

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

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

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

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

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

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

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

черный
источник
Очень хороший совет (и я проголосовал за него), но он не
решает
5

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

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

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

SSpoke
источник
5

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

Лукаш Мадон
источник
8
По общему мнению, единственный способ избежать разборки вашего кода людьми - это никогда вообще не предоставлять физический доступ к нему, что означает предложение вашего приложения исключительно в качестве SAAS, получение запросов от удаленных клиентов и возврат обработанных данных. Поместите сервер в запертую комнату в подземном бункере, окруженном канавой аллигатора и электрифицированной колючей проволокой высотой 5 м, в которую вы выбрасываете ключ, прежде чем покрыть его всем 10 м железобетона, а затем надеетесь, что вы не забыли установить тонны программных систем для предотвращения вторжения в сеть.
Вечер
6
Надеюсь, я никогда не получу контракт на обслуживание ваших серверов
Колин Пикард,
5

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

Нитрид галлия
источник
это реальное решение ... а именно, поместите свои драгоценности короны на свой собственный сервер на своей собственной VPS-машине и выставляйте вызовы API на этот сервер только с клиента (браузера или API-клиента)
Скотт Стенсланд,
5

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

przemoc
источник
4

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

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

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

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

Олоф Форшелл
источник
2
Ваш первый пункт не имеет смысла, оптимизированные порезы код из хлама, это делает его легче на обратный (я говорю из опыта). Ваша третья точка - это тоже пустая трата времени, и реверс-инженер стоит того, чтобы его умело знать, как делать точки останова доступа к памяти. вот почему, вероятно, лучше не проектировать систему самостоятельно, а нам, сторонним библиотекам, которые еще не «взломаны», потому что это может длиться чуть дольше, чем то, что может создать «новичок» ...
Necrolis
Поскольку, похоже, я ничего не знаю по этому вопросу, возможно, мне следует обратиться к профессионалу, такому как вы, для моих нужд в разработке программного обеспечения, а не писать какой-либо код самостоятельно.
Олоф Форшелл
4

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

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

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

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

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

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

flolo
источник
3

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

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

printf("1677741794\n");

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

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

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

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

Rotsor
источник
7
1. Ваш пример здесь не актуален; две программы, которые вы показываете, являются поведенчески эквивалентными, и этот вопрос касается выяснения поведения программы, а не восстановления ее исходного кода (что, очевидно, невозможно). 2. Этот документ является теоретическим документом; невозможно написать идеальный обфускатор, но также невозможно написать идеальный декомпилятор (по тем же причинам, по которым невозможно написать идеальный анализатор программ). На практике это гонка вооружений: кто может написать лучший (де) обфускатор.
Жиль "ТАК - перестать быть злым"
1
@ Жиль, результат (правильной) деобфускации всегда будет поведенчески эквивалентен запутанному коду. Я не понимаю, как это подрывает важность проблемы.
Роцор
Кроме того, о гонке вооружений: речь идет не о том, кто больше вкладывает в исследования, а о том, кто прав. Правильные математические доказательства не ошибаются только потому, что кто-то очень сильно их хочет.
Ротсор
1
Хорошо, возможно, вы правы насчет гонки вооружений на практике. Я думаю, что неправильно понял это. :) Я надеюсь, что возможно какое-то криптографически безопасное запутывание.
Роцор
Для интересного случая запутывания, попробуйте смарт-карты, где проблема в том, что у злоумышленника есть физический доступ (обфускация белого ящика). Часть ответа заключается в ограничении доступа физическими средствами (злоумышленник не может читать секретные ключи напрямую); но запутывание программного обеспечения также играет роль, главным образом, чтобы атаки типа DPA не давали полезных результатов. Извините, у меня нет хорошей ссылки. Примеры в моем ответе смутно вдохновлены методами, используемыми в этой области.
Жиль "ТАК - перестань быть злым"
3

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

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

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

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

Groetjes Альберт

Альберт ван дер Хорст
источник
3

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

Вы можете сделать это, полагаясь на программу остановки («останавливает ли программа 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/

Ира Бакстер
источник
2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

УДАЧИ!

Консультант по маркетингу
источник
4
Ты вообще читал вопрос? Я никогда не спрашивал о способах защиты от пиратства. Приложение будет бесплатным, это основной используемый протокол, который необходимо защитить из-за особенностей безопасности.
графитмастер
2

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

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

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