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

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

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

Защита от эмуляторов

Структуру спиральной дорожки невозможно скопировать, но легко проэмулировать. Вместе с копировщиками защищенных дисков, как правило, поставляются программы-эмуляторы, создающие виртуальный CD-ROM/DVD привод. Копировщик проделывает ту же самую операцию, что и защита – снимает топологию с защищенного диска и передает ее эмулятору.

Можно ли этому противостоять? Разработчики StarForce использовали прямой доступ к IDE-контроллеру в обход всех установленных драйверов, в том числе и драйвера-эмулятора. А как быть, если у пользователя установлен не IDE-привод? Тогда StarForce вынуждена работать через уже установленные драйвера. Чтобы обойти защиту, достаточно выдернуть шлейф со своего привода или отключить соответствующий канал IDE-контроллера на лету, и StarForce падет. Не очень-то сильная защита, да к тому же трудно реализуемая (см. рис. 8).

Рисунок 8. Виртуальный диск Virtual Clone CD в «Моем компьютере»

Мы же пойдем другим путем. Если открыть стандарт по SCSI- или ATAPI-устройства (их черновые версии лежат на www.t10.org и www.t13.org соответственно), можно обнаружить десятки «мультимедийных» команд, поддерживаемых практически всеми современными приводами. В эмуляторах же реализована лишь малая часть. Поэтому, чтобы защититься от эмуляторов, достаточно задействовать хотя бы половину SCSI/ATAPI-команд (попутно это «убьет» мониторы шины и прочие анализаторы).