Всё просто, на самом деле.

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

То есть надо привязывть ключ к параметрам машины.

Привязка к машине обходится двумя способами.

1. С помощью т.н. trainers — оригинальная прога запускается в качестве child process с перехваченными системными вызовами. Когда она читает, скажем, серийник мамы, то ей подсовывается фиксированный ответ, под который куплен (или стырен) реальный ключ. Все проверки в проге проходят и превед.

2. С помощью патчей, которые выключают проверки.

Первый пункт counter'ится привязыванием ключей к десятку или больше системный параметров. Бонусом идет их считывание больше чем одним способом, например, через голые syscalls.

Второй пункт — это то, что затыкается протекторами. Протекторы в большинстве случаев — это major overkill. Такая элементарная вещь, как проверка целостости бинарника через N минут после запуска с последующим shutdown через еще M минут, отбивает охоту ковыряться в программе у большинства "хакеров". Если таких проверок несколько (десятки), равномерно распределенные по коду и времени, то выцепить их все будет сложно. Если часть этих проверок отключать, когда процесс бежит под дебаггером, и насыпать местами разных какашек типа ThreadHideFromDebugger, то процесс ковыряния в бинарнике становится совсем не интересным. Его по-прежнему можно вычистить и сломать, но это требует много времени, которое особо никто на очередной генератор инвойсов тратить не будет.

Задача защиты — это сделать процесс её снятия (экономически) не выгодным. Шифровалки-защищалки — это только один из вариантов.

Всё просто, на самом деле.

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

То есть надо привязывть ключи к параметрам машины.

Привязка к машине обходится двумя способами.

1. С помощью т.н. trainers — оригинальная прога запускается в качестве child process с перехваченными системными вызовами. Когда она читает, скажем, серийник мамы, то ей подсовывается фиксированный ответ, под который куплен (или стырен) реальный ключ. Все проверки в проге проходят и превед.

2. С помощью патчей, которые выключают проверки.

Первый пункт counter'ится привязыванием ключей к десятку или больше системных параметров. Бонусом идет их считывание больше чем одним способом, например, через голые syscalls.

Второй пункт — это то, что затыкается протекторами. Протекторы в большинстве случаев — это major overkill. Такая элементарная вещь, как проверка целостости бинарника через N минут после запуска с последующим shutdown через еще M минут, отбивает охоту ковыряться в программе у большинства "хакеров". Если таких проверок несколько (десятки), равномерно распределенные по коду и времени, то выцепить их все будет сложно. Если часть этих проверок отключать, когда процесс бежит под дебаггером, и насыпать местами разных какашек типа ThreadHideFromDebugger, то процесс ковыряния в бинарнике становится совсем не интересным. Его по-прежнему можно вычистить и сломать, но это требует много времени, которое особо никто на очередной генератор инвойсов тратить не будет.

Задача защиты — это сделать процесс её снятия (экономически) не выгодным. Шифровалки-защищалки — это только один из вариантов.