Копирование без границ или передовые методики защиты CD


             

Защита от анализа


Существует по меньшей мере два способа взлома: копирование диска специализированными копировщиками или анализ защитного кода с последующий модификацией (он же bit hack). Создать некопируемый диск это только полдела. Еще необходимо защитить свою программу от анализа.

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

В последнее время большое распространение получил некрасивый, но убойный подход, основанный на генерации "мусорного кода", внедряемого в защищаемую программу. Похожая техника используется во многих полиморфных вирусах, из которых можно "выдрать" уже готовые "движки" (engine). Мусорный код чрезвычайно затрудняет анализ, делая его практически невозможным. Допустим, ключевая функция программы компилируется в тысячу машинных команд. Исходя из "крейсерской" скорости дизассемблирования 1команда в секунду, хакер сможет "прочесть" (только прочесть! не проанализировать!) весь код за ~15 минут, но после разбавления функции миллионом мусорных инструкций, чтение листинга потребует свыше 10 суток напряженной работы, а полный анализ растянется на долгие годы.

Звучит прекрасно, но без подводных камней не обходится. Во-первых, если перестараться, то скорость программы упадет в разы, причем, нужно учитывать, что далеко не у всех стоит Pentium-4, поэтому "замусоривать" можно только редко вызываемые функции. Во-вторых, мусорный код должен быть достаточно нетривиальным, чтобы его "мусорность" не бросалась в глаза. Использование XCHG EBX,EBX или MOV EAX,EAX легко отсекается анализаторами. В-третьих, в некоторых случаях анализ защитного алгоритма необязателен и хакер может взломать программу и так (см. "защита от мониторов шины"), поэтому, линия обороны должна быть хорошо продуманной и однородной на всем своем протяжении. Бронебойные ворота бесполезны, если вокруг них стен.

Еще лучше применять P-код, реализовав "виртуальную машину" и написав свой собственный интерпретатор. Поскольку, программировать в P-коде очень непроизводительно и неудобно, рекомендуется реализовать транслятор, "пережевывающий" исходный текст, написанный на Паскале или Си и выдающий последовательность инструкций Машины Тьюринга, Сетей Петри, Стрелки Пирса и т. д. Чем ниже уровень абстракции, тем лучше для нас и хуже для хакера. Программа, состоящая из нескольких сотен строк, превращается в десятки тысяч или даже миллионы инструкций Тьюринга, декомпиляторов с которой не существует! Как компромиссный вариант можно использовать Форт, транслирующий исходный текст в шитый код. Это легко (и с комфортом) программируется, быстро работает, но долго ломается. Тем не менее, трудоемкость взлома порядка на два ниже, чем у Машины Тьюринга или Стрелки Пирса.




Содержание  Назад  Вперед