Реферат Курсовая Конспект
Ограничение возможностей - раздел Информатика, NAG SCREEN Многие Незарегистрированные Версии Отличаются Тем, Что Часть Их Возможностей...
|
Многие незарегистрированные версии отличаются тем, что часть их возможностей заблокирована. Если программа предусматривает регистрацию, то обычно больших проблем при взломе не возникает. Совсем другое дело, когда регистрация не предусмотрена и в наше распоряжение дана DEMO-версия с ограниченными возможностями. Иначе говоря, есть две программы, никак не связанные между собой, — полная и демонстрационная версия. Строго говоря, очень вероятно, что взлом последней окажется невозможным, поскольку код, выполняющий некоторые функции, в программе физически отсутствует.
Часто это оказывается безнадежным, но не всегда. Если нет никаких других путей для получения легальной копии (например, ее автор эмигрировал в Штаты или запросил такие деньги, за которые лучше ее самому написать), то можно решиться на такой отважный шаг, каксамостоятельное воссоздание недостающего кода. Это сложный и трудоемкий процесс, требующий тщательного изучения алгоритма взаимодействия остального кода с отсутствующим.
Однако чаще всего код все же физически присутствует, но не получает управления. Например, просто заблокированы некоторые пункты меню, как в file:/ /CD:SOURCEVCCRACKODRELEASEcrackOD.exe. Такое действительно встречается очень часто и легко программируется. Все, что нужно сделать программисту, — это пометить в редакторе ресурсов некоторые элементы управления или меню как 'Disabled'.
Но что просто делается, так же просто и ломается. Необходимо воспользоваться любым редактором ресурсов. Я предпочитаю пользоваться 'Symantec ResoLirceStudio 1.0', однако пригоден и любой другой. Загрузим в него наш файл. Дальнейшие действия зависят от интерфейса выбранной программы и не должны вызвать затруднений, за исключением тех ситуаций, когда выбранный редактор не поддерживает используемого формата ресурсов или некорректно работает с ними. Например, с помощью Borland Resource Workshop мне так и не удалось выполнить эту операцию. Он необратимо портил ресурс диалога, хотя с разблокированием меню справился отлично.
Чтобы разблокировать элементы управления или меню, необходимо вызвать свойства объекта и снять пометку 'Disabled' или 'Grayed', после чего сохранить изменения.
Запустим программу, чтобы проверить нашу работу. Получилось! Не исправив ни одного байта кода и даже не прибегая к помощи дизассемблера и отладчика, мы осуществили взлом!
Удивительно, что такие защиты встречаются до сих пор, и не так уж редко. Психология разработчиков — воистину великая тайна. Очень трудно понять, на что они рассчитывают. Однако некоторые уже, видимо, начинают догадываться, что нет ничего проще и приятнее, чем редактировать ресурсы в исполняемом файле, поэтому прибегают к явным вызовам API типа EnableWindow(false). Т.е. блокируют элементы управления непосредственно во время работы. Разумеется, можно перехватить этот вызов отладчиком и удалить защитный код. Именно так поступит любой хакер и даже кракер. Рядовой же пользователь остановит свой выбор на программе, подобной Custornizer, которая позволяет "на лету" менять свойства любого окна, а впоследствии делать это и автоматически.
Таким образом, необходимо усилить реализацию защиты, чтобы ее вскрытие не было доступно широкому кругу пользователей. Достаточно ввести некоторую переменную типа 'Registered' и проверять при нажатии на кнопку се значение. Если Registered равна нулю, а пользователь каким-то загадочным образом все же ухитрился нажать заблокированную кнопку, то повторно блокируем кнопку или завершаем работу, мотивируя это несанкционированными действиями пользователя.
Именно так реализована защита, например, в crackOE. Откроем файл редактором ресурсов и убедимся, что все элементы разблокированы. Выключаются они позже, на стадии инициализации диалога, функциями API. Попробуем разблокировать их инструментом типа customizer-a. С первого взгляда кажется, что все в порядке. Но попробуем нажать кнопку "hello". Защита сообщает о незарегистрированной версии и вновь блокирует кнопку. Для простого пользователя такой барьер можно уже считать непреодолимым. Однако тому, кто знаком с ассемблером и отладчиком, нетрудно нейтрализовать подобную защиту.
Обратимся к MSDN и введем в строке поиска "Disable Window". Среди полученных функций будет только одна, непосредственно относящаяся к Win32 API, — EnableWindow. Можно загрузить отладчик и установить на последнюю точку останова или поискать перекрестные ссылки на нее же в дизассемблере. Но этому я, надеюсь, уже научил читателя. Давайте усложним себе задачу и попробуем обойтись без этих чудес прогресса. В конечном счете гораздо интереснее работать головой, чем техникой.
Очевидно, что сообщение "Это незарегистрированная копия" выдается защитным механизмом. Для этого он должен передать процедуре AfxMessageBox смещение этой строки. Разумеется, речь идет о смещении в памяти, а не в файле. Однако для РЕ-файлов его легко узнать, например, с помощью HIEW. Эта утилита — единственная из всех мне известных шестнадцатиричных редакторов, позволяющая просматривать локальные смещения для РЕ-файлов.
Находим строку "Это незарегестрированная копия", не забыв сменить кодировку, и переключаем Hiew в режим отображения локальных смещений. В нашем случае это будет 0х00403030. Не забывая про обратный порядок байтов в слове, ищем последовательность '30 30 40 00'. Если все сделать правильно, то получим только одно вхождение. Дизассемблируем прямо в HIEW-e найденный код:
.00401547: 8B4660 mov eax, [esi] [00060]
.0040154A: 85CO test eax, eax
.0040154C: jne .000401564—-—--- (1)
.0040154E: 6830304000 push 000403030 ;" @00"
.00401553: E8C2 020000 call .0004018lA -------- (2}
.00401558: бАОО push 000
.0040155A: 8D4E64 lea ecx,[esi] [00064]
.0040155D: E8B2020000 call .000401814 -------- {3)
.00401562: 5E pop esi
.00401563: C3 retn
Обратим внимание на условный переход. Несомненно, он ведет к нужной нам ветке программы. Однако не будем спешить его изменять. Это нам ничего не даст. Все элементы останутся по-прежнему заблокированными, и нажать на них мышкой не будет никакой возможности. Можно, конечно, найти соответствующие вызовы EnableWindow, но это утомительно и не гарантирует того, что хотя бы один мы не пропустим.
Найдем переменную, которая управляет выполнением программы. Очевидно, что это [esi+ОхОбО]. Необходимо найти код, который управляет ее значением. Если его изменить на противоположное, то программа автоматически зарегистрируется.
Сделаем смелый шаг: предположим, что esi указывает на экземпляр класса и переменная инициализируется в этом же классе. Тогда любой код, манипулирующий с ней, будет адресоваться аналогичным образом. Это на самом деле смелый шаг, потому что никто нам не гарантирует, что не будет иначе, особенно для оптимизирующих компиляторов. Однако он настолько часто оказывается эффективным, что нет нужды искать другие пути, пока не попробуем этот. В худшем случае мы ничего не найдем или получим ложные срабатывания.
На этот раз нам везет, и HIEW выдает следующий любопытный фрагмент:
.004013D3: 8В4С240С mov есх, [esp] [ООООС]
.00401307: С7 4 66000000000 mov d, [esi] [00050],00000
.004013DE: 5F pop edi
Это не что иное, как самое сердце защиты. Обратите внимание на то, что приложение не предусматривает явной регистрации. Переменная инициализируется одним н тем же, ни от чего не зависящим значением. Т.е. демонстрационная и коммерческая версии — это по сути дела разные программы. Но отличающиеся всего одним байтом. Попробуем присвоить этой переменной ненулевое значение
.004013D7; С7466000000000 mov d,[esi] [00060),00001
и перезапустим программу. Сработало! Нам не пришлось даже анализировать алгоритм защиты. Изменив только один байт (переменную-флаг), остальное мы возложили на саму защиту. Ни в коем случае нельзя сказать, что мы ее нейтрализовали или модифицировали. Защита все еще жива и корректно функционирует.
Однако, изменив флаг, мы ввели ее в заблуждение и заставили признать нас зарегистрированными пользователями. Это довольно универсальный и широко распространенный способ. Гораздо легче передать защите поддельные входные данные, чем анализировать много килобайт кода в поисках ее фрагментов, разбросанных по всей программе.
Впрочем, разработчики далеко не всегда ограничиваются одним флагом. Таких переменных может быть несколько, и они необязательно будут связаны друг с другом. Это усложнит задачу взломщика, особенно если защита проверяет, чтобы все флаги были идентичны. Тогда не остается ничего, кроме тщательного анализа. В худших реализациях бывает, что несоответствие флагов регистрации приводит не к вызову сообщений об ошибках, а к искажению алгоритма работы таким образом, что программа выглядит работающей, но фактически работает неправильно. Приведем пример:
return SomeResult*(!FlagRegl ^ F1agReg2);
Если два флага не равны друг другу, то в результате получится ноль? функция вернет неверный результат. Если такое, например, случится в программе расчета зарплаты, то последствия не заставят себя ждать. Самое печальное, что флаги регистрации могут одновременно являться и рабочими переменными программы. Обычно при этом флагу выделяют младший бит, а все остальное отводят под нужды какой-нибудь функции. Тогда без тщательного анализа всего кода невозможно быть уверенным, что приложение функционирует корректно.
К счастью, программисты часто оказываются слишком ленивы, чтобы детально проработать эту архитектуру. И рождают перлы типа CrackOF. Рассмотрим этот защитный механизм. Перед нами две заблокированных кнопки. Очевидно, для локализации защиты нужно найти вызовы EnableWindow.
j_?EnableWindow@CWnd@@QAEHH@2 proc near ; CODE XREF: sub_0_401360+D4p
– Конец работы –
Эта тема принадлежит разделу:
Каждому предоставлена полная свобода выбора — или терпи Nag Screen...
Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ: Ограничение возможностей
Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:
Твитнуть |
Новости и инфо для студентов