Здравствуйте Flamer, Вы писали:

F>И вдруг пришло понимание , что _ВСЕ_РАВНО_ без прямой проверки где-либо в коде не обойтись (в итоге — смена двух байт в проге и опаньки). Да, раскидаю я проверку по разным частям проги, сделаю таблицу переходов при промежуточных вычислениях, буду это дело в потоках отдельных пускать, буду множить данные неоднократно, чтобы запутать крекера — но все равно сравнение введенного ключа с эталонным(вычисленным из введенного логина) будет!!!

Ответ примерно такой:
A) эталонного ключа быть не должно (и как следствие — сравнения тоже).
Проще говоря — регистрационный ключ должен просто удовлетворять некоторым условиям
(довольно сложным и неочевидным)

Б) введенный регистрационный ключ использовать для расшифровки программы или ее куска.
Но здесь проблема в том, что мы должны иметь РАЗНЫЕ ключи для разных пользователей
и в то же время эти разные ключи должны расшифровывать одинаковый код.
То есть проблема примерно такая: один Private Key --> много Public Key

Теперь некоторые рекомендации по затруднению трейсинга.
1) Программу ликуй со статической версией CRT библиотеки.
2) после ввода ключ оставляй на стеке.
3) затем, сделай несколько "холостых" malloc'oв (случайное число) и в какой-нибудь
из них положи ключ. free на такие malloc'и вызывать не надо.
4) Адрес ключа не храни в глобальной переменной. Лучше всего — в мембере какого-нибудь
класса. Это относится ко всем данным связанным с защитой.
5) Активно используй (и передавай) ключ при помощи PostMessage()
6) Все security-related действия выполняй в несколько шагов. И от шага к шагу переходи при помощи PostMessage и "как бы случайно".
7) При выявлении факта взлома не выводи никаких сообщений — просто начинай портить
программе данные и хип. В итоге она сдохнет как бы "естественно".
А кракер будет думать что это он криво кракнул.