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

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

Эти процессы взаимосвязаны: отладчик может содержать в себе дизассемблер, а возможность трассировки в отладчике присутствует в каждой среде программирования.

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

Методы активной защиты:
- поиск кода программы, который выполняется часто и с примерно одинаковым временем. Поставить проверку этого времени, и если время выполнения кода больше, то программу ломают в отладчике - принудительно закрыть программу;
- установка высокочастотного таймера (или нескольких), делающих бессмысленную работу (желательно, с большими объемами данных). Бессмысленная работа должна быть хаотичной: то период таймера изменится, то Randomize + Rnd сработают, то куча информации откуда-нибудь читается и записывается. В итоге взломщику будет очень сложно отличить полезные данные от мусора, т.к. мусор генерируется хаотично;
- обеспечение одновременного выполнения мусорных таймеров и полезных функций. Это смешает мусор с полезной информацией;
- блокировка отладочных прерываний процессора;
- блокировка прерываний с клавиатуры.

Методы пассивной защиты:
- упаковка выходного EXE-файла (а лучше - его частей) каким-нибудь упаковщиком (а лучше - его частной модификацией), чем сильнее сжатие - тем лучше;
- составление EXE-файла таким образом, что он полностью автономен и не использует внешних библиотек (кроме API, конечно);
- увеличение объема программы, наполняя ее объемным мусорным исходным кодом (желательно, чтобы он ещё и выполнился пару раз);
- компиляция в P-Code, а не в Native Code наоборот. P-Code легче декомпилируется, но сложнее отлаживается. Native Code легче отлаживается, но тяжелее декомпилируется;
- больше глобальных переменных внутри важных функций. Компилятор их в регистры не заносит (правда, код медленнее работает). Взломщику постоянно придется думать, что это какие-то важные переменные, ещё кому-то нужные, - процесс взлома идёт труднее.

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

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

Дополнительные пассивные методы защиты:
- использование программ обфускации (запутывание кода программы, скрытие имен переменных), закрывает некоторые дыры при декомпиляции программы из P-Code. Применять ее нужно как к выходному файлу, так и к упакованному.