Мелкие промахи, ведущие к серьезным последствиям
1)
категорически недопустимо бороться с пассивными отладчиками! многие системщики постоянно держат soft-ice в фоне и совсем не для хакерских целей! защиты они уже давно не ломают — нет времени, да и программирование приносит гораздо большие деньги, но когда необходимая им программа ругается на soft-ice, отказываясь запускаться, вот тогда-то они выседают на ярость и, тряхнув стариной, разносят защиту в пух и прах, очень часто при этом выкладывая crack на всеобщее обозрение;
2) не нужно пытаться обнаружить виртуальные машины — все равно не получится! их слишком много: VM Ware, VirtualPC, BOCHS, QEMU… к тому же многие пользователи и сетевые/журнальные обозреватели не желая "засирать" свою основную систему, "обкатывают" новые программы именно под виртуальными машинами и если те отказываются там запускаться, выбор делается в пользу конкурентной программы;
Рисунок 7 BOCHS – одна из многих виртуальных машин
3) привязываться ни к чему нельзя! пользователям очень не нравится когда программы привязываются к оборудованию, запрещая ее менять (а как же апгрейд?), тем более, что подобная привязка очень легко "отламывается", а если не отламывается то запускается под виртуальной машиной. к носителям информации и электронным ключам привязываться тоже нельзя — честным пользователем один геморрой (и реверанс в сторону конкурентов), нечестные все равно скопируют;
4) не давайте хакеру явно понять, что программа еще не взломана! выводите ругательство о взломе не сразу, а спустя некоторое время, например, через несколько дней :) или хотя бы используйте "отложенный" вызов "ругательных" процедур, посылая скрытому окну W сообщение типа "нас взломали". пусть окно W поставит его в очередь, обрабатываемую вместе с другими "нормальными" сообщениями, тогда прямая трассировка ни к чему не приведет и хакер утонет в коде;
5) обнаружив взлом, не пытайтесь "мстить" пользователю нестабильной работой!
далеко не каждый потенциальный клиент догадается, что причина сбоев кроется в плохом краке, а не самой программе! столкнувшись с проблемами, он не побежит регистрироваться, а просто установит конкурентную программу и по своему будет очень логичен и прав;
6) не используйте никаких недокументированных возможностей! это ничуть не затрудняет взлом (хакеры знают все и обо всем), а вот работоспособность защищенной программы от этого сильно страдает и при установке очередного пакета обновления или при запуске под специфичной версией Windows она может отказать. так же не защищайте программу с использованием драйверов! во-первых, без многолетнего опыта очень сложно написать стабильно работающий драйвер, не завешивающий систему и не создающий новые дыры в системе безопасности, к тому же драйвера в силу их крошечного размера очень просто отломать. код, написанный на Visual Basic'е ломается не в пример сложнее;
Рисунок 8 голубой экран смерти, вызванный ошибкой в драйвере защиты
7) не используйте готовых защитных пакетов (протекторов, упаковщиков): все готовые решения уже давно сломаны и чтобы научиться _правильно_ ими пользоваться необходимо затратить достаточно много времени, к тому же, к вашим собственным ошибкам добавляются баги протектора (а протекторов без багов не существует) и разобраться в этом глюкодроме будет очень нелегко;
Рисунок 9 протектор, конфликтующий с VM Ware, подрывает доверие пользователей к программе
8) никогда не доверяйте API-функциям — их очень легко перехватить и подсунуть любой желаемый результат, тем более, не используйте прямых вызовов API-функций в программе, преимущественно использующей библиотечные функции и RTL, поскольку это сразу же демаскирует защиту, позволяя локализовать "логово дракона" во многомегабайтой чаще кода программы;
9) ничего не проверяйте на ранней стадии инициализации, иначе хакер доберется до защиты элементарной пошаговой трассировкой! чем позже выполняется проверка — тем лучше, причем проверке не должен предшествовать вызов никаких "очевидных" API-функций (таких, например, как CreateFile для открытия ключевого файла) — между загрузкой ключевого файла и его проверкой должно пройти какое-то время (в смысле они должны быть разделены как можно большим объемом нелинейного кода);
10) не защищайте программы! все равно взломают! а если не взломают, то не купят из принципа! основной доход приносит категория честных пользователей, для которых достаточно тривиальной "защиты" из пары строк; как показывает практика, разработка более сложных защитных механизмов оказывается коммерчески неоправданной (исключение составляют специализированные программные комплексы, типа IDA PRO, PC 3000, продажи которых измеряются считанными тысячами штук). программы, ориентированные на массовый рынок, лучше распространять бесплатно, получая доход с рекламы, поддержки или других дополнительных сервисов (берите пример с Opera);
Рисунок 10 Opeara – бесплатно распространяемый браузер, извлекающий доход из сотрудничества с Google
