Хотя я и сам считаю себя новичком, но, если хочешь, могу дать некоторые рекомендации.
   Можешь для начала почитать статьи с http://www.wasm.ru/wault в разделе "Исследование программ", особенно "Теоретические основы крэкинга" и "Введение в крэкинг с нуля, используя OllyDbg". А вообще, лучший способ обучения в этом деле - практика.
   В каждом конкретном случае нужен свой подход. Например, в программах, написанных на Delphi (вроде DelinvFile), можно начать с анализа кода в IDR и создания map-файла. Это на порядок упрощает задачу исследования asm-кода. Из обработчика кнопки регистрации уже не трудно выйти на основную функцию проверки. А дальше собственно и начинается основная часть работы.
   Если в процессе анализа встречается функция, которая вызывается из множества мест, то зачастую её можно не разбирать, а определить её предназначение по тому, какие она параметры принимает и какой возвращает результат. Если её действие по-прежнему непонятно, то, возможно, это какая-то несущественная функция и её можно смело пропустить. Стоит обращать внимание на функции, которые вызываются всего из 1-2 мест, особенно, если им передаются рег. данные. По мере накопления опыта ненужные функции довольно быстро отсеиваются.
   Не стоит зацикливаться на трудных местах. Смотри на код в целом, старайся создать общую картину, понять логику, которой руководствовались разработчики. В любом случае, анализ всегда проще, чем синтез. Разобрать чужую защиту гораздо легче, чем изобрести свою.
   Помимо настроя и терпения, желательно также иметь опыт программирования, без этого, по крайней мере, не получится сделать сам кейген. К тому же, это помогает выделять в asm-коде стандартные структуры (if, for, case и пр.). Для более трудных защит придётся изучить криптографические алгоритмы: CRC, хеш-функции (MD5, SHA), симметричное (см. Панасенко С.П. - Алгоритмы шифрования) и ассиметричное (RSA, ECC) шифрование, цифровые подписи (DSA, ECDSA) и пр. В особенно тяжёлых случаях защита может быть многоуровневой, проверки запускаются только при случайных событиях, есть шифрованные и обфусцированные куски кода, часть верификации вынесена в VM, модифицированы стандартные криптогр. алгоритмы (как, например, модифицированные MD5 и RSA в Total Commander) и т.д. Здесь всё ограничено лишь изобретательностью программиста.
   Для меня мотивацией поначалу было исследование программ, которые я использую в повседневной работе. Наличие к некоторым из них в сети уже готовых кейгенов, ещё больше подталкивало к их анализу, т.к. в этом случае была уверенность, что такая задача заведомо разрешима. К тому же, далеко не всегда готовый кейген даёт возможность тонкой настройки лицензии, что также является дополнительным стимулом к его улучшению.
   В общем, тут главное начать, и не бойся трудностей, которые непременно встретятся в начале пути.

   В качестве примера, приведу вкратце разбор защиты DelinvFile:
1. После анализа в IDR выходим на функцию TDelinvRegDlg.RegItBtnClick (00614F4C)
2. В ней сначала получается введённый ключ (00614F75), затем он переводится в верхний регистр (00614F80), далее из него удаляются все символы кроме цифр и загл. лат. букв (00614F8B). Потом идёт замена некот. символов (00614FA1: 'L', 'I' -> '1', 'O' -> '0').
3. Далее идёт важная функция 006148E0, т.к. ей передаётся преобразов. ключ. Заходим в неё.
4. В ней единственный интересующий нас вызов: 006147CC. Это и есть основная функция проверки.
5. Далее формируется ключ для блочного шифра:
	00671B25 - указатель на встроенный массив из 16 байт
	005F26A0 - вычисляет CRC от строки 'DELINVF' (Res = $08A0E3E6)
	005F27B4 - xor-ит побайтово полученный CRC и массив. На выходе ключ для бл. шифра:
		9E AD E7 49 8C A7 B8 6D 72 15 17 47 61 B9 36 B2
6. 005F220C - переводит пользовательский ключ из hex-строки в байты (результат д.б. 8 байт)
7. 005F2988 - производит расшифровку. В ней вызывается основная процедура блочного шифрования 8-ми байт (005F257C). Разобраться в этой процедуре не так сложно, как может показаться на первый взгляд. Перед этим можешь почитать статью о сетях Фейстеля на википедии. Производится 4-ре раунда преобразований над 8-ми байтовым входом на основе 16-ти байтового ключа. После выхода из этой процедуры первые 2 байта расшифр. рез-та д.б. $3C69.
8. Затем проверяются последние 4-ре байта результата. Это, скорее всего, идентификатор лицензии (LicId). Он должен быть в диапазоне [10001..15999].
9. Наконец, процедура 005F29B4 проверяет вторые 2 байта результата. Из кода процедуры нетрудно понять, что они определяют дату истечения срока лицензии. При этом 0 соответствует дате 01.01.9999, т.е. неограниченной лицензии.
10. В процедуре 00612DE4 LicId проверяется на принадлежность чёрным спискам.

P.S. Также эта программа поддерживает сайтовые лицензии в  виде обычного ini-файла. На их проверку можно выйти по строке 'DelInvFile.LIC' (0061420A). Здесь в ключе вместо $3C69 используется $9C5B, и LicID = 2014. При желании в качестве упражнения можешь сделать генератор лиц. файлов сайтовых лицензий.