|
"Knowledge itself is power" F.Bacon
|
Проблема защиты, взгляд "изнутри"
|
Вернуться к разделу Свитки
Автор: Астапов Макс, дата публикации 23 октября 1999 г.
Недавно заметил на "Королевстве" некоторый интерес к защите программ от нелегального
использования. Мне показалось, что данная тема будет многим интересна и я хотел бы кое-что пояснить.
Я постараюсь объяснить суть проблемы защиты в принципе, так что конкретных вещей Вы тут не увидите.
Существует масса способов, как защитить программу от такой напасти, как бесконтрольное копирование или,
говоря проще, воровство. Небольшие "шареварные" программы обычно защищают номерами, более серьезное ПО -
всякого рода ключевыми дискетами, электронными ключами и т.д. А самое "крутое" ПО вообще не защищают, и это,
на мой взгляд, самое мудрое решение...
Дело в том, что на самом деле совсем не важно, каким способом вы будете защищать свой код, в ЛЮБОМ
случае все сведется к конструкции:
IF <признак правильного ключа>
THEN <программа делает необходимые для дальнейшей
нормальной работы пометки и работает нормально>
ELSE <программа Вас отшивает>.
Догадываетесь, что нет смысла "городить огород", оставляя такую дыру. Занимаясь, как сейчас принято
говорить, "проблемами защиты" программ, а попросту говоря, вскрывая их, я встречал различные
варианты защиты, как правило, на основе серийного номера в различных вариациях (имя-код, хеш от
параметров компьютера-код, и д.р.). При этом меня не сильно интересовали внутренние механизмы реализации этих вариантов,
просто я искал вполне определенный набор инструкций, содержащий переходы
(обычно JNZ, JZ), которые и приводили меня к нужному результату.
В краце опишу основные методы вскрытия защиты. Практикуется два способа устранения защиты:
чистый - нахождение номера и "жесткий" (я бы сказал жестокий) "взлом". Первый способ самый
лучший, дается 100% гарантия, что программа будет работать как ей и положено. Второй способ легче
первого (не надо искать ключ), и заключается в том, что в программу вносятся изменения (соответствующие
инструкции условного перехода меняются на противоположные (так делают люди с чувством юмора, поскольку
годится любой номер, кроме правильного), либо на инструкции безусловного перехода), машинные коды
этих инструкций берутся из отладчика. В этом случае программа тоже работает, но нет гарантии, что она
не выкинет какой-нибудь фокус в дальнейшем, думаю, что все видели некорректно "крякнутые" программы.
Следует отметить, что защита, основанная на привязке: к дискете, серийному номеру винчестера, номеру BIOS,
HASP и им подобным, снимается именно способом №2.
Теперь разберемся какие меры можно предпринять с тем, чтобы вашу программу (если Вы удостоитесь
такой чести, конечно) не "крякнули". Как я уже и говорил, тип защиты практически не важен (в обычных случаях),
поэтому выбирайте тот способ защиты, который вам больше по душе - с точки зрения вскрытия, это практически все равно.
Так как самым узким местом в защите, как мы выяснили, являются переходы, то нам надо их прятать. Как?
Ну во-первых, для тех, кто не знает, как в коде находится тот кусок, который отвечает за защиту,
объясню - это делается путем установки "ловушек" - брейкпоинтов на определенные API функции
(запрос строки, выдачу сообщения об ошибке регистрации и массу других косвенных).
Далее, при срабатывании ловушки, исследуется последующий код, благо отладчик предоставляет для этого массу возможностей, и в конце концов находится
нужный переход (либо кончается терпение и время), далее следует реализация способов №1 или №2.
Так вот, первое: следовало бы постараться не использовать стандартные функции API для передачи в программу
регистрационных данных (номеров и др.). Сделать это, насколько я понимаю, сложно, поскольку мне встречались
некоторые попытки обойтись нестандартными фунциями, но они были безуспешны, так как копнув глубже, места передачи регистрационных
данных успешно обнаруживались "ловушками", установленными на более низкоуровневые фунции.
Поэтому, как говорил отец Браун: "Где прячут лист - в лесу", следует
чаще вызывать регистрационную информацию (либо проводить иные проверки), с тем чтобы у коварного взломщика
на исследование всей этой "липы", а может и не липы:) ушло как можно больше сил и времени.
К тому же есть еще такие неприятные для "исследователя" моменты: при разборе кода, когда не понимаешь, что делает тот или иной кусок, желание копаться в нем дальше, постепенно
пропадает, ровно как и при исследовании "бесконечного" кода.
Естественно, через какое-то время "нюх ослабнет", и нужный момент будет пропущен.
Поэтому, следующий вывод: имеет смысл делать не только несколько проверок, но и проводить их разными алгоритмами, в разных частях программы. Это
полезно еще и потому, что если даже какую-либо проверку удастся обнаружить и обезвредить,
то остальные, не найденные, привязанные к другим модулям программы, останутся и будут "гадить", что сделает
взлом не совсем чистым, а цель не достигнутой.
Более конкретно сложно сказать,
так как я себе слабо представляю, как связан высокоуровневый код с ассемблерным, а проблемы при вскрытии
возникают, естественно, с ассемблерным кодом под отладчиком.
Еще... В некотором смысле глупостью со стороны
разработчиков является и то, что в программе предусматривается жесткий шаблон на формат ключа, что,
разумеется, подсказывает, какую последовательность литер нужно искать (например код из 8 цифр - значит
строки с буквами не в счет), поэтому делать такие вещи не стоит.
Ну и последнее, что можно порекомендовать -
это самому попытаться вскрыть свою программу хотя бы тем отладчиком (или способом), которым Вы умеете
пользоваться, ну и следует, конечно, почитать какую-либо "докуменцацию" по "Reverse Engineering".
Астaпов Макс, 1999 г.
P.S. Вопрос: а Вы лично регистристрированной Дельфи (и Windows, заодно) пользуетесь? Нет?
Ну тогда давайте будем коммунистами (в смысле бесплатности) до конца.
[Основная страница]
[Карта сайта]
[Дальние Земли]
[Круглый стол]
[Книга Песка]
[Свитки]
[Фолианты]
[Сокровищница]
[Подземелье Магов]
[Рыцарский зал]
[Базарная площадь]
[Городская площадь]
[Почта]