копаемся в броне

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

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

4. Не позволяй взломщику обнаруживать явные признаки того, что программа еще не взломана. Выводи ругательство о взломе не сразу, а спустя некоторое время, через несколько дней). Или хотя бы используй «отложенный» вызов «ругательных» процедур, посылая скрытому окну W сообщение типа «Нас взломали». Пусть окно W поставит его в очередь, обрабатываемую вместе с другими «нормальными» сообщениями, и тогда прямая трассировка не приведет ни к чему, а крэкер утонет в коде.

5. Обнаружив взлом, не пытайся «мстить» пользователю нестабильной работой. Далеко не каждый потенциальный клиент догадается, что причина сбоев кроется в плохом крэке, а не в самой программе. Столкнувшись с проблемами, он не побежит регистрироваться, а просто установит альтернативную программу.

6. Не используй недокументированные возможности. Это не затрудняет взлом (крэкеры знают все и обо всем), зато работоспособность защищенной программы от этого сильно страдает и Windows может просто отказать при установке очередного пакета обновлений или при запуске под специфичной версией. Также не защищай программу с помощью драйверов. Во-первых, без многолетнего опыта очень сложно написать стабильно работающий драйвер — такой, чтобы не завешивал систему и не создавал новые дыры в системе безопасности. К тому же драйверы, в силу их крошечного размера, очень просто отломать. Код, написанный на Visual Basic’е, ломается не в пример сложнее.

7. Не используй готовых защитных пакетов (протекторов, упаковщиков). Все готовые решения уже давно сломаны, а чтобы научиться правильно пользоваться ими, необходимо затратить достаточно много времени. К тому же к твоим собственным ошибкам добавятся баги протектора (протекторов без багов не существует) и разобраться в этом глюкодроме будет очень нелегко.

8. Никогда не доверяй API-функциям — очень легко перехватить их и подсунуть любой желательный результат. Тем более не используй прямых вызовов API-функций в программе, которая использует преимущественно библиотечные функции и RTL: защита сразу же демаскируется и позволит локализовать «логово дракона» во многомегабайтной чаще кода программы.

9. Не проверяй ничего на ранней стадии инициализации, иначе взломщик доберется до защиты элементарной пошаговой трассировкой. Чем позже выполняется проверка, тем лучше. Притом проверке не должен предшествовать вызов «очевидных» API-функций (таких как CreateFile для открытия ключевого файла) — между загрузкой ключевого файла и его проверкой должно пройти какое-то время (в смысле, они должны быть разделены как можно большим объемом нелинейного кода).

10. Не защищай программы — все равно взломают. Если и не взломают, то не купят из принципа! Основной доход приносит категория честных пользователей, для которых достаточно тривиальной «защиты» из пары строк. Как показывает практика, разработка более сложных защитных механизмов оказывается коммерчески неоправданной (исключение составляют специализированные программные комплексы типа IDA PRO, PC 3000, продажи которых измеряются лишь тысячами штук). Программы, ориентированные на массовый рынок, лучше распространять бесплатно, а доход при этом получают с рекламы, поддержки или других дополнительных сервисов (бери пример с Opera).