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

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

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

ПРИЕМЫ ИЗ ПРАКТИКИ

НАПИСАТЬ ИГРУ — ПОЛДЕЛА, НУЖНО И ЗАЩИТИТЬ ЕЕ ТАК, ЧТОБЫ НЕ ВЗЛОМАЛИ (ИЛИ ВЗЛОМАЛИ, НО НЕ СРАЗУ). ЗАЩИТА ДОЛЖНА БЫТЬ МАКСИМАЛЬНО ПРОСТОЙ И БЕЗГЛЮЧНОЙ. НА ЭТУ ТЕМУ НАПИСАНО МНОЖЕСТВО СТАТЕЙ, НО ОЧЕНЬ МАЛО «РЕЦЕПТУРНЫХ» СПРАВОЧНИКОВ, ДОХОДЧИВО И БЕЗ ЛИШНЕГО, БЕЗ ВОДЫ ОБЪЯСНЯЮЩИХ, КУДА ИДТИ И ЧТО ДЕЛАТЬ

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

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

Арсенал защиты

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

Аппаратная защита — совсем другой разговор. При желании в микрочип можно перенести программу даже целиком, и тогда никто не сможет скопировать (если, конечно, выбрать правильный чип). Однако процесс разработки и отладки усложняется в десятки и даже сотни раз, «железное обеспечение» получается крайне негибким, неудобным в тиражировании и распространении, не говоря уже о невозможности исправить обнаруженные ошибки. Даже если чип имеет перепрошиваемое ПЗУ, разрешение на запись равносильно разрешению на чтение, так как самое ценное в железе — это прошивка. Скопировать железо намного проще, чем выдрать из защищенного чипа прошивку, если же она будет свободно распространяться как обновление... Можно, конечно, распространять не всю прошивку, а только измененные модули или даже их части. Что сделает хакер? Он просто создаст слегка модифицированный модуль, считывающий содержимое ПЗУ и выводящий его наружу контрабандным путем.

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

Тайники машинного кода