CFA LogoCFA Logo Computer
Новости Статьи Магазин Драйвера Контакты
Новости
RSS канал новостей
В конце марта компания ASRock анонсировала фирменную линейку графических ускорителей Phantom Gaming. ...
Компания Huawei продолжает заниматься расширением фирменной линейки смартфонов Y Series. Очередное ...
Компания Antec в своем очередном пресс-релизе анонсировала поставки фирменной серии блоков питания ...
Компания Thermalright отчиталась о готовности нового высокопроизводительного процессорного кулера ...
Компания Biostar сообщает в официальном пресс-релизе о готовности флагманской материнской платы ...
Самое интересное
Программаторы 25 SPI FLASH Адаптеры Optibay HDD Caddy Драйвера nVidia GeForce Драйвера AMD Radeon HD Игры на DVD Сравнение видеокарт Сравнение процессоров

АРХИВ СТАТЕЙ ЖУРНАЛА «МОЙ КОМПЬЮТЕР» ЗА 2002 ГОД

Ломать не строить

Игорь ПАВЛОВ pavlov_igor@nm.ru

Пиратские компакт диски с кучей полезнейших программ по-прежнему свободно продаются на просторах нашей необъятной Родины. Цена таких дисков колеблется вокруг отметки $2. Не секрет, что стоимость ПО на таком носителе зачастую превышает $2. А ведь большинство программ на CD-ROM имели защиту от нелегального копирования, но она была успешно сломана. Как же можно защитить свой продукт от нелегального копирования, чтобы труд не пропал даром? Как противостоять армии взломщиков-хакеров?

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

Проходит еще пара дней и ночей. На скорую руку вы пишете простую защиту от нелегального копирования, основанную на серийном номере. На ту же руку быстро пишите сайт программы. Меню Buy Now!!! красуется на полэкрана. И вот вы сидите с заготовленными мешками для денег и ждете толпу покупателей.

Проходит еще несколько бессонных дней и ночей. Покупатели почему-то не спешат. Но вот наконец пришло первое письмо. Читаем: какой-то MadGuy хвастается, что написал crack для Вашей программы и пересылает его Вам. Еще обещает выложить этот crack в Интернете. Для тех, кто в танке: crack — это программка, модифицирующая другую программу, и, как правило, снимающая защиту от копирования. Быстро запускаем этот crack. Применяем. И… о боже! Теперь защита Вашей программы не работает! «Чем это мне грозит?» — спросите Вы. Только лишь тем, что денег за свою программу Вы уже вряд ли получите.

Законы против подобного варварства, конечно, есть (ст. 198-1 УК Украины). Но реальных примеров, чтобы закон помог программисту от пиратов, я не знаю. Значит в данном случае закон нам не помощник. Выход из этой ситуации банальный: «Учиться, учиться и еще раз учиться» (c) В.И. Ленин. Кто не знает — был такой знатный программист. Всякие там декреты о мире и о земле… Но это все немного не по теме.

Итак, будем учиться противостоять хакерам-взломщикам, или, говоря иначе, учиться защищать свою программу от нелегального копирования. Сразу оговорюсь: неломаемых защит не бывает. Любую защиту можно нейтрализовать — вопрос лишь времени и усилий. Примером тому могут служить продаваемые пиратами сломанные программы брэндовых фирм (Microsoft, Adobe, Borland). Уж такие гиганты могли бы написать достойную защиту своим продуктам! Положение усугубляется еще тем, что, как правило, в области защиты программ хакер знает гораздо больше, чем его заочный оппонент — программист. Наша задача — как можно больше усложнить жизнь хакеру, чтобы взлом программы отнял у него уйму времени и сил. Посудите сами: если стоимость программы будет порядка $10, а на ее взлом надо потратить сутки времени, то не каждый хакер захочет ковыряться ради таких денег. Если только он не фанатик. Но от хакера-фанатика, к сожалению, уберечься нельзя. Они ломают программы не ради корысти, а ради самого процесса взлома.

Итак, приступим к делу. Мы рассмотрим типичную защиту от нелегального копирования, а также действия хакера по взлому этой защиты. Для простоты понимания листинги программ я буду приводить на Delphi. Однако суть описанных методов для всех языков программирования одинакова. Еще нам понадобятся хотя бы поверхностные знания ассемблера. К сожалению, без этих знаний хорошую защиту не построишь.

Очень часто защита программы основывается на вводе серийного номера. Если номер совпал с эталоном, то регистрация прошла успешно. В коде программы это выглядит примерно следующим образом:

Вас просят ввести серийный номер. Если номер совпал с эталоном seRIal, то регистрация прошла успешно. В противном случае появится окно с надписью «Incorrect number». Вариант простой, зато дешево и сердито.

Что будет делать хакер? Он оперирует как минимум двумя вещами: отладчиком и дизассемблером. Какой бы язык и компилятор вы ни использовали, результатом будет EXE-программа, которая является, грубо говоря, набором машинных команд для процессора. А любой такой набор команд можно дизассемблировать, что с успехом и делает хакер.

Приведенный выше фрагмент кода на Delphi в дизассемблере будет выглядеть примерно так:

М-да, что-то с трудом понимается, скажете Вы. А зря — хакеру уже все ясно. Рассмотрим все по порядку: Эталонный и введенный номера сравниваются в строке .0045671B процедурой call .00404644. После процедуры сравнения идет условный переход, и если номера совпали, то выполняется строка .00456722, а если не совпали, то выполняется строка .0045672E. С этим вроде как все ясно. Если что-то не понятно, то советую воспользоваться любым справочником по ассемблеру и подсмотреть описание непонятных команд.

Что дальше делает хакер? Он заменяет команду условного перехода jne .0045672E на обратную —je .0045672E. И получается, что теперь программа регистрируется на любой номер, кроме эталонного! А еще эту команду условного перехода можно поменять на две пустых команды nop nop. Что получилось? После сравнения серийных номеров результат сравнения игнорируется. Теперь программа будет всегда выводить диалог об удачной регистрации. Второй вариант хакеру нравится больше, и он останавливается на нем.

Обратите внимание: хакер даже не пытался подбирать серийный номер или угадать алгоритм его генерации. Он подправил всего одну команду, заставив тем самым защиту работать неправильно. Именно к изменению условного перехода в основном и сводится взлом программы.

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

Становится ясно, что самое слабое место в защите — это процедура сравнения, а точнее, анализ ее результата в виде условного перехода. Причем не применять процедуру сравнения невозможно. Положение становится безвыходным. Стоит хакеру подправить нужный условный переход, и программа сломана.

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

1. Никогда не сравнивать номера сразу после того, как их ввел пользователь. Лучше записывать их, например, в реестр и сравнивать при загрузке программы.

2. После сравнения номеров не выводить сообщения вида «Неверный номер» — это только облегчит хакеру поиск алгоритма сравнения.

3. Применять упаковщики программ. Это помешает созданию crack’а для Вашей программы. EXE-файл программы становится как бы зашифрованным и расшифровывается непосредственно в память компьютера при запуске программы.

4. Самому шифровать процедуру сравнения — это затруднит ее дизассемблирование.

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

Теперь рассмотрим перечисленные правила поподробнее.

Если Вы сразу после ввода серийного номера производите его сравнение с эталоном, то найти процедуру сравнения номеров хакеру не составит большого труда. Он легко может найти в дизассемблерном листинге диалог ввода серийного номера, а сразу за ним искомую процедуру сравнения. Будет лучше, если Вы запишите введенный номер в реестр и попросите перезапустить программу. А при запуске программы прочитаете номер из реестра, но не будете сверять его сразу, а сделаете это по таймеру или по какому-нибудь действию пользователя.

Также не стоит сразу после сравнения номеров выводить сообщение «Неверный номер». Достаточно хакеру найти фрагмент кода, выводящий окно о неверном номере, и перед этим фрагментом он обнаружит нашу процедуру сравнения. Не стоит делать хакеру такого подарка. Гораздо лучше будет при неверной регистрации молча ограничить функциональность программы, т.е. запретить некоторые кнопки или что-то в этом духе. Такие действия отследить намного труднее.

Когда-то во времена динозавров и ДОСа были очень популярны упаковщики программ. Они ужимали программу, оставляя ее при этом исполняемой. С переходом на Windows упаковщики утратили свою актуальность. Но как ни странно, именно они помогут нам против хакеров. Упакованная программа становится как бы зашифрованной и не поддается прямому дизассемблированию. Хакеру приходиться изгаляться и искать распаковщики со специальными утилитами, что представляет определенное неудобство для него. Сейчас популярны упаковщики ASPack и UPX, но для них есть стандартные распаковщики. Поэтому лучше использовать малоизвестный упаковщик или шифровать программу своими руками.

Вот мы дошли до собственноручного шифрования. Это не потребует больших усилий, но зато намного усложнит хакеру жизнь. Рассмотрим пример шифрования процедуры. В готовом EXE-файле процедура будет находиться в зашифрованном виде, а значит, ее нельзя будет дизассемблировать. Мало того, Вы можете применить свой собственный нестандартный алгоритм шифрования, тем самым сбив с толку хакера.

Рассмотрим пример шифрования простой операцией исключающего ИЛИ. Допустим, у Вас есть процедура CheckTrial, которую Вы хотите зашифровать. В нешифрованном виде она выглядит так:

В тексте программы процедура EndCheckTrial обязательно должна следовать сразу после процедуры CheckTrial. Она нам нужна, чтобы знать адрес конца кода процедуры CheckTrial. Итак, зашифруем процедуру CheckTrial, а результат шифрования выведем в TMemo:

Если все сделано правильно, то в TMemo появился текст зашифрованной процедуры CheckTrial. Мы аккуратно вставим этот зашифрованный вариант процедуры в исходный код программы вместо ее нешифрованного варианта. Получится примерно следующее:

Моя зашифрованная процедура, скорее всего, будет отличаться от Вашей зашифрованной процедуры, так как ее вид зависит от компилятора и множества других факторов. Если теперь попробовать вызвать процедуру CheckTrial, то произойдет ошибка. Чтобы ошибки не было, надо сначала расшифровать процедуру, а потом вызывать ее. Напишем процедуру, которая расшифровывает CheckTrial и запускает ее:

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

Теперь подсчитаем контрольную сумму процедуры CheckTrial по простому алгоритму на основе исключающего ИЛИ. Я специально выбрал простой алгоритм, чтобы не забивать вам голову еще и лишней математикой. Итак, считаем контрольную сумму:

В переменной intCRC находится контрольная сумма процедуры CheckTrial. Вы можете сверять ее с заранее сохраненным значением. Если значения не совпали, то можно сделать вывод, что в Вашей программе уже поковырялись. Узнав это, можно просто создать в программе серьезную ошибку типа «Недопустимой операции» (c) Microsoft Corp. Сами понимаете, что взломанную, но неустойчивую программу никто распространять не станет.

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

И напоследок один дельный совет. Можно вообще сделать так, что в программе нечего будет ломать. Уже слышу резонный вопрос: «А разве такое бывает?» Бывает. И вот пример. Вы пишите демо-программу с ограниченной функциональностью. Причем в программе не просто запрещены какие-то меню, а вообще отсутствует код, отвечающий за эту функциональность. Пожалуйста! Ломайте на здоровье! Только вот ломать нечего… По получению оплаты за программу Вы высылаете полную версию программы с прошитыми реквизитами заказчика. Таким образом, если полная версия программы просочится на нелегальный рынок, Вы сможете прочитать реквизиты клиента, купившего полную версию, и наказать его по полной программе в соответствии с лицензионным соглашением.

Вот, собственно, все, что я хотел рассказать. Желаю успехов.

Рекомендуем ещё прочитать:






Данную страницу никто не комментировал. Вы можете стать первым.

Ваше имя:
Ваша почта:

RSS
Комментарий:
Введите символы или вычислите пример: *
captcha
Обновить





Хостинг на серверах в Украине, США и Германии. © sector.biz.ua 2006-2015 design by Vadim Popov