Оригинальный DVD-ROM: eXeL@B DVD !
eXeL@B ВИДЕОКУРС !

ВИДЕОКУРС ВЗЛОМ
выпущен 12 ноября!


УЗНАТЬ БОЛЬШЕ >>
Домой | Статьи | RAR-cтатьи | FAQ | Форум | Скачать | Видеокурс
Новичку | Ссылки | Программирование | Интервью | Архив | Связь

Исследование защит shareware-программ.

Обсудить статью на форуме

Хорошая подборка видеоуроков, инструментов крэкера, книг и статей - здесь.

Статью написал: Bad_guy <bad_guy@mail333.com>
Статья создана: 16.03.2003

Написанная мной в феврале 2003 года статья "Социальная инженерия в реверс инженеринге" - понравилась многим авторам сайтов Рунета, ее разместили на своих страницах порядка десяти сайтов, среди которых был даже сайт журнала "Хакер". И спустя месяц ко мне с просьбой написать статью для журнала "Компьютерра" обратился редактор Сергей Леонов, статью я написать согласился (она уже напечатана в "Компьютерре" от 22.04.2003), а от гонорара отказался в пользу размещения ссылки на CRACKL@B в журнале. Надо сказать, что я переоценил возможности журнала в продвижении сайта, ну да ладно...
А сейчас вы можете ознакомиться с содержанием этой статьи, однако сразу скажу, что статья писалась "на массу", поэтому вряд ли будет интересна опытному крэкеру.

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

Один из наиболее распространенных способов защиты программы - написание этой защиты собственными руками, и именно в таком способе проявляются крайности: эти защиты либо очень надежны, либо, наоборот, очень слабы. Объясняется это, по-видимому, степенью образованности автора в области защиты программ. Приведу простой пример: вы написали компьютерную игру и ничего не знаете про крэкеров, дизассемблеры, отладчики… Вы создаете окошко, в котором написано "Введите имя пользователя", "Введите регистрационный код", затем, по нажатию "OK", складываете коды всех символов в регистрационном имени и сравниваете это число с введенным регистрационным кодом, а потом, в зависимости от результатов сравнения, выдаете пользователю окошко, либо "Спасибо за регистрацию!", либо "Неверный регистрационный код". Теперь расскажу, как легко снять эту защиту: понадобится отладчик (самый популярный - SoftIce). Когда исследователь защиты вводит свое "имя пользователя" и произвольное число в качестве "регистрационного кода", он ставит в отладчике прерывание, которое остановит вашу программу при считывании данных из тех самых полей ввода. Отладчик покажет текст дизассемблированного кода программы в этом месте, далее программа пошагово исполняется под отладчиком, контролируемая крэкером. Рано или поздно, независимо от хитрости превращения имени пользователя в регистрационный код, крэкер увидит место, где сгенерированный программой правильный код будет сравниваться с введенным неправильным кодом. Теперь достаточно просто записать на бумажку правильный регистрационный код и ввести его в окошке регистрации. Реально весь описанный процесс занимает от 30 секунд до 10 минут. Самый же надежный на сегодняшний день способ защиты - это шифрование правильным регистрационным кодом тех процедур, которые работают только в зарегистрированной версии программы - такой способ защиты осуществить чрезвычайно тяжело, даже я не до конца знаю, как это сделать. Однако, слабой стороной этого метода является то, что код (или его часть) будет одним и тем же для каждого пользователя, то есть при распространении такого кода на крэк-сайтах, автор не будет знать, какой пользователь его распространил. Соответственно, он будет продолжать посылать коды для новых версий своей программы в частности и этому пользователю. Совсем не обязательно даже покупать программу, для получения кода есть два других способа: один из них противозаконный - его я рассматривать не буду, потому что действую всегда в рамках закона, другой способ менее действенный, но весьма законный - это социальная инженерия.
Социальная инженерия пришла в крэкерство из хакерства (в Рунете - во многом благодаря стараниям автора этой статьи), в хакерство же она пришла из жизни, где существовала с незапамятных времен. Как ни странно, многие и по сей день не знают что это такое, поэтому специально для разработчиков и исследователей программ рассказываю. Социальная инженерия - это некоторые действия над человеческим сознанием с целью получения желаемого результата, поэтому скорее речь идет не о том, как взломать программу, а о том, как "взломать" ее автора. Суть самого метода такова: надо уверить автора, что вам очень нужна зарегистрированная версия его программы, но у вас нет денег на ее приобретение. Таким образом вполне реально получить коды к shareware-программам не пользуясь ничем, кроме электронной почты. Разработчики программ должны знать о таком способе "взлома", чтобы не допускать влияния "человеческого фактора" на надежность защиты. Эта технология подробно описана автором в статье "Социальная инженерия в реверс-инженеринге", которую несложно найти поиском в Интернете.
Второй способ защиты программы, ставший недавно весьма популярным - использование специального протектора исполняемых файлов, то есть после компиляции своего творения автор берет программу-протектор и запаковывает ей собственную программу. Протекторы пишутся весьма грамотными профессионалами в области защиты, поэтому обеспечивают неплохой уровень противодействия взлому, с которым большинству исследователей программ не справиться. Но, поскольку некоторые из протекторов становятся очень популярными, их начинают исследовать все больше и больше не самых безграмотных крэкеров, которыми впоследствии пишутся программы-анпротекторы (распаковщики этой защиты). Подобные средства быстро и автоматически снимают эту защиту, хотя некоторые варианты приходится снимать вручную - это высший уровень крэкерства, доступный не каждому.
Третий способ - защита через Интернет. Если ваша программа работает с сетью, например, это может быть менеджер закачки файлов, браузер или FTP-клиент, можно применить проверку введенного в программу кода через Интернет, используя базу данных пользователей на сайте программы. Однако проверять нужно какие-либо косвенные данные, чтобы исследователь не мог получить с сайта программы, например, базу данных с серийными номерами. Для того чтобы снять такую защиту, нужно найти в программе место, где идет обращение к сайту и возвращается результат проверки. После нахождения достаточно просто подменить результат, например, с помощью пропатчивания программы в нужном месте. Сложность взлома этой защиты заключается в том, что достаточно непросто найти в коде программы место, где идет обращение к Интернет-серверу именно с целью проверки регистрационного кода.
Четвертый способ - аппаратные ключи. Этот метод защиты доступен только крупным разработчикам программного обеспечения, потому что приходится поставлять пользователю нечто материальное: диск с программой и сам ключ, кроме того, стоимость такого метода довольно велика. Снятие этой защиты - задача достаточно сложная, но осуществимая. Уже существуют эмуляторы аппаратных ключей, однако из-за редкости применения указанного способа, крэкеров, снимающих подобную защиту мало - многие ею просто не занимаются.

Безусловно, здесь приведены не все способы защиты программ, а лишь наиболее популярные. В помощь российским разработчикам программного обеспечения, как профессионал-исследователь защит программ, могу дать несколько полезных советов. На мой взгляд, в первых версиях своей shareware программы не стоит серьезно заниматься механизмом защиты. Дело в том, что можно, во-первых, переоценить практическую ценность своей программы - на самом деле она так плоха, что ее никто даже не купит, и смысл в защите пропадает. Во-вторых, зачем тратить на разработку защиты то время, которое можно с успехом потратить на раскрутку самой программы.
Допустим, ваш продукт начал продаваться, и вы получили свой первый гонорар. Теперь начинайте заходить на всевозможные крэк-сайты и ищите там крэк к своей программе. Пока вы его не найдете, не занимайтесь улучшением защиты - улучшайте саму программу, это принесет больше прибыли. Как только вы найдете крэк к своей программе в сети, сразу подумайте о другой защите, именно другой - меняйте сам принцип. Если вы не умеете самостоятельно писать защиту и не имеете средств на заказ профессионала, воспользуйтесь каким-нибудь коммерческим протектором программ. Разумеется, вам придется заплатить за его регистрацию порядка сотни долларов, но ведь ваша программа принесла уже больше… или нет? Можно предложить еще один альтернативный способ: обратиться к крэкеру, дабы он помог разработать алгоритм защиты. Конечно, это тоже будет не бесплатно, но наверняка меньше тех самых ста долларов, ведь большинство крэкеров - это обычные студенты. Желательно знать такого человека лично, иначе, при взаимодействии только через сеть, вас могут запросто обмануть.

Для тех, кто хочет самостоятельно писать защиту своих программ, также хочется привести несколько общих рекомендаций:

  • При вводе регистрационного кода в программу копируйте его в несколько переменных.
  • API-функции, на которые крэкер может установить прерывания в отладчике, имеет смысл поставить в цикл, и, таким образом, "зашумлять" ими реальные вызовы.
  • Никогда сразу не проверяйте правильность введенного регистрационного кода - сразу можно проверять только правильность его длины.
  • Не храните введенный код в памяти в незашифрованном виде.
  • Усложняйте алгоритм проверки пароля, проверяйте правильность пароля каждый раз при старте программы и выходе из нее, также проверяйте пароль отдельной процедурой во время работы программы (например, каждую минуту).
  • Тихо проверяйте целостность исполняемого файла программы, если целостность нарушена, можно вызывать "сбой в программе", например, каждый третий запуск.
  • Не держите регистрационный код программы в одном месте (лучше всего хранить его в по-разному зашифрованном виде и в файле, и в реестре, и в папке windows\system, маскируя под какой-нибудь config32.dll).
  • Не храните в открытом виде текстовые строки программы.
  • Старайтесь спрятать реальные вызовы функций за бутафорскими.
  • Читайте статьи по взлому и защите программ.

Вполне возможно, что прочитав эту статью вы решите заняться исследованием защит программ, или попросту, присоединиться к когорте крэкеров. Что для этого нужно? Как минимум: неплохое знание программирования на любом высокоуровневом языке (Pascal, C и т.д.), базовое знание ассемблера (достаточно знать его функции), также полезно знание архитектуры какого-нибудь еще более-менее используемого процессора (очень хорош для понимания Intel 486), нужно найти отладчик SoftIce, ну и еще пару статей для крэкеров-новичков. На первых порах - не лениться, не пугаться, проявлять настойчивость и уверенно действовать, тогда вы рано или поздно станете замечательным крэкером, а может даже и профессионалом по защите программ.



Обсуждение статьи: Исследование защит shareware-программ. >>>


Комментарии к статье: Исследование защит shareware-программ.


Материалы находятся на сайте https://exelab.ru



Оригинальный DVD-ROM: eXeL@B DVD !


Вы находитесь на EXELAB.rU
Проект ReactOS