Как сделать кряк для программы

Если хоть раз мечтал написать crack или keygen

Дня 3 назад заглянул на сайт crackmes.one попробовать силы во взломе защит. Просто наугад взялся за «hitTman’s Kolay One!»: просто по оценке Difficulty: 2.0 и Quality: 4.0. Не примитивно, но и не слишком сложно.

Оказалось, форма ввода пароля с подсказкой: текст кнопки «submit password» после нажатия меняется на число. Если попробовать разные символы пароля, заметно, что для одних и тех же символов число не меняется. Очевидно, пароль подается в хеш-функцию, а ее результат попадает на кнопку. Пробуя пары символов, легко узнать что число на кнопке — сумма чисел для символов пароля.

Логично, что программа сравнивает хеш с эталоном прежде чем выдает сообщение «Try harder!». Ищем в сообщение строках бинарника. Повезло: оно даже не зашифровано и на него единственная ссылка в коде.

Очевидно, рядом же и эталон хеша: 12Eh. Легко проверить: из известных хешей символов составить пароль, например «AaAaAaAaAaAaAaAaAaAaAaAaAaAaAa//» и предложить программе, на что она выдает «Great Job».

Автор просил: «find a Valid pass!», но это оказалось просто, да и верный пароль — не один. Куда интересней написать генератор ключей. Пригодится таблица хеш-значений для всего алфавита. Руками вводить символы пароля и записывать на бумаге их хеши долго и скучно, ведь можно заставить программу саму перебрать алфавит.

У OllyDbg есть коллега — Immunity Debugger, он умеет выполнять скрипты на Python. Отыщем хеш-функцию и заставим ее обработать алфавит.

В обработчике ButtonClick (sub_45385C) прямо перед сравнением хеша с эталоном находится вызов sub_4537C4. Похоже, это и есть хеш-функция: она принимает строку пароля и возвращает хеш в EAX. Привычных push для передачи параметров не видно, вероятно, они передаются через регистры. Если так, то var_C содержит указатель на строку-пароль.

Выше вызов sub_432A4C принимает два аргумента: адрес var_C и еще какой-то указатель по смещению от EBX. Ищем что записано в EBX: выше по коду ButtonClick в него записывается содержимое EAX, но прежде нет записей в EAX, значит там тоже находится параметр процедуры. Заглянув в документацию по Delphi видим, что обработчику ButtonClick передается адрес TObject sender. Можно догадаться, что второй аргумент sub_432A4C — это адрес поля ввода на форме, с которого она читает пароль.

Таких вызовов в ButtonClick два: если запустить программу в отладчике, увидим, что sub_00432A4C действительно записывает указатель на строку-пароль в переменную-аргумент.

Если дальше выполнять ButtonClick пошагово в отладчике, можно заметить, что в переменной на стеке появится и текст кнопки — число. Легко догадаться, что sub_407CE0 — это int to string, [ebx+2FCh] — это указатель на кнопку, а sub_00432A7C — это setButtonText.

Теперь подменим пароль перед хешированием: ставим breakpoint по адресу 0x004538B3 — прямо перед вызовом hashFn она же sub_4537C4. Вводим пароль 1234 и средствами отладчика отредактируем содержимое памяти var_C — введем букву A и символ конца строки \0. Сейчас хеш-функция должна вернуть в EAX значение 0x13 (19). Шагаем вперед и. Первая неудача: в EAX — 0x56 (86). Долго думал, пробовал, грешил на Юникод или еще какие скрытые хитрости программы. Оказалось, программа где-то запоминает длину строки и Вместо хеша «A\0» вычисляет хеш «A\034». Хеш \0 равен 0, поэтому если ввести пароль A34 получим хеш 0x56. Значит введем один символ пароля и повторим правки в отладчике — теперь получилось!

Теперь нужно повторить действия для всего алфавита:

остановиться перед вызовом hashFn
сменить символ пароля на следующий по алфавиту
остановиться после вызова hashFn и запомнить хеш символа
вернуть программу к вызову hashFn

Вот скрипт на Python, который это сделает:

import immlib imm = immlib.Debugger() def main(args): table = <> # break после hashFn imm.setBreakpoint(0x004538B8) mem_password = imm.getRegs()["EAX"] # цикл по печатным символам ASCII for c in range(0x20, 0x7F): b = bytearray() b.append(c) b.append(b'\x00') if imm.writeMemory(mem_password, bytes(b)) '".format(chr(c))) return "ERROR" imm.run() # запоминаем хеш table[c] = imm.getRegs()["EAX"] # Возвращаемся к вызову hashFn imm.setReg("EIP", 0x004538B3) # снова передали указатель на строку-пароль в EAX imm.setReg("EAX", mem_password) imm.run() # запишем результаты в файл with open("C:/a.csv", "w") as out: for c in table: out.write(" ".format(chr(c))) out.write("0x\n".format(table[c])) return "Kolay done"

Как вариант можно вводить пароль 1234 и вызывать imm.writeLong(mem_password, с), чтобы записать байт символа и три нуля следом.

Алфавитом овладели, правило хеширования пароля знаем. Как генерировать пароли?

Наивное решение: перебор всех ключей и проверка каждого. Вот код, что найдет все ключи длины 2:

const string alphabet = //. const unordered_map weights = //. const int N = 2; const int S = 0x12E; string key; void generateKeys(ostream& out) < if (N > else < for (char c : alphabet) < const int w = weights.at(c); if (sum + w > > >

Работает, но захлебывается уже на ключах длиной больше 5.

От перестановки мест слагаемых сумма не меняется, так что код можно улучшить: пусть он перебирает сочетания.

bool nextCombination(vector& nums, int n) < const int k = nums.size(); for (int i = k - 1; 0 return true; > > return false; > bool TestKey(const vector& nums) < int sum = 0; for (int i : nums) < sum += weights.at(alphabet[i]); >return S == sum; > string MakeKey(const vector& nums) < string key; for (int i : nums) < key.push_back(alphabet[i]); >return key; > void generateKeys(ostream& out) < vectornums(N); for (int i = 0; i < N; ++i) < nums[i] = i; >do < if (TestKey(nums)) < ++cnt; out > while (nextCombination(nums, alphabet.size())); >

Теперь можно дождаться, пока он найдет все сочетания длины 7.

А если хочется ключи длиннее? Можно останавливаться на первом найденном ключе — авось повезет. Время, когда перебор наткнется на первый верный ключ непредсказуемо. Я так и не дождался, пока программа найдет первый верный ключ длины 20.

Можно ли найти лучшее решение, чем перебор всех сочетаний? Например, если известен один верный ключ, как перейти к следующему?
vx -> ?

Аналогия: чтобы получить следующее число, добавляем 1 к младшему разряду и, если необходимо, выполняем перенос:
18, 19, 20, .

Можно заменять символы пароля так, чтобы его хеш не менялся. Беда в том, что для ‘x’ нет равноценной замены.

0x01 001: %)+/5;=CGIOSYaegkmq 0x08 008: 1 0x0c 00c: y 0x0d 00d: # 0x0f 00f: ! 0x11 011: '7 0x13 013: AM 0x14 014: " 0x15 015: 3[ 0x16 016: & 0x17 017: 9U 0x19 019: _w 0x1a 01a: . 0x1b 01b: E 0x1d 01d: s 0x1f 01f: > 0x20 020: : 0x21 021: -W 0x22 022: > 0x23 023: ] 0x28 028: ,JQ 0x29 029: ?o 0x2b 02b: 2 0x2c 02c: R 0x2d 02d: < 0x2e 02e: 4V 0x31 031: K 0x32 032: (^ 0x36 036: * 0x37 037: $ 0x38 038: j 0x39 039: c 0x3a 03a: D 0x3e 03e: v 0x3f 03f: @ 0x40 040: 8Lz 0x41 041: u 0x42 042: 6 0x49 049: b 0x4a 04a: F 0x4c 04c: 0\ 0x4e 04e: B 0x57 057: i 0x5a 05a: N 0x5c 05c: X 0x5e 05e: t 0x64 064: | 0x6a 06a: Phn 0x6c 06c: < 0x72 072: f 0x75 075: d 0x7b 07b: H 0x7e 07e: r 0x88 088: p 0x8c 08c: T 0x90 090: Z 0x9c 09c: ` 0xac 0ac: l 0xba 0ba: ~ 0xf0 0f0: x

Возьмем другой ключ из 3х символов: Zr%. Заменяя % можно пройтись по нескольким ключам:
Zr% -> Zr) -> Zr+ -> . -> Zrq
Попробуем найти замену для rq. Пришлось обойти все пары символов алфавита и вычислить их хеши.
Zrq -> Zt- -> ZtW -> Zuv

Что делать дальше - непонятно. Сменить Z на другой символ? У Z нет равноценных замен, придется перебором снова найти первый подходящий ключ.

Так и не придумал алгоритм перехода от одного известного ключа к следующему: если есть идеи, пишите в комментариях.

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

// Длина ключа N - степень двойки void generateKeys(ostream& out) < for (int n = 1; n < N; n next_weights; for (auto i = weights.begin(); i != weights.end(); ++i) < for (auto j = next(i); j != weights.end(); ++j) < const string& s1 = i->first; int w1 = i->second; const string& s2 = j->first; int w2 = j->second; int len = s1.length() + s2.length(); if (len == n * 2) < string s3(len, 0); int w3 = w1 + w2; merge(s1.begin(), s1.end(), s2.begin(), s2.end(), s3.begin()); if (len < N) < next_weights[s3] = w3; >if (N == len && S == w3) < out > > > weights.swap(next_weights); > >

Как сделать кряк для программы

Взлом программного обеспечения

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

Крэк (также искажённое кряк и, крайне редко, крак) (англ. crack) - программа, позволяющая осуществить взлом программного обеспечения. Как правило, крэк пригоден для массового использования. По сути, крэк является воплощением одного из видов взлома, зачастую, это обычный патч. Для слова крэк используются следующие эвфемизмы: лекарство, таблетка от жадности,аспирин /

Крэкер (также искажённое крякер) (англ. cracker) - человек, который занимается созданием крэков.

Взломщик - это человек, который взламывает программу при помощи уже готового крэка или без такового.

Виды взлома

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

Ввод серийного номера (регистрационного кода) (жарг. серийник) (англ. serial number, S/n) - взлом программы посредством введения правильного регистрационного ключа (или фразы), полученного нелегальным способом. Ключ может генерироваться на основе какой-либо информации (имени владельца ПО, характеристик аппаратной части компьютера, и т. п.), либо иметь фиксированное значение. Для генерации регистрационного ключа используется тот же алгоритм, что и в программе.

Регистрационный код может распространяться в ключевом файле (файле лицензии) (англ. keyfile), который обычно помещается в каталог с установленной программой.

Для массового взлома, зачастую, создаётся (и в дальнейшем используется) генератор ключей (жарг. кейген) (англ. keygen сокр. от key generator) - программа для генерации регистрационных ключей (см. выше). Данный вид взлома наиболее востребован (особенно, когда программа часто обновляется или рег. ключ генерируется на основе какой-то информации (см. выше)) и поэтому наиболее ценится. Как правило, требует бо?льшей квалификации взломщика по сравнению с другими видами взлома, но не всегда.

Использование загрузчика (жарг. лоадер) (англ. loader) - способ обходить некоторые виды защиты ПО, заключающиеся в использовании внешних (навесных) систем защиты. Состоит в изменении определённых фрагментов программы в оперативной памяти сразу после её загрузки в эту память, но перед её запуском (то есть перед выполнением кода в точке входа).

Применение (бинарного) патча (часто жарг. крэк или кряк от англ. crack) (англ. byte patch) - способ, похожий на «загрузчик», но модификация производится статически в файлах программы. Как правило, это один из самых простых и быстрых способов взлома ПО.

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

Использование эмулятора ключа (англ. key emulator) - способ используется для обмана защит, построенных на использовании в качестве защиты электронного ключа (как правило, подключаемого к LPT или USB порту компьютера). Заключается в снятии дампа внутренней памяти ключа. Файл с содержимым этой памяти подаётся на вход специальной программе - эмулятору, которая подключает свой драйвер-фильтр в стек драйверов и обманывает защищённую программу, эмулируя работу с аппаратным ключом. В случаях наличия в программе обращений к ключу для аппаратного шифрования участка памяти этот метод используется в связке с методом Бинарный патч. Современные аппаратные ключи настолько сложны, что, при грамотном их применении, возможно создать защиту, фактически не поддающуюся взлому.

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

Этот список не является исчерпывающим, а лишь обозначает наиболее встречаемые способы взлома.

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

Принципы взлома

Как правило, в основе работы крэкера лежит исследование ассемблерного кода, полученного из машинных инструкций с помощью специально предназначенной для этого программы-дизассемблера. В зависимости от выбранного способа взлома, результат исследования может использоваться, например, для построения генератора ключей или для внесения необходимых изменений в исполняемый файл. Последний способ в большинстве случаев наиболее лёгкий, так как не требует изучения алгоритма проверки правильности ключа: зачастую взлом сводится к поиску проверки нескольких условий (наподобии «ВведённоеЧисло равно ЭталонномуЧислу?») и замене такого условия на безусловный переход (goto, jmp), или, реже, на противоположное (то есть для данного примера на «ВведённоеЧисло не равно ЭталонномуЧислу?»).

Кроме того, внесение изменений в исполняемый файл (патч) может производиться с целью отключения нежелательных действий со стороны программы (например, напоминание о необходимости регистрации), сокращения функциональности программы. В этих случаях, часто, соответствующие команды процессору заменяются на байты со значением 90h (в шестнадцатеричной системе счисления), что соответствует ассемблерной команде nop (No Operation), то есть «пустой команде», не выполняющей никаких действий. Если таких команд много, то применяется безусловный переход (перепрыгивание ненужного кода). Возможно также расширение возможностей программы написанием дополнительного кода, но, как правило, это слишком трудоёмкий процесс, не оправдывающий временных затрат.

Между тем, патч возможен, как правило, в том случае, когда исполняемый файл программы не защищён специальными «пакерами» и «протекторами» - программами, скрывающими реальный код исполняемого файла. Для последнего типа программ зачастую используется самая интеллектуальная часть обратной разработки (англ. reverse engineering) - исследование кода программы при помощи отладчика и создание генератора ключей, но возможны и другие решения, например, создание загрузчика (см. выше).

Правовые аспекты деятельности

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

Глава 28 Уголовного кодекса РФ устанавливает наказания за компьютерные преступления. В соответствии со ст. 272 за крекинг можно получить лишение свободы до 2 лет. При предварительном сговоре группы лиц - до 5 лет. В России практика наказаний за взлом программного обеспечения существует в очень сыром и пока в теоретическом виде. Это вызвано тем что понятие «интеллектуальная собственность» пока ещё точно не определено российским законодательством. Также сам факт крекерства очень тяжело доказать, поскольку тот же антивирус Касперского вносит изменения в файлы при их лечении от вирусов и его действия так же можно классифицировать по ст. 272 УК РФ. Из известных в нашей стране случаев наказания за компьютерные преступления можно выделить пожалуй лишь создание вредоносных программ. Поэтому многие люди в том числе и правообладатели пытаются представить крекеров как создателей вирусов, но на самом деле это в корне неверно.

Как взломать программу, изменив файлы DLL

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

Команда контент-менеджеров wikiHow тщательно следит за работой редакторов, чтобы гарантировать соответствие каждой статьи нашим высоким стандартам качества.

Количество просмотров этой статьи: 29 295.

В этой статье:

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

Научитесь программировать на языке ассемблера и работать с шестнадцатиричным кодом. Для взлома большинства пробных версий программ необходимо хорошо знать язык ассемблера, который является языком программирования низкого уровня. [1] X Источник информации Он является производным от машинного языка, и каждая разновидность языка ассемблера будет зависеть от типа используемого компьютера. Большинство языков ассемблера работают с двоичными и шестнадцатеричными кодами.

Установите дизассемблер. Чтобы изучить и изменить файлы DLL, вам понадобится несколько инструментов, включая дизассемблер. Отличным выбором будет IDA Pro — дизассемблер и отладчик. Его бесплатная версия доступна на https://www.hex-rays.com/products/ida/support/download_freeware, хотя ее возможности существенно ограничены по сравнению с Pro-версией. Также можно попробовать dotPeek — поддерживающий DLL декомпилятор, который транслирует код ассемблера .NET в C#. [2] X Источник информации Еще один вариант — OllyDBG, позволяющий бесплатно открывать DLL-файлы.

Откройте программу, которую вы хотите взломать с помощью дизассемблера. Процесс будет немного разным в зависимости от того, какой дизассемблер вы используете. Вы увидите, какие файлы DLL загружает программа. Используйте отладчик, чтобы определить, какие функции вызывают файлы DLL. [3] X Источник информации

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

Установите контрольную точку на счетчике. Когда вы выделите функцию счетчика, используйте дизассемблер, чтобы восстановить код в этой контрольной точке. Это позволит изучить код, который используется во время вызова функции счетчика.

Измените код счетчика. Теперь, когда вы нашли код для функции счетчика, вы сможете изменить его таким образом, чтобы счетчик никогда не достиг финальной точки отсчета. Например, можно сделать так, чтобы счетчик не смог дойти до конечной точки или перепрыгивал ее.

Снова скомпилируйте взломанную программу. После использования дизассемблера и редактирования вам нужно скомпилировать новую версию программы, чтобы ваши изменения распространились на файлы DLL и другие зависимости. [4] X Источник информации

Взлом программ, или Крэкинг

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

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

Прежде всего рассмотрим понятие «крэк» (крак, кряк), представляющее собой кальку с английского слова crack, которое имеет множество значений, но ближе всего к теме нашей статьи значения «решать трудную задачу» и «раскалываться, давать трещину, ломаться». Впоследствии в Интернете так стали называть программы для взлома защиты, а крэкингом — сам процесс взлома.

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

Дзен-крэкинг

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

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

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

Представим, что есть программа, которая выполняет некое действие. К примеру, она отказывается запускаться по истечении 15 дней с момента ее первого запуска. При этом появляется окошко с предупреждением — это и есть первое наблюдение. Если при переводе системной даты назад программа все равно не запускается, из этого следует еще один вывод: программа каким-то образом проверяет текущую дату, но при этом не основывается на показаниях часов операционной системы. Можно предположить, что программа либо сделала пометку о том, что запуск больше невозможен, либо все-таки определяет время другим способом. Здесь есть два пути: представить себя на месте программиста и подумать, какие варианты определения времени он мог использовать, или искать в системном реестре либо в исполняемых файлах ссылку на запрет запуска. Однако сначала необходимо понаблюдать за производимыми программой действиями, которые являются признаками той или иной реализации защиты. Если программа не просто «задумывается» при запуске, но еще и шуршит винчестером, вероятность того, что она проверяет файлы на дату/время создания, увеличивается. В противном случае необходимо уже непосредственно разбирать, какие условные переходы, связанные с этим окном, происходят, и к каким функциям в это время происходит обращение.

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

Наиболее подходящими для крэкеров дырами являются глобальные переменные, в которых хранятся сведения о состоянии программы («зарегистрирована — не зарегистрирована»); функции, возвращающие критичное для защиты значение (число запусков или дней до истечения испытательного срока, результат проверки серийного номера на правильность), и процедуры, выводящие сообщение об успешной или неуспешной попытке регистрации, а также об истечении триального срока программы. В некоторых случаях изменение 0 на 1 делает программу зарегистрированной и полностью работоспособной — конечно, необходимо найти эту прореху, что и является главной задачей крэкера. Поэтому поиск констант (количество дней) и их изменение — наиболее оптимальное решение, поскольку в этом случае действует правило минимального вмешательства в сам код программы.

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

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

Описанные выше приемы взлома применяются в большинстве случаев, однако в некоторых ситуациях защита встроена в установщик, которым инсталлируется программа, так как большая часть программ поставляется в виде инсталляционного пакета. В нем, кроме файлов, которые требуется установить на машину пользователя, содержится сценарий инсталляции, то есть некий скрипт, описывающий алгоритм инсталляции. Поскольку написание собственного инсталлятора — дело трудоемкое, для большинства небольших программ используется один из готовых продуктов. Инсталляционный скрипт описывает, в каком режиме устанавливается тот или иной файл (добавление, замена, замена с предварительной проверкой версии и т.п.), какие данные необходимо внести в реестр или в файлы конфигурации, какие программы запускаются до, в процессе и после инсталляции, а также многое другое. В это «многое другое» могут входить и такие интересные вещи, как проверка серийных номеров, создание записей в реестре, а также распаковка и запуск программ. Поэтому защиту от запуска незарегистрированной или триальной со сроком действия версии следует искать именно в инсталляционном файле. При этом реализация защиты может быть совершенно различной — от простых меток в реестре до создания точки отсчета времени от системной библиотеки самой операционной системы. В качестве метки, по которой программа будет проверять ограничения по времени или по числу запусков, может использоваться какой-либо файл, создаваемый в процессе инсталляции, особенно если этот файл спрятан где-нибудь глубоко в системных директориях, но при этом активно применяется программой. Самый надежный способ нахождения подобных функций защиты — декомпиляция инсталляционного файла и последующий разбор его по байту. Однако эта операция требует времени и опыта. Зато в случае, если инсталляционная программа произведена сторонним разработчиком, можно написать универсальный патч для обхода защиты всех программ, которые используют эту версию инсталляционного пакета. Исходя из метода наименьшего сопротивления применяется прием мониторинга системы в процессе инсталляции. В этом случае, не углубляясь в код инсталляционного файла, можно обнаружить запросы к файлам, а также создание ключей в реестре. Подобные утилиты мониторинга за ОС позволяют делать слепки системы на разных этапах ее инсталляции, а путем сравнивания исходных значений с полученными можно выяснить результат действия инсталляционного пакета. Стоит отметить, что далеко не все инсталляционные пакеты отличаются широкими возможностями, очень часто встречается простое решение — запуск либо самой программы после инсталляции, либо дополнительной программы на фоне процессов, которая и создает защиту.

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

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

Вспомогательные программы

Инструменты — это одно из главных орудий крэкера, без них он как без рук. Но сами по себе такие инструменты не более чем программа, главное — уметь их использовать. Будет ли полезен лучший в мире отладчик, если человек не знает, что означают те цифры и буквы, которые появляются на его экране? Поэтому, прежде чем задать программе вопрос, необходимо быть уверенным, что вы сможете понять ответ. Тем не менее от качества инструментов во многом зависит скорость и эффективность действий крэкера. Инструментарий должен регулярно обновляться, поскольку программы тоже постоянно совершенствуются, наращивают мощность, обрастают новыми полезными и бесполезными функциями, к тому же их защита и реализация тоже постоянно улучшаются. Инструментов для крэкинга существует великое множество, главное — отбирать из них самые эффективные, быстрые и удобные. Некоторые крэкеры возражают против использования готовых решений, поскольку это чрезмерно упрощает процесс взлома и «некрасиво». Но, поскольку в крэкинге необходим конечный результат, а не красота, большинство пользуется всеми подручными средствами, дописывая уже готовые программы для собственных нужд.

Существует несколько типов программ, активно применяемых для взлома защиты программы.

Отладчики и дизассемблеры

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

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

Декомпиляторы и узкоспециализированные отладчики

С ростом мощности ЭВМ широкое распространение получили компиляторы, создающие не «чистый» машинный код, а некий набор условных инструкций, который выполняется при помощи интерпретатора. Интерпретатор может поставляться отдельно или быть прикрепленным к самой программе. Интерпретаторами являются практически все инсталляторы (в их основе лежит интерпретатор инсталляционного скрипта, хотя процесс создания такого скрипта может быть скрыт визуальными средствами). Создавать код могут также компилирующие языки, однако его прямой анализ весьма затруднителен. Для анализа таких программ используются специализированные утилиты, переводящие код, понятный лишь интерпретатору, в форму, более удобную для понимания человеком. Некоторые декомпиляторы также могут извлекать информацию об элементах интерфейса, созданных визуальными средствами. В любом случае не следует ожидать от декомпиляторов восстановления исходного текста программы; если декомпилированная программа успешно компилируется и сохраняет работоспособность — это исключение, а не правило.

Распаковщики и утилиты для дампинга процессов

Дизассемблировать запакованную или зашифрованную программу невозможно, но если очень хочется получить хоть какой-то листинг, то можно попытаться извлечь из памяти компьютера дамп программы в момент ее работы. Этот дамп уже можно более или менее успешно дизассемблировать. Более того, на основе дампа можно воссоздать исполняемый файл программы, причем этот файл будет успешно загружаться, запускаться и работать. Именно на этом принципе и основана работа большинства современных распаковщиков: подопытная программа запускается под управлением распаковщика; распаковщик ждет некоторого события, свидетельствующего о том, что программа полностью распаковалась, тут же «замораживает» программу и сбрасывает ее дамп на диск. Защитные системы нередко пытаются противодействовать получению работоспособного дампа при помощи манипуляций с сегментами и таблицами импорта-экспорта. В этих случаях приходится использовать PE-реконструкторы, то есть утилиты, обнаруживающие в дампе некорректные ссылки на функции и пытающиеся их восстановить. Многие продвинутые дамперы и распаковщики имеют встроенные средства восстановления секций импорта.

Утилиты анализа файлов

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

Шестнадцатеричные редакторы и редакторы ресурсов

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

API-шпионы и другие утилиты мониторинга

Зачастую бывает нужно узнать, какие именно действия выполняет та или иная программа, откуда она читает и куда записывает данные, какие стандартные функции и с какими параметрами вызывает. Получить эти сведения помогают утилиты мониторинга. Они делятся на две большие группы: отслеживающие сам факт возникновения каких-либо событий и позволяющие выявить один или несколько специфических типов изменений, произошедших в системе за некий промежуток времени. К первой группе относятся всевозможные API-шпионы, перехватывающие вызовы системных (а более продвинутые — и не только системных) функций, хорошо известные утилиты Reg, File, PortMon и т.д., перехватчики системных сообщений и многие другие. Эти утилиты, как правило, предоставляют подробную информацию об отслеживаемых событиях, но генерируют весьма объемные и неудобные для анализа логи, если отслеживаемые события происходят довольно часто. Вторая группа представлена всевозможными программами, создающими снимки реестра, жесткого диска, системных файлов и т.п. Эти программы позволяют сравнить состояние компьютера до и после некоего события, построить список его различий в этих состояниях и на основе этого списка сделать определенные выводы. Основная проблема при работе с такими утилитами хорошо описывается афоризмом: «После — не значит вследствие».

Прочие утилиты

Существует также огромное количество утилит, не вписывающихся в рассмотренные выше категории или попадающих в несколько категорий сразу. Поскольку крэкинг — занятие весьма многогранное, столь же многогранны используемые для него инструменты. Более того, некоторые утилиты, которые могут быть полезны для крэкера, создавались для совершенно иных целей (хорошим примером может служить программа GameWizard32, которая, вообще-то, предназначена для того, чтобы мухлевать в компьютерных играх, но оказалась полезной при вскрытии программы с ограничением на максимальное число вводимых записей). Как невозможно объять необъятное, так и нельзя описать все программы, которые применяются для крэкинга.

Заключение

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

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

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

ПК и комплектующие

Настольные ПК и моноблоки
Портативные ПК
Серверы
Материнские платы
Корпуса
Блоки питания
Оперативная память
Процессоры
Графические адаптеры
Жесткие диски и SSD
Оптические приводы и носители
Звуковые карты
ТВ-тюнеры
Контроллеры
Системы охлаждения ПК
Моддинг
Аксессуары для ноутбуков

Принтеры, сканеры, МФУ
Мониторы и проекторы
Устройства ввода
Внешние накопители
Акустические системы, гарнитуры, наушники
ИБП
Веб-камеры
KVM-оборудование

Сетевые медиаплееры
HTPC и мини-компьютеры
ТВ и системы домашнего кинотеатра
Технология DLNA
Средства управления домашней техникой

Планшеты
Смартфоны
Портативные накопители
Электронные ридеры
Портативные медиаплееры
GPS-навигаторы и трекеры
Носимые гаджеты
Автомобильные информационно-развлекательные системы
Зарядные устройства
Аксессуары для мобильных устройств

Цифровые фотоаппараты и оптика
Видеокамеры
Фотоаксессуары
Обработка фотографий
Монтаж видео

Операционные системы
Средства разработки
Офисные программы
Средства тестирования, мониторинга и диагностики
Полезные утилиты
Графические редакторы
Средства 3D-моделирования

Веб-браузеры
Поисковые системы
Социальные сети
«Облачные» сервисы
Сервисы для обмена сообщениями и конференц-связи
Разработка веб-сайтов
Мобильный интернет
Полезные инструменты

Средства защиты от вредоносного ПО
Средства управления доступом
Защита данных

Проводные сети
Беспроводные сети
Сетевая инфраструктура
Сотовая связь
IP-телефония
NAS-накопители
Средства управления сетями
Средства удаленного доступа

Системная интеграция
Проекты в области образования
Электронный документооборот
«Облачные» сервисы для бизнеса
Технологии виртуализации

1999	1	2	3	4	5	6	7	8	9	10	11	12
2000	1	2	3	4	5	6	7	8	9	10	11	12
2001	1	2	3	4	5	6	7	8	9	10	11	12
2002	1	2	3	4	5	6	7	8	9	10	11	12
2003	1	2	3	4	5	6	7	8	9	10	11	12
2004	1	2	3	4	5	6	7	8	9	10	11	12
2005	1	2	3	4	5	6	7	8	9	10	11	12
2006	1	2	3	4	5	6	7	8	9	10	11	12
2007	1	2	3	4	5	6	7	8	9	10	11	12
2008	1	2	3	4	5	6	7	8	9	10	11	12
2009	1	2	3	4	5	6	7	8	9	10	11	12
2010	1	2	3	4	5	6	7	8	9	10	11	12
2011	1	2	3	4	5	6	7	8	9	10	11	12
2012	1	2	3	4	5	6	7	8	9	10	11	12
2013	1	2	3	4	5	6	7	8	9	10	11	12