Крис Касперски

…Важно не только научиться. Важно не научиться.

Не научиться бывает подчас трудней.

Нарушить стандарт, отвергнуть шаблон.

Не принять общепринятого.

Л. Озеров

«Выбор и предпочтение»

Потребность в защитных механизмах растет с каждым днем, но качество их реализации падает вниз стремительным домкратом. Давным-давно сломан HASP, FLEX LM, ASProtect и другие широко разрекламированные решения, лишний раз подтверждая, что вы не можете доверять никакому коду, кроме своего собственного, но что делать, если вы и в себе не уверены? Эта статья перечисляет основные ошибки, совершаемые разработчиками, и дает советы по усилению защиты.

В борьбе за выживание защитные механизмы обречены. Защита лишь продлевает мучения программы, отодвигая ее взлом на некоторый срок. Теоретически. Практически же ничего не стоит создать защиту, позволяющую программе дожить до преклонных лет и «умереть» собственной смертью, передавая наследие следующей версии. Главное – правильно забаррикадироваться. Бессмысленно вешать стальную дверь на картонный дом. Линия обороны должна быть однородна во всех направлениях, поскольку стойкость защиты определяется наиболее уязвимой ее частью.

Мы не будем касаться вопросов целесообразности защиты как таковой (это отдельный больной вопрос), а сразу перейдем к рекомендациям, следование которым усилит защиту настолько, насколько это возможно. Необходимо не только добиться экономической нецелесообразности взлома, но и убить моральный стимул к хакерству «на интерес» – для этого защита должна быть максимально «тупой», а ее взлом – рутинным.

Выбирайте только надежные, системно-независимые методики. Хитроумные антиотладочные приемы только разжигают хакерский интерес, и что еще хуже – выдают ложные, срабатывая у легальных пользователей, а этого допускать ни в коем случае нельзя. Делайте ставку на частый выход новых версий и техническую поддержку – это оттолкнет пользователей от «кракнутых» версий.