защита игр от взлома

КРИС КАСПЕРСКИ АКА МЫЩЪХ

Спецвыпуск: Хакер, номер #064, стр. 064-066-5

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

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

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

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

p-код

Термин p-код восходит к интерпретатору Visual Basic'а, но в хакерских кругах означает нечто большее и подразумевает любой интерпретируемый код произвольной виртуальной машины (не путать с VMWare). Непосредственное дизассемблирование в этом случае становится невозможно, и приходится прибегать к декомпиляции, для чего необходимо проанализировать алгоритм работы интерпретатора, написать (и отладить!) декомпилятор, что требует пива и времени. Правда, разработка (и отладка) интерпретатора тоже не обходится даром. Плюс разработка языка тянет за собой кучу вспомогательного инструментария (в первую очередь понадобится отладчик). Иначе как на нем программировать?..

Все это выливается в солидный проект, который может быть использован всего один раз, в одной-единственной программе, причем желательно слегка изменять ядро интерпретатора после выхода нескольких версий, чтобы написанный хакером декомпилятор перестал работать. Что поделаешь, защита требует жертв и больших вложений. Плюс производительность интерпретируемого кода плетется в самом хвосте, отставая от динамической расшифровки и обфускации, но... Может быть, есть возможность реализовать на p-коде только защитные модули? Нет! Тогда их отломают! Не глядя! На p-коде должна быть реализована вся программа целиком, в том числе защитный механизм, тогда без декомпилятора его будет не хакнуть. Но это все теория. На практике полностью загнать программу в p-код не удается из-за производительности и критичные к быстродействию функции пишутся на языке высокого уровня или даже ассемблере. Зато вызываются они уже из p-кода, в котором сосредоточена основная логика по типу «если нельзя, то все-таки».