NAG SCREEN

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

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

Но кому понравится назойливая реклама или периодически всплывающий экран с просьбой нажать ту или иную клавишу (каждый раз разную)? "Nag" в переводе с английского — "изводить, раздражать, ныть", а также "придирки, постоянное ворчание". Нетрудно представить, как пользователи относятся к подобным защитам. С другой стороны, каждому предоставлена полная свобода выбора — или терпи Nag Screen, или заплати немного денег за регистрацию и вздохни с облегчением.

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

С точки зрения хакера это вовсе и не защиты. Все, что здесь требуется, — это слегка модифицировать код. Трудно найти причину, которая могла бы этому помешать. Кроме того, практически всегда nag-screen-ы используются в комбина­ции с регистрацией на имя пользователя. Поэтому возможны по крайней мере два варианта: написать свой генератор регистрационных номеров (как уже описано выше) или модифицировать код так, чтобы nag-screen больше никогда не появлял­ся. Обычно первое гораздо предпочтительнее и проще в исполнении. Модифика­ция же чужого кода всегда сопряжена с большими законодательными ограниче­ниями и не может быть рекомендована. Но иногда незарегистрированная и зарегистрированная копии — это две разных программы, и есть только один путь из первой получить вторую — модифицировать исполняемый код.

Рассмотрим типичный пример защиты file://CD:SOURCEVC CRACKOARELEASEcrackOA.exe. Если запустить этот примитивнейший тексто­вый редактор, то работе будет мешать периодически появляющееся диалоговое окно, закрыть которое в течение некоторого времени будет невозможно.

Каким образом его можно убрать? Первое, что приходит в голову. — дизассемблировать приложение, найти код, создающий диалог, и нейтрализовать его. Мысль, безусловно, правильная, но не дающая ответа на вопрос, как среди километров листинга дидассемблера найти нужный фрагмент. Установить точку останова на АР1-функцию создания диалога можно, но бесполезно. Код, вызыва­ющий се, находится где-то глубоко в недрах MFC42.DLL и совершенно неинтере­сен. На самом деле диалог запускается на выполнение функцией CDialog::DoMo-da1(). Ее ординал равен Ox9D2. Получить его можно описанным выше способом с помощью dumpbin или IUA. Поскольку последнее подробно еше не рассматрива­лось, сделаем это сейчас. Загрузим файл в дизассемблер и откроем окно имен (ALT-VN). Найдем в нем 'DoModal'.

Справа указан адрес ординала в таблице импорта. Было бы логично переклю­чить дизассемблер в hex-режим (благо IDA это позволяет) и узнать, что по этому адресу находится. К сожалению, по непонятным мне причинам она отказывается это выполнить.

Если в используемой вами версии этот недостаток не устранен, то на экране появится белиберда. Если же заглянуть по этому адресу, скажем в HIEW-e, то можно увидеть следующее

По адресу Ох4020А4 находится слово Ox9D2 — это и есть ординал CDialog:; DoModaK). Интересно, что некоторые версии Soft-Ice находят его неправильно! Если, исходя из здравого смысла, установить точку останова на MFC42!ORD_09D2, то... можно потратить уйму времени, но так и не выяснить, почему же отладчик не всплывает, хотя диалог все же создается!

На самом деле необходимо дать команду ВРХ MFC42109DI — по совершенно магической причине это сработает. Первое всплытие мы пропускаем, поскольку в создании главного диалога нет ничего интересного. Выйдем из отладчика и немного подождем. Вызов nag-scre-еп-а защитой вызовет исключение, и мы окажемся в самом начале процедуры DoModal. Выйдем из нее командой р ret и изучим окружающий код.

Mov ESI,ECX

Mov ЕAХ, [ESI+60]

Test ЕАХ, ЕАХ

Jnz loc_0_4015F4

Lea ЕСХ, [ESP+O4]

Mov DWORD PTR [ESI+60],01

Call sub_0_401150

Lea ЕСХ, (ESP+01]

Mov DWORD PTR [ESP+OOOOOOBO]

Call CDialog: : DoModal (void)

Dec DWORD PTR [ESI+60]

Необходимо найти причину появления диалога и обезвредить. С другой стороны можно не разбираться в защитном механизме, а удалить процедуру вызова диалога, заменив 'Ев 57 02 00 00' в строке 0х0401504 на '90 90 90 90', но это самый варварский способ. Посмотрим лучше чуть выше, на бросающуюся в глаза конструкцию:

015F:0040159E MOV ЕАХ, [ESI+60]

015F:004015A1 TEST EAX,EAX

015F:004015A3 JNZ loc_0_4015F4

Куда ведет ветка loc_0_4015F4? Прокрутим окно немного вниз:

loc_0_4015F4

015F:004015F4 MOV ECX.ESI

015F:004015F6 CALL CWind: :Default(void)

015F:004015FB MOV ЕСХ, [ESP+OOOOOOA8]

015F:00401602 POP ESI

015F:00401603 MOV FS: (00000000],ЕСХ

015F:0040160A ADD ESP, OOOOOOBO

015F:00401610 RET 0004

Несомненно, этот условный переход вызывает ветку, завершающую процедуру без создания диалогового окна. Если JNZ заменить на безусловный переход, то ветка защиты никогда не получит управления, — следовательно, nag-screen никогда не появится. Работу кракера на этом можно считать завершенной. Программа взломана, клиенты довольны, разве хоть что-то еще осталось? Но хакеры обладают пытливой натурой, поэтому назначение переменной [ESI+60J не может их не заинтересовать. С первого взгляда все ясно. Это переменная типа BOOL. Если она равна TRUE, то NAG-SCREEN никогда не появится. Можно даже с уверенностью дать ей символьное имя 'Registered*. Однако взглянем на код защиты еще раз:

015F: 0040159E MOV Eах, [ESI+60]

015F: 004015A1 TEST ЕАХ, ЕАХ

015F: 004015A3 JNZ loc_0_4015F4

015F: 004015A5 LEA ЕСХ, [ESP+04]

015F: 004015A9 MOV DWORD PTR [ESI+601,00000001

015F: 004015B0 CALL sub_0_401150

015F: 004015B5 LEA ЕСХ, [ESP+04)

015F: 004015B9 MOV DWORD PTR [ESP+OOOOOOBO],0

015F: 004015C4 CALL CDialog:: DoModal (void)

015F:004015C9 DEC DWORD PTR [ESI+60]

015F:004015CC LEA ECX, [ESP+68]

015F:004015DO MOV DWORD PTR [ESP+OOOOOOBO],1

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

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

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

Продолжим трассировку или сразу выйдем из процедуры, командой р ret. Soft-Ice покажет, что мы находимся глубоко внутри процедуры MFC42!ORD_142B (OnWndMsg@CWnd) или, другими словами, в цикле выборки сообщений. Пере­данное сообщение находится по адресу ss:[ebp+8]. Легко видеть, что в нашем случае это 0х113, которое более известно как WM_TIMER (это можно выяснить командой WMSG 113).

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

Рассмотрим таблицу импорта crackOb.exe:

USER32.dll

FO GetClientRect