Крэкеры vs Авторы защит

Андрей Каролик

Спецвыпуск: Хакер, номер #057, стр. 057-104-3

Харон: Защищают-то почти независимо, но разница, как ни странно, есть. Наиболее сложны для взлома программы, написанные на ммм… "некомпилируемых" языках. Скажем, на васике или жабе. Проблема, естественно, не в том, чтобы найти, что ломать (тут особой разницы нет), а в том, что сделать патч к класс-файлу намного более трудоемкое занятие, чем к какому-нибудь PE'шнику. Но и тут есть соображение "в утешение крэкерам": серьезных продуктов на подобных языках не пишут :).

XS: Опиши стандартные шаги защиты/взлома программы.

мыщъх: Взлом - дело творческое, и общепринятой методики здесь нет. Одну и ту же защиту можно взломать десятком независимых способов, и невозможно предугадать, какой путь будет быстрее. Вот только одна из возможных схем. Смотришь, упакована ли программа. Если упакована, пытаешься найти готовый распаковщик. Если же его нет, снимаешь дамп утилитами типа ProcDUMP/LordPE или пишешь распаковщик самостоятельно. Распакованный файл загружаешь в дизассемблер и просишь его сгенерировать MAP-файл, содержащий всю символьную информацию, что существенно упрощает отладку. Дальше IDA Pro и SoftIce будут действовать в одной связке. Дизассемблер ищет перекрестные ссылки на "ругательные строки", отладчик - перехватывает обращения к API-функциям, подозрительным ячейкам памяти, портам ввода-вывода и т.д. Все вместе они помогают понять алгоритм работы защиты и взломать ее. Затем либо пишется генератор ключей/серийных номеров, либо правятся несколько байтиков в программе. Незапакованные программы правятся прямо в QVIEW, для запакованных пишется специальный онлайновый патчер, меняющий их на лету.

Харон: На этот вопрос я могу ответить одном советом (совет тем, кто защищает). Если есть стандартные шаги, то защитой лучше не заниматься: все равно она продержится до первого пожелавшего ее взломать :). Защита должна быть не просто интегрирована в продукт - она должна разрабатываться под конкретный продукт. И использовать для нее надо все "специфики" продукта. Скажем, если приложение общается с внешним миром, то самое милое дело - выкинуть кусочек (хоть несколько байтов) защиты тоже вовне. Ну, и хорошо бы до того, как начинать делать защиту, подумать, а что, собственно, ты собираешься защищать? В смысле, чего хочется избежать за счет этой самой защиты. Защита ведь - это далеко не всегда "защита от копирования".

XS: На каких ошибках ты обжигался и что можешь посоветовать на основе печального опыта?

мыщъх: Сообщать разработчикам об ошибках ;). Серьезно. Многие из них впадают в сумеречное состояние души, граничащее с полной прострацией, и поднимают вселенский вопль, благодаря которому мы узнаем много новых ругательных слов. Также ни в коем случае, ни при каких обстоятельствах никому не следует угрожать ни в явном, ни в предполагаемом виде. Добром это не кончится! Никогда нельзя доверять ничему написанному, пока все не проверишь сам! Ошибаются даже авторитеты (например, в моих книгах ошибок просто толпа).

Харон: При защите: устанавливать на продукт цену, которая провоцирует взлом :). При взломе: начинать ломать, не заглянув в интернет :).