Каков подходящий алгоритм контрольной суммы для предотвращения модификации кода?

Question

Я объясню, что я намерен делать. У меня есть функция или набор строк кода (в C) для защиты - в основном никто не должен изменять инструкции. Итак, у меня есть код (называемый защитой контрольной суммы), который работает с кодом сборки x86, сгенерированным из файла C. Он выбирает одну инструкцию из этой сборки, добавляет (или применяет fletcher algo или любую другую функцию) к значению контрольной суммы (изначально 0), и это делается до завершения всех инструкций. Затем, чтобы увидеть, была ли какая-либо инструкция изменена, я беру добавление (или fletcher и т. Д.) Всех инструкций и проверяю его на значение предварительно вычисленной контрольной суммы. Какие методы подходят для этого?

Вот исследовательская работа, которая говорит об этой технике:

https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/2001-49.pdf

Вот шаблон охранника:

guard: 
     add ebp, -checksum 
     mov eax, client_addr 

for: 
     cmp eax, client_end 
     jg end 
     mov ebx, dword[eax] 
     add ebp, ebx 
     add eax, 4 
     jmp for 
end: 

Answer 1

Исследования бумага цитирует от создателей Arxan technologies. Таким образом, они защищают код patents, где защита защищает людей от обратного проектирования. За многие годы до Аршана у Интертраст было similar technologies. Я недостаточно изучил Арксан, чтобы понять, что такое романа о том, что они делают, и я не могу прокомментировать законности патентов.

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

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

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

• Простую контрольную сумму легко обойти хакером. Все, что он должен сделать, это изменить код таким образом, что инструкция, которая никогда не вызывается в конце его модификации кода, отменяет его изменения в предыдущей части кода.
• Цифровые подписи и MAC основаны на секретах, и теоретически хакер всегда может найти эти секреты в вашем коде. This research paper показал, как это сделать много лет назад (и это практично и работает!). Как только секреты найдены, чем цифровая подпись или MAC ведут себя по существу как криптографический хеш, поэтому настоящая причина избежать этих инструментов заключается в том, что они переполняют проблему, которую вы пытаетесь решить.
• Криптографические хэши решают ту же проблему, что и контрольные суммы, но не позволяют кому-либо атаковать ее так же, как если бы кто-то атаковал обычную контрольную сумму: то есть, если они изменяют код, тогда они также будут иметь для изменения контрольной суммы. Другими словами, нет простого способа отменить модификации кода, вставив инструкцию, которая ничего не делает в конце. (Если вы нашли способ, то вы бы вычислили столкновение в хэш-функции, что означает, что вы нарушили криптографическую хэш-функцию).

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

Answer 2

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

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

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

Обновление:

Для примеров, смотрите, например, на An idiot guide to writing polymorphic engines, ответ на this question и this forum thread. Найдите «обфускацию кода x86», и вы найдете много больше.