TOP10 ошибок защитников программ


Мелкие промахи, ведущие к серьезным последствиям - часть 2


5)       обнаружив взлом, не пытайтесь "мстить" пользователю нестабильной работой!

далеко не каждый потенциальный клиент догадается, что причина сбоев кроется в плохом краке, а не самой программе! столкнувшись с проблемами, он не побежит регистрироваться, а просто установит конкурентную программу и по своему будет очень логичен и прав;

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

 

Рисунок 8 голубой экран смерти, вызванный ошибкой в драйвере защиты

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

 

Рисунок 9 протектор, конфликтующий с VM Ware, подрывает доверие пользователей к программе

8)       никогда не доверяйте API-функциям — их очень легко перехватить и подсунуть любой желаемый результат, тем более, не используйте прямых вызовов API-функций в программе, преимущественно использующей библиотечные функции и RTL, поскольку это сразу же демаскирует защиту, позволяя локализовать "логово дракона" во многомегабайтой чаще кода программы;




Начало  Назад  Вперед



Книжный магазин