Защита Delphi-программ от взлома. Часть II – Защитно-обзорная (№1).

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

Все они достаточно разные. У каждой есть свои сильные и слабые стороны. Какие-то отламываются быстрее быстрого, а над какими-то нужно посидеть несколько больше. А какие-то в принципе не отламываются (да, есть такая).

Итак, давайте рассмотрим самые распространённые из них и поговорим об их сильных и слабых сторонах. Но для начала, чтобы развеять все ваши грёзы, запомните одно очень сильное и основное правило:

Лучшая, и единственно реальная защита  – это программирование действительно нужного и востребованного софта, а так же частые релизы новых (т.е. лучших) версий. Этим, и только этим вы можете стимулировать рост легально зарегистрированных пользователей вашего программного обеспечения.

И ещё одно правило от некоторых лиц ( предпочли остаться инкогнито ):

Реализовывать защиту на чистом ассемблере – себе дороже. Все статьи пестрят о том, что защита должна быть написана исключительно на ассемблере. Бред! Реверсер – ассемблерщик! Для него, наглядней ассемблера – только бумага туалетная, которой он ж#пу вытирает! Запомните программисты, чем еб#нутее (высокоуровневей. – прим. автора статьи) язык – тем сложнее его отлаживать на низком уровне. (не соглашусь с некоторыми вещами, но в целом отражает суть. – прим. автора статьи).

Защита на основе статической строки

Данный тип защиты совершенно не пригоден для использования в качестве защиты. Под статической строкой понимается единственный серийный номер, который просто и открыто вшит в программу. Что это значит? Это значит, что любой пользователь, который может воспользоваться дизассемблером, легко и просто выдернет этот код и воспользуется им. Такой метод взлома обычно называют String reference взломом.

Дело в том, что в любом нормальном дизассемблере, не говоря уже об отладчике есть возможность просмотра всех строк, которые, так или иначе фигурируют в вашей программе. Можно смотреть как ASCII, так и UNICODE строки. Если уж и использовать такой метод защиты, то нужно хотя бы неким образом зашифровать часть или даже всю строку или использовать разного рода обфускаторы, которые предназначены для защиты программ от этого самого String reference взлома.

Данный метод взлома может использоваться даже начинающими взломщиками. Они просто находят некие строки (например: Unregistered version или Incorrect cd-key), смотрят рядом лежащий в открытом виде код и вводят его в программу, или меняют условный переход и программа отломана. Худший вариант защиты.

Ещё один способ защиты от string reference взлома – это загружать все (или только интересные для взломщика) из вне, например из библиотеки или обычного шифрованного файла.

Пример программы: #1 ACE Search Engine Submission Software

 

Привязка к железу

Данный тип защиты обычно используют, когда хотят чтобы программа, работала только на одной машине. С одной стороны способ вроде бы и ничего, а с другой… ни в п**ду, как говорится, ни в красную армию. Мало того, что обходится простым патчингом (если знать где патчить), так ещё и создаёт некоторые неудобства, в случаи того, если пользователь купил новую машину или попросту сделал апгрейд старой.

Получается, что после пользователю, в случаи чего, нужно будет выслать новую копию программы. Некоторым выходом из ситуации станет привязка, например к флешке, да и то, этим мы ещё сильнее создаём проблемы пользователям.

 

Регистрационный файл-ключ

Этот метод использует проверку наличия и содержания некого файла, в котором хранится регистрационная информация. То есть, сначала информация считывается из файла, а потом проверяется. Останавливает начинающих крэкеров, но не более того. Если такая защита имеет место быть в вашем приложении, постарайтесь организовать ее так, чтобы контент файла проверялся по кусочкам (чем больше оных, тем лучше) и в разных местах программы.

Не храните в файлах-ключах всё в открытом виде. Лучше пусть всё будет зашифровано каким-нибудь стойким алгоритмом. Разбейте файл на логические поля, где будет присутствовать имя, e-mail ну и сам регистрационный код в виде длинной строки цифр и букв. Можно ещё придумать зашифрованное поле с контрольным вопросом и ответом и при регистрации (когда пользователю нужно будет выбрать файл-ключ) спрашивать пользователя. Знаешь ответ – проходи, нет – так умойся юшкой.

Проверка содержимого файла в функции – плохая идея. Понадобится патч всего одного байта, чтобы ваша функция возвратила TRUE (ключ валидный) вместо FALSE. Если вы сделали именно так, то не ленитесь и напишите ещё чёртову дюжину подобных (левых) функций-проверок, которые возвращали бы разные значения (может быть даже с разными типами данных).

Можно ещё сделать функцию-пустышку, которая открывает ключ функцией CreateFile и вызывается по таймеру каждую секунду. Если взломщик не очень опытный, он будет долго думать, почему он вываливается в отладчик каждую секунду, а то и чаще, когда поставит брейкпоинт на одноимённую функцию.

Так, отдаём ключ пользователю, который заплатил, он вводит его в программу, она его загружает, расшифровывает (по кускам и в разных местах) и делает соответствующие выводы. Всё это подходит против взломщиков уровня “низкий” или, в некотором плане для “средний”. Более опытные товарищи запросто смогут наковырять себе свой собственный ключ и без вас.

Пример программы: WinRAR, Total Commander

 

Демонстрационная версия программы

Я сейчас говорю не про тайм-триал (о ней позже). Я говорю о чистой демке, которую ломать можно долго и нудно, но никогда не сломать. Дело в том, что в демонстрационных версиях программы некоторые важные возможности попросту отсутствуют. Они не заблокированы, их просто нет. Отсутствуют целые куски кода. Новички – крэкеры часто пытаются отламывать демки, но естественно тщётно. Помню, на краклабе проскакивали темы на форуме (можно найти, если поднять архив форума), где новички просили помощи по взлому демок, на что получали ясные и понятные ответы что это нереально.

Казалось бы, вот она – Панацея! Но нет, демка – это как стул без пары ножек, то есть вроде бы и он родимый, а присесть нельзя. Нет в нём той функциональности. Как показывать такой стул потенциальному покупателю? Вот посмотрите, пожалуйста, какие мы удобные стулья делаем J. Не сможет он оценить всё удобство такого стула, а не оценит – не купит. Так и с demo-версиями программного обеспечения.

Получается, что хоть нашу программу взломать нельзя, то и продать тоже (в большинстве случаев), так как пользователь не сможет оценить тех крутых фишек, которые вы выкинули из демки и не поймёт, нужен ли ему такой продукт.

Но допустим у вас купили программу оценив демо и вы выслали полную версию. Так что мешает выложить полную версию в Интернет. Ничего. Вот и получается, что demo-версии – это палка о двух концах. И не так и не эдак они не рулят.

 

Защита класса имя-код (id железа – код ; сетевое имя компа – код… разные варианты)

Пожалуй самый распространённый метод защиты приложений. На основе введённого имени пользователя (или его электронной почты, или того и другого) программа генерирует эталонный серийный номер (он может быть не уникальным), сравнивает его с эталонным и делает вывод, пропускать вас, или нет.

На такие защиты очень падки так называемые кейгеннеры. Это – взломщики с достаточно богатым опытом, которым просто мало (или недостаточно) просто пропатчить программу или отловить серийник на своё имя. Они занимаются программированием (написанием) генераторов ключей, которыми, кстати, мы иногда не брезгуем воспользоваться.

Считается, что написание кейгена – чуть ли не высший пилотаж реверсинга. Это и понятно, ведь сначала нужно на протяжении нескольких дней (в случаи хорошей защиты) исследовать алгоритм генерации ключа, а только потом написать генератор. Да не простой генератор (обычная форма, кнопки и т.д) а лучший! Нужно привлечь так называемого GFX’ера (художник по оформлению кейгена) и CHIPTUNE’ра (те люди которые пишут трекерную музыку для кейгенов, от которой большинство из нас просто без ума), защитить свой будущий кейген от рипа (рипперы – люди которые воруют алгоритмы готовых кейгенов, или переделывают их под себя). В конце остаётся запрограммировать кейген на чистом ассемблере (реже на Си). В действительности – это адский труд нескольких высоко-профильных специалистов.

Кстати, есть кейгеннеры, которые не будут выкладывать свои разработки на публику, если видят, что алгоритм защиты действительно стоящий. Они не делают этого только из за уважения к автору программы. Солидарность. Ведь они – тоже разработчики. Максимум, такие кейгены остаются в так называемом привате той группы, в которой состоит реверсер. Это очень редкое исключение, но всё же, оно имеет место быть, и мы должны быть только благодарны и так же солидарны с такими группами, придумывая для них всё новые и интересные защиты и алгоритмы. Кстати, если не получится выдрать алгоритм генерации, то всегда можно пропатчить программу.

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

Больше функций приманок! Пусть они лихорадочно что-то высчитывают и ксорят. При проверке, вызывайте сначала их, а главную функцию можно вызвать ближе к середине, или к концу. Поверьте, это убьёт уйму времени взломщику, прежде чем он поймёт, в чём именно загвоздка.

Никуда не передавайте генерированный код в открытом виде. Если вы это делаете, то передавайте его по частям (что собственно тоже глупо. Шифруйте! – прим. некоторого лица).

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