Ключевой файл

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

Можно рассмотреть два типа атаки. В первом хакер воссоздает ключевой файл, не затрагивая сам защитный механизм, а во втором модифицирует послед­ний так, чтобы удалить проверки наличия/валидности ключевого файла. Обычно хакеры выбирают первое, поскольку это зачастую проще и вызывает меньше конфликтов с законодательством. Теоретически "левый" ключевой файл можно объявить поддельным, но чтобы за это привлечь к уголовной ответственности, формат ключевого файла должен быть защищен авторскими правами, что далеко не всегда возможно. Действительно, сам формат не может быть защищен по нашему законодательству. Можно защитить, скажем, используемую функцию шифровки. Но для этого нужно ее разработать. А авторы защит, напротив, сами склонны "втихаря" применять патентованные алгоритмы, ничего не отчисляя за их использование. Кроме того, не известен еще ни один судебный процесс, который был бы возбужден по этому поводу. Это, конечно, никак не должно

 

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

Все ключевые файлы можно разделить на следующие категории: в ключевом файле содержится имя пользователя и регистрационный номер (часто зашифро­ванные). Защитный механизм проверяет их на соответствие и, если результат положительный, устанавливает флаг "регистрации" в единицу. Впрочем, имя пользователя может и отсутствовать — тогда проверяется только серийный номер. Разумеется, такие защиты очень уязвимы. Несмотря на то что многие авторы, стремясь осложнить жизнь хакерам даже додумались применить несим­метричные криптоалгоритмы (которые при правильной реализации не дают ни малейшей возможности зашифровать свое имя и per. номер, так как известен ключ только для расшифровки) или использовать цифровые подписи, — все это не спасает. Взломщики идут другим путем; в конечном счете любая функция проверки возвращает результат завершения операции. Вот его-то и инвертируют. Или, скажем, удаляют саму проверку подлинности электронной подписи.

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

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

Парадоксально, но в некоторых защитах (если так можно их назвать) роль ключа выполняет само имя файла! Не знаю, кажется ли это разработчикам оригинальной идеей или они пытаются таким образом сберечь место на дисках пользователей, но факт, что я видел за свою жизнь по крайней мере три таких защиты. Самые примитивные из них просто проверяли наличие файла, скажем с именем 'Reg.key' и, находя его, устанавливали флаг регистрации. Немного более сложные защиты помещали в имя файла инициалы пользователя и контрольную сумму для проверки. Разумеется, все это было зашифровано, чтобы не бросалось в глаза и не поддавалось элементарной подделке.

Рассмотрим простой пример crackll. Для начала попытаемся определить, предусматривает ли программа регистрацию и если да, то какую. Для этого необходимо найти ссылку на строку "UNREGISTRED" и уточнить источник ее вызова. Если это условный переход, то, очевидно, разработчиком предусмотрен некий путь регистрации.

.004011A5 jne .0004011BE

.004011A5 push 00040303В ; "UNREG.
.004011A5 call printf ;MSVCRT.dll
.004011A5 add esp, 004 ;"*"
.004011A5 xor eax,eax
.004011A5 add esp, 000000144 ;" Fl

.004011A5 retn

.004011A5 lea edx, [esp] [00031]
.004011A5 push edx

.004011A5 push 000403020 ; "REG..."
.004011A5 call printf ,-MSVCRT.d

He правда ли, наглядно? Регистрация и в самом деле предусмотрена. Осталось выяснить источник ввода, с которым манипулирует защита. Прокрутим экран немного вверх:

.00401120: 51 push ecx

.00401121: 684C304000 push 00040304C ;

.00401126: FF1500204000 call FindFirstFileA;KERNEL32.dll

Очевидно, что регистрационная информация расположена в каком-то файле. Но в каком? На этот вопрос поможет ответить мониторинг файловых операций. Используем, например, Win95 File Monitor Марка Руссиновича. Его протокол очень интересен:

19 Crackll FindOpen D:KPHCPHCKSRCVCCRACKII*.* SUCCESS .

20 Crackll FindMext D:KPNCPHCKSRCVCCRACKII*.* SUCCESS ..

21 Crackll FindHent D:KPNCPHCKSRCVCCRACKII*.* SUCCESS StdAfx.h

22 Crackll FindNext D:KPHCPHCKSRCVCCRACKII*.* SUCCESS StdAfx.cpp

23 Crackll FindHext D:KPHCPHCKSRCVCCRACKII*.* SUCCESS CRACKll.dsw

24 Crackll FindNext D:KPNCPHCKSRCVCCRACKII*.* SUCCESS CRACKII.cpp

С первого взгляда не совсем ясно, как функционирует защита. Кажется, что это простое чтение оглавления текущего каталога. И нет никакой информации о том, какой файл там должен находиться. Выходит, мониторинг не дал нам никакого результата? Вовсе нет: отрицательный результат тоже результат.

Алгоритм защитного механизма немного прояснился. В текущей директории ищется какой-то файл. Вероятно, защита даже не знает, какой точно, поэтому и не задает маски поиска. Похоже, что она проверяет некоторую дополнительную информацию, например, время создания, модификации или длину. Все эти поля могут выделять ключевой файл среди остальных. Возможно, меня спросят: как же защита может узнать дату, если в протоколе отсутствует функция чтения времени? На самом деле тот, кто хоть немного сталкивался с программированием под DOS/Windows, должен помнить, что FindFirstFile/FindNextFile возвращают не только имя найденного файла, но и целый "букет" его свойств. Заглянем в SDK, чтобы уточнить последнее. В описании FindFirstFile встретится ссылка на следующую структуру:

typedef struct _WIM32_FIND_DATR { // wfd DWORD dwFileRttributes;

filetime ftCreationTime;

FILETIME ftLastAccesaTime;

filetime ftLastwrUeTime;

DWORD nFileSizeHigh;

DWORD nFileSizeLow;

DWORD dwReservedO;

DWORD dwReservedl;

TCHAR cFileName [ MAX_PATH] ;

TCHAR cAlternateFileName [14];

} WIN32_FIND_DATA;

Какие поля использует защита, можно выяснить только с помощью дизассем­блера/отладчика. Попробуем обойтись без IDA и проанализировать алгоритм с помощью одного HIEW. Это совсем не так сложно, как может показаться на первый взгляд.

Начнем изучение логики работы защитного механизма с самого начала. "А где оно, это начало?", — могут меня спросить. В самом деле, ответить не так просто. Однако достоверно известно, что FindFirstFileA лежит в непосредственной близо­сти от начала защиты. Вот с этой точки мы и начнем свое путешествие по коду.

Прокрутим экран немного вверх, пока не встретим следующий код:

.0040110Е: 6850304000 push 000403050 ;

Посмотрим, на что указывает данное смещение:

.00403050: 43 52 41 43.-4B 20 4D 45-20 30 78 31-31 20 OA 00 CRACK ME 0х11 Это же первая выводимая программой строка! Следовательно, мы находимся в непосредственной близости от точки входа в защитный механизм.

.00401113: FF1554204000 call printf ;HSVCRT.dll

.00401119: 83C404 add esp,004 ;

.0040111C: 8D4C2414 lea ecx,[esp] [00014]

Выделяется локальная переменная. По тому, как она будет использована чуть ниже (заслана в стек), можно выяснить по прототипу функции, что это структура WIN32_FIND_DATA.

.00401120: 51 push ecx

Вот эта переменная и засылается в стек.

.00401121: 684С304000 push 00040304С ;

.00403040: 52 45 44 20-43 4? 50 59-20 OA 00 00-2A 2E 2A 00 RED COPY *.*

А это, как видно, маска файлов для поиска.

.00401126: FF1500204000 call FindFirstFiieA;KERNEL32.dll

Нашли первый подходящий файл. С этого момента нужно ожидать вызовов FindNexiFile.

.0040112С: 8B2DOC204000 mov еЬр,[00040200С]

А это что за смещение? Смотрим...

.0040200В: 008021000000 add lean] [000000021] ,al

С первого взгляда непонятно. Но обратим внимание: эта область находится в таблице адресов импорта kernel32.dll. Строго говоря, мы не можем твердо рассчитывать, что 0х2180 действительно указывает на импортируемую функцию. Как было показано в предыдущей главе, загрузчик попросту игнорирует записан­ное в ней значение и вычисляет адреса функций в том порядке, в каком они перечислены в таблице имен. Однако компиляторы, несмотря ни на что, все же правильно заполняют эту структуру, и если над ней не "поработал" разработчик защиты, то ее значение должно соответствовать истине. Попробуем в этом убедиться:

.0040218О: 9D 00 46 69-6Е 64 4В 65-78 74 46 69-6C 654100 Э FindHextFileA

Выглядит правдоподобно. Таким образом, в ebp помещен адрес импортируе­мой функции, и все вызовы call ebp следует читать как call FindNextFileA.

.00401132: 8BF8 mov edi.eax

В eax, как мы помним, был помещен результат выполнения функции FindFir-stFileA. SDK нам скажет, что его ненулевое значение свидетельствует об успехе операции (и наоборот).

.00401134: 33F6 xor esi,esi

.00401136: BA4C2440 mov cl,[espl [00040]

Это, очевидно, первый символ строки cFileName. Для того чтобы понять это, придется заглянуть в файлы определений и узнать размер переменной FILETIME. Далее, исходя из того что вся структура расположена в памяти по адресу [esp+0xl4], нетрудно будет определить, к какому полю принадлежит [esp+0x40l. Однако обратим внимание на такую деталь: все остальные поля, кроме имен, — двойные слова. Выходит, CL не может быть ничем иным, кроме как именем файла,

.0040113Д; 3202 xor dl.dl .0040113С; 84С9 teat cl.cl

В свете вышесказанного смысл этой строки очевиден. Строка завершается нулевым символом, и test с1,с1 проверяет это.

.0040113Е: В8542410 mov [esp] [00010], dl

Объявление еще одной локальной переменной размером в байт. Начальное значение равно нулю, так как перед этим была выполнена операция xor dl,dl.

.00401142; В801000000 mov еая, 000000001 ;

Очевидно, регистровая переменная с начальным значением 1.

.00401147; 741Г je .000401168—--—— (1)

Условный переход выполняется только при достижении конца строки.

.00401149: 8А4С0440 mov с1, [esp] [eax] [00040]

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

.0040114D: OFBED9 movan еbх,сl

.00401150: 81Е303000080 and ebx,080000003 ;

.00401156: 7905 jns .00040115D

.00401158: 4В dec ebx

.00401159: 83CBFC or ebx,-004 ;

.0040115C: 43 inc ebx

Этот очень витиеватый код, возможно, заставит вас призадуматься и окажется увлекательной головоломкой. Это маленькое чудо запрограммировано разработ­чиками MS VC. Действительно, призадумаешься, прежде чем сказать в адрес MicroSoft пару крепких бранных слов. Уж больно этот код хорош. При ближай­шем рассмотрении оказывается, что это аналог функции х mod 4, но насколько же хорошо он оптимизирован! Если это так, то, похоже, защита зачем-то вычисляет хеш-сумму от имени файла. В том, что это хеш, сомнений практически нет. Теперь вспомним, что первый символ имени был пропущен, а сама хеш-сумма вычисляется в байтовой переменной. Не правда ли, это наводит на мысль, что первый символ имени файла и есть контрольная сумма остальных? И весь этот механизм придуман для того, чтобы отличать ключевые файлы от остальных. .0040115D: 02D3 add DL,BL

в данном случае выступает в роли накопителя хеш-суммы.

.0040115F: 40 inc eax

Перемещает индекс на следующий символ.

.00401160: 84С9 test cl,cl

.00401162: 75E5 jne

.000401149-------- (1)

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

.00401164: 88542410 mov [espl [000101 ,dl

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

.00401168: 48 dec eax

Уменьшаем индекс. Очевидно, разбор имени пошел в обратном направлении.

.00401169: 740Е je .000401179-------- (2)

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

.0040116В: 8A54043F mov dl,[esp][eax][0003F]

Загружаем очередной символ строки.

.0040116F: SOF206 xor dl,006 ;

Ксорим его. Правда, еще не понятно зачем.

.00401172: 6854043F mov [esp][eaxJ[0003F],dl

И записываем обратно. Похоже, что это цикл расшифровки строки. Вероятно, в ее имени содержится что-то важное.

.00401176: 48 dec eax

.004011.77; 75F2 jne ,00040116В------- (3)

А это уже глюк компилятора. Неоптимально организованный цикл.

.00401179; OFBE542440 movsx ebx,b,[esp] [00040]

Наконец-то мы обращаемся к первому символу. Заметим, что теперь уже расшифрованному.

.0040117Е; 8В442410 mov eax, [еsр] [00010]

А это вычисленная хеш-сумма. Действительно, похоже, что сейчас их будут сравнивать.

.00401182: 83ЕА41 sub edx,041 ;"Д"

Вычитаем из символа 'А'. Действительно, чтобы имя было читаемым, разра­ботчику защиты пришлось добавить к хеш-сумме этот символ, иначе не было бы попадания в нужный диапазон.

.00401185: 25FFOOOOOO and ean,OOOOOOOFF ;" "

Преобразуем результат в байт.

.0040118А: ЗВС2 cmp eax,edx

Сравниваем значения друг с другом.

.00401180:7505 jne .000401193 ------ (4)

Если два значения идентичны, то флаг esi устанавливается в единицу. (показан ниже) В противном случае он остается равным нулю.

.0040118Е: ВЕ01000000 mov esi,000000001

Вот очень хороший кандидат на глобальный флаг регистрации.

.00401193: 3D4C2414 lea есх, [esp] [00014]

.00401197: 51 push ecx

.00401198:57 push ebi

.00401199: FFD5 call еbр

Вызов FindNextFile

.0040119В: 35CO test eax, eax

.0040119D: 7597 jne .000401136 -------- (5)

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

.004011SF: 5F pop edi

. 004011AO :85F6 test esi,esi

А вот и проверка флажка!

.004011А2: 5Е pop esi

.004011A3: 5D pop ebp

.00401lA4: 5В pop ebx

.004011Д5; 7517 jne .0004011BE-------- (2)

Очевидно, что переход осуществляется только когда он равен единице. В противном случае программа считается незарегистрированной.

.004011А7: 6338304000 push 000403038 ;

Посмотрим, куда он указыавает:

.00403030: 20 25 73 20-Ой 00 00 00-55 4Б 52 45-47 49 53 54 Is UNREGIST

.00403040: 52 45 44 20-43 4F 50 59-20 OA 00 00-2A 2E 2A 00 RED COPY *.*

Точно, это незарегистрированная ветка.

.004011АС: FF1554204000 call printf ;MSVCRT.dll

.004011В2: 83С404 add esp, 004

.004011B5: ЗЗСО хог еах, eax

.004011B7: 81C444010000 add esp,000000144

.00401160: C3 retn

А вот эта ветка получает управление, только когда esi равен единице.

.004011ВЕ: 8D542431 lea edx, [esp] [00031]

Постойте-ка, а ведь edx указывает на расшифрованную строку! Очевидно для того, чтобы вывести ее на экран.

.004011С2: 52 push edx

Точно, prinft выводит ее!

.004011СЗ: 6820304000 push 000403020 ;" @0 "

.00403020: 52 45 47 49-53 54 45 52-45 44 20 46-4F 52 20 за REGISTERED FOR :

Так вот что это за строка — это имя пользователя!

.004011С8: FF1554204000 call printf ;MSVCRT.dil

Защита оказалась довольно любопытной. Она сохраняла регистрационную информацию непосредственно в имени файла. Не самый плохой вариант, особенно учитывая, что длинные имена win95 позволяют вместить до 260 символов, что приблизительно равно размеру среднего ключевого файла. Любопытно, что неко­торые разработчики заполняют такие файлы парой килобайт "мусора" для сбивания с толку. Интересно, насколько же наивным надо быть, чтобы думать, будто такой трюк может кого-то запутать.

Мы разобрали алгоритм защиты. А как ее сломать? Можно, конечно, в строке 0х0401134 установить начальное значение esi в единицу и тогда независимо от наличия ключевого файла окажется зарегистрированной. Но это не лучший путь, так как теперь программа выдает вместо имени регистрации откровенный мусор. Чтобы этого избежать, придется либо отключить вывод строки на экран, заменив его, скажем, на другую строку с нашими инициалами, либо написать собственный генератор. Последнее, конечно, предпочтительнее.

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

.0040118А: ЗВС2 cmp eax,edx

.0040U8C: 7505 jne .000401193-------- (4)

.0040118E: BEOIOOOOOO mov esi, 000000001

.00401193: 3D4C2414 lea ecu, [esp] [00014]

.00401197: 51 push ecx

.00401198: 57 push edi

.00401199: FFD5 call ebp

.0040119B: B5CO test eax.eax

.0040119D: 7597 jne .000401136-------- [5}

.004011BE; 8D542431 lea edx. [esp] [00031]

Подумаем, что будет, если ключевой файл окажется не последним в директо­рии. Тогда edx в строке 0х04011ВЕ будет указывать на имя совсем другого файла, превращенное расшифровкой в мусор, а вовсе не на регистрационную строку. Для чего это сделано? Очевидно, что ключевой файл создается последним в директо­рии и все исправно работает. Но лишь до того момента, пока файлы этого каталога не будут куда-нибудь скопированы так, что ключевой файл окажется не послед­ним в списке. Защита откажет в работе! Не правда ли, оригинальный способ защититься от копирования? Но какому пользователю это понравится? Он хочет получить полноценную копию, не обремененную ограничениями защиты. И мы поможем ему в этом. Но сначала создадим хотя бы один корректный ключевой файл.

Не будем спешить писать свой генератор. Гораздо проще положиться на сам защитный механизм и просто "подсмотреть" правильную строку и контрольную сумму для нашего имени. Создадим файл (или каталог — безразлично, но последнее приятнее) и дадим ему имя 'XKRIS KASPERSKI', где 'X' — зарезерви­рованный символ для будущей контрольной суммы.

Теперь достаточно остановиться в строке 0х0401 ISA и подсмотреть сгенери­рованную защитой строку. Необходимо воспользоваться отладчиком. Но каким? Ведь кроме Soft-Ice в мире немало и других программ. Например, для этой цели подойдет интегрированный отладчик в MS VC. Конечно, по своим возможностям он уступает Soft-Ice, но прост и удобен в управлении, имеет хорошо спроектиро­ванный интерфейс и неплохое ядро, а также великолепную возможность работы с исходными текстами "родных" для него MFC библиотек, которые находятся на компакт-диске, вместе с VC.

Загрузим файл в отладчик и перейдем к строке 0х040118А. Если теперь нажать Ctrl-FlO, то программа будет выполнена только до текущей строки, а затем управление вновь получит отладчик. Другими словами, аналог 'here' в SI и TD. Но как мы узнаем, что строка принадлежит именно нашему файлу, а не какому-нибудь другому? Самым простым способом выяснить, какой файл сейчас обрабатывается, это взглянуть на его имя. Как мы помним, оно расположено в стеке по адресу esp+0x40. Вызовем окно отображения дампа и перетащим мышью эту строку в окно или введем ее вручную.

Какая жалость: строка зашифрована и по ней никак не получается узнать имя. Но не будем спешить. Действительно, шифровка искажает имена файлов до неузнаваемости, но длину строки оставляет неизменной. Ключевой файл с именем 'XKRIS KASPERSKI' будет самым длинным из всех присутствующих в каталоге, что не сможет не броситься нам в глаза.

Строка '"MTOU&MGUVCTUMO' без первого символа — это и есть запись, соответствующая нашему (а точнее, моему) имени.

Переименуем теперь папку 'XKRIS KASPERSKI' в 'XMTOU&MGUVCTUMO' и повторим те же манипуляции с отладчиком, чтобы, во-первых удостовериться, что мы нигде не ошиблись, а во-вторых, узнать контрольную сумму. Не вручную же нам ее вычислять!

Вычисленная контрольная сумма, находящаяся в регистре еах, равна 0х16, тогда ОХ16+'А' (0Х41) == 0х57 = 'W.

Однако вся строка имени файла (включая и первый символ контрольной суммы) шифруется по хог 6. xor 'W',6 == 'Q': таким образом, ключевой файл должен называться 'QMTOL'AMGUVCTUMO'. Переименуем его и запустим программу для проверки.

CRACK MЕ 0х11

REGISTERED FOR: KRIS KASPERSKI

Press any key to continue

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

Понятно, что между 0х040118Е и 0х0401193 необходимо вставить jmp 0х040119F, чтобы при нахождении первого же ключевого файла защита выходила из цикла. Однако нам катастрофически не хватает свободного места. Кажется, что никакими ухищрениями не удастся выгадать хотя бы пару байт свободного пространства. Но как вам нравится такой вариант:

.0040118Е: 46 inc esi

.0040118F: ЕВОЕ jmps .00040119F —-—-- (2)

.00401191: 0000 add [eax],al

.00401193: 8D4C2414 lea ecx,[e5p] [00014]

Значение esi по умолчанию равно нулю, следовательно inc esi можно записать как inc (0) == 1. Эта команда занимает всего один байт, за счет чего в наше распоряжение поступают целых четыре освободившихся байта. Можно сделать SHORT или NEAR прыжок, и при этом, в худшем случае, по крайне мере один байт остается свободным. Интересно, сможет ли читатель найти другие решения?

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

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

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