RCE.SU - реверсинг, кодинг, выделенные сервера, ICQ, proxy

Современное ПО: основные недостатки защиты и общие способы их устранения.

Target: защита программного обеспечения.
Автор: GoKs [UOFG Crew]
Соавторы: aSL! [UOFG Crew]
Жарче тяжести в груди,
Возникает дальний свет,
Если сможешь, - помоги мне
Поверить в свою смерть!
(Ю. Чичерина.)
INTRO.
Данный материал предназначен для всех тех, кто создаёт собственные программные продукты или пишет для них защиты. Надеюсь меня простят все те, кто эти защиты ломает и обходит ;-)!

Причины побудившие написать этот материал.
Проанализировав весь найденный и доступный материал в Сети по взлому ПО (благо такого материала сейчас предостаточно), а также основываясь на собственном опыте и опыте членов нашей команды, я пришёл к выводу, что огромное количество “шареварного” софта практически не имеет защиты от “крэкеров”, либо защищено плохо и для “крэкеров ”, как бы специально оставлены дыры. Также, меня глубоко задевают выпады и “наезды” некоторых разработчиков в адрес нашей команды. Постоянные посетители нашего сайта поймут, о чём я говорю. Для тех же, кто не часто заглядывает к нам, поясню: некоторые производители ПО, найдя у нас на сайте или в сети “крак” к своему продукту, сильно “расстраиваются” и начинают строить козни людям, которые сломали их защиту, обращаясь к администрации серверов на которых размещены такие сайты. Администраторы, находясь под давлением разработчиков , закрывают такие ресурсы L. Я думаю, что эти люди в корне неправы! Простым удалением такого ресурса из Сети - проблему не решить! Закрыв один сайт - вы вызываете противодействие по ту сторону баррикады и, как следствие этого, - на один закрытый “варезный” сайт, появляется два, а то и больше ресурсов подобного рода ! Это -социальная проблема, и таким вот способом её никогда не решить! Но пути решения всё же, как мне видится, существуют. Один из них - это создание действительно сильной защиты!

I. Обзор распространённых типов защит.
Теперь, чтобы непосвящённым, было легче ориентироваться, небольшой обзор существующих современных типов защит.
Итак, на сегодняшний день, представлено довольно большое количество способов защит ПО, но я коснусь в этом материале, только тех, которые пользуются наибольшей популярностью у производителей.
1 тип. Так называемые демо-версии ПО. Проанализировав довольно большое количество таких “демок”, я сделал вывод, что это наиболее хороший способ защиты от несанкционированного использования ПО.
2 тип. Защита ограничением времени работы программы (30 дней или определённое количество запусков). Очень неудачный способ защиты и поддаётся взлому даже начинающему “крэкеру”.
3 тип. Защита на основе генерации серийного номера в зависимости от имени (компании) пользователя . Также довольно слабый способ, хотя иногда и встречаются довольно удачные реализации этого типа защит. В эту же группу я бы включил защиты, основанные на генерации серийного номера в зависимости от отпечатка, созданного программой при первом её запуске. Причём, отпечаток генерируется программой в зависимости от того, какие параметры имеет “железо” компьютера. Здесь намного больше удачных решений, но сам способ не удобен для юзера, купившего такую программу, - ведь при модернизации “железа” ему вновь придётся обращаться к автору, а это не всегда возможно и удобно.
4 тип. Защита, основанная на внешнем “ключевом файле”, так называемые “key-file защиты”. Программа при каждом запуске ищет такой файл в своей директории, и если находит, то считывает зашифрованную информацию из него, расшифровывает её, сравнивает контрольную сумму, полученную при расшифровке и если всё ok, то программа работает как зарегистрированная, если же такого файла нет, или информация при сравнении получается критичной, то программа не запускается вовсе или работает в демо-режиме. Довольно неплохой способ, начинающие “крэкеры”, как правило, не могут сломать подобную защиту, если она грамотно реализована .
5 тип. Навесные защиты типа Vbox, Asprotect, Aspack e.t.c. За этим типом защит я вижу большое будущее. Довольно неплохие решения, но опять же подавляющее большинство подобных защит слабо и в Сети существует огромное количество утилит, снимающих автоматически такие защиты. Но мне представляется наиболее перспективным это направление. Объясню почему. Большинство таких защит, включают все рассмотренные выше типы, сразу, “в одном флаконе”, плюс ко всему используются алгоритмы сжатия исполняемых модулей и шифрование кода программы. Наиболее яркий пример этой группы -Asprotect, и, я думаю, многие любители “пореверсировать”, со мной согласятся, что он - наиболее удачный на сегодняшний день. Хотя продвинутые “крэкеры”, при наличии определённого опыта и наборе определённых средств, успешно справляются и с этим продуктом.
5а тип. Особняком тут стоят весьма известные защиты, применяемые в мире игрушек. Надеюсь, что такие имена, как LaserLock, SecuRom, SafeDisc, StarForce и др. Как правило, они сочетают защиту пятого и третьего типа. Немного поясню: программа как бы “привязывается” к диску, на который она записана, т.е. она зашифрована при помощи отпечатка оригинального диска. Очевидно, что здесь возникают некоторые проблемы при анализе. Наиболее грамотной я хотел бы назвать StarForce. Она Вам, наверное, известна по такой игре, как “Рандеву с незнакомкой”
6 тип. Защиты, осуществлённые при помощи электронных ключей, так называемые “dongle”. Наиболее “трудноломаемые”. Если бы не дороговизна данного типа защит, то, наверное, всё ПО защищалось при помощи “донглов”. Материала по ним в Сети намного меньше, чем по остальным типам защит. Этот тип защит успешно снимают только продвинутые и опытные “крэкеры”.
Существует ещё несколько типов защит, но я не буду на них останавливаться, так как они не получили широкого распространения на рынке ПО. Естественно, что все вышеперечисленные типы, последнее время комбинируются, что усложняет их взлом, но всё же не делает это невозможным.

II. Основные недостатки рассмотренных типов защит ПО.
1.Демо-версии ПО. Итак, как я уже выше упоминал, этот тип, на мой взгляд, наиболее удачное решение! Но и здесь есть несколько подводных камней. Если вы пишите полноценный программный продукт, то не забывайте написать отдельную демо-версию этого продукта, в котором действительно не будет каких-то существенных функций! Многие же авторы поступают так: пишут полноценную программу, а затем из неё “делают демку”, вставляя несколько “хитрых переходов” перед вызовом функций, эти самые “переходы” вроде как выключают эти функции и у пользователя складывается впечатление, что он пользуется демо-версией программы, на самом же деле стоит исправить 2-3 байта в коде программы и получаем полноценный продукт! В качестве примера я хочу привести достаточно известную программу под названием “Астра-Д”. В демо версии ее, например, отключена такая опция, как печать. Но! Код, отвечающий за нее в программе присутствует, и простой заменой 3 байт проблема легко решается.
2.Временное ограничение. Довольно “древний” способ защиты, поэтому и наиболее уязвим. “Ломается” новичками, которые вчера прочитали документацию к Soft-Ice и пару статей на reversing.net. J А всё потому, что здесь нет новых решений. Реализуют либо программный счётчик дней (запусков), либо при первом запуске программа прописывает дату своего запуска в реестр Windows и потом при каждом запуске сравнивает сколько прошло дней (запусков), либо делают то же самое, только используют не реестр, а файл, который прячется на жёстком диске. Единственное, утешает то, что этот способ самостоятельно почти не используется, а комбинируется с каким-либо другим.
3.Серийные номера и key-file защиты. Здесь основной ошибкой является, либо использование слишком простых алгоритмов генерации серийного номера, что приводит к написанию “кейгена”, либо наоборот - алгоритм достаточно сложен, но оставлено слишком много лазеек для реализации “битхака”.
4.Навесные защиты. Здесь очень много недостатков, поэтому все их перечислять не буду, а назову лишь те, которые встречаются очень часто:
  • не реализованы антиотладочные приёмы или реализованы те из них, которые нейтрализуются специальными утилитами, типа FrogIce. Это в конечном итоге приводит к распаковке \ расшифровке и снятию защиты;
  • слабые алгоритмы шифрации кода, что позволяет снять защиту даже не расшифровывая код программы; (Прямо под отладчиком).
  • не реализована или реализована неудачно проверка контрольной суммы и целостности кода;
  • навесная защита использует реестр. Как пример: программа защищена Asprotect -ом, включена функция ограничения работы (30 дн.). Запустив утилиту RegMon, мы без труда найдём ключик в реестре, удалив который, получим возможность пользоваться программой ещё 30 дней и это можно делать сколь угодно долго;
  • самая большая ошибка J. Господа авторы навесных защит! Вы не следите за сайтами на которых представлены утилиты для автоматического снятия ваших защит! Советую при обнаружении таких программ - исследовать работу такой утилиты, сделать выводы и исправить найденные ошибки, а то и заново переписать алгоритм защиты. Также, Господа Авторы! Вы не откликаетесь на добровольные предложения о помощи в усовершенствоании защиты.

6.Электронные ключи. С этим типом защит ситуация намного лучше. Тут распространёнными ошибками являются:
  • использование возможностей электронного ключа не на полную мощность;
  • проверка на наличие ключа реализована 1 раз, обычно при запуске программы;
  • не использована возможность шифрации программного кода при помощи так называемого “конверта” (envelope)..

III. Общие рекомендации по улучшению рассмотренных защит.
1.Демо-версии. При написании демо-версий программ, “обрезайте” полностью функции, которые вы хотите исключить из “демки”. 2.Временные защиты. Никогда не пользуйтесь одним лишь этим типом защиты! Обязательно комбинируйте с другими типами защит. 3.Серийный номер и key-file защиты. При использовании подобных защит используйте несколько алгоритмов генерации с возможно большей длинной ключа (в качестве примера можно взять наш 2-ой “крякмикс”). Чтобы защититься от “битхака” при невозможности написания генератора ключей, включайте больше проверок правильности серийного номера и интегрируйте эти проверки в основные функции программы. Желательно использование шифрования кода программы.
4.Навесные защиты. Используйте все возможные антиотладочные приёмы. Старайтесь не использовать реестр Windows для хранения данных о запуске программы. Используйте при шифровании кода программы алгоритмы с большой длиной ключа. Желательно, при запуске программы, чтобы она не расштфровывалась сразу в память компьютера целиком, а это делалось бы “ступенчато”, по мере необходимости. Делайте больше проверок контрольной суммы и целостности кода, интегрируйте их в наиболее важные функции защищаемой программы.
5.Электронные ключи. Здесь самое важное использовать все возможности ключа. Обязательно делать множественную проверку на наличия ключа. Обязательно использование “конверта”. Также, неплохо включать проверку контрольной суммы в наиболее важные функции программы. Используйте для шифрации данных программы данные из ключа (это есть во многих современный ключах). Также, хотелось бы отметить целесообразность применения блочных шифровщиков, всроенных во многие ключи.

IV. Общие рекомендации по созданию “трудноснимаемой” защиты.
1) Используйте “труднореверсируемые” языки программирования, такими на мой взгляд являются:
а)Visual Basic - наиболее сложный для реверсирования;
б)Delphi - запутывает взломщика из-за большой “вложенности” кода получаемого после дизассемблирования.
2) Комбинируйте несколько типов защит.
3) Если программа использует Internet при выполнении каких-либо функций, обязательно включите в программу процедуру проверки “валидности” регистрационных данных на служебном сервере.
4) Обязательно криптуйте код программы, это если не остановит “взломщика”, но создаст ему дополнительные трудности.
Помните! Не существует неломаемой зашиты! Если Вы сделали защиту, то найдется человек, который ее снимет; исключение: Вы - Господь Бог. Запомните! Вы должны сделать такую защиты, чтобы стоимость ее снятия была соизмерима со стоимостью самой программы.

Заключение.
В заключении хочется сказать, я не хотел бы этим кратким обзором кого-либо обидеть. Я лишь констатировал те факты, которые реально существую на современном рынке ПО. У некоторых читателей могло возникнуть ощущение, что все существующие защиты очень слабы - это не так! Ситуация в последнее время меняется в лучшую сторону. “Крэкерам” всё труднее становится при взломе программ. Хотя, иной раз, встречаешь неплохую программу, начинаешь исследовать её защиту, и приходишь к выводу, что автор отдал все свои силы на создание и усовершенствование программного продукта, а на написание хорошей защиты не хватило сил или желания.
Хочу проинформировать авторов ПО! Наша команда готова протестировать любую вашу защиту, сделать развёрнутый отчёт по обнаруженным недостаткам и дать рекомендации по улучшению защиты (вплоть до написания более сильной защиты).
Также, наша группа готовит к выпуску (конец ноября) свой шифровщик исполняемых файлов, в котором мы постараемся реализовать все те пожелания, что были рассмотрены в этом материале.
Endnote:
© 2001 GoKs [UOFG Crew] goks@uofg.cc
Additions © 2001 by aSL! [UOFG Crew] asl@uofg.cc
Greets to: everyone in UOFG, TDS , reversing.net and all crackers in da world
UOFG Crew Web Site: http://www.uofg.cc


<= Вернуться к статьям


Rambler's Top100