http://www.kratronic.com/recorder/recorder.html - 1.9Mb.
Making key generators for Visual Basic programs has always seemed to me to be something of a waste of time, simply because we can all register them in a matter of minutes using 2 very basic techniques. I'll show you the most common :-
:004897A0 CALL MSVBVM50.__vbaVarTstEq :004897A6 MOVSX EDX, AX :004897AB JZ 004899AB <-- Good guy jump. :00489803 "Code or (name) is wrong. Please enter a valid code"
So we enter our name, bpx for __vbaVarTstEq (the second break is the one you want), perform a search for our bogus code in memory (wide-char format) and scroll the data window no more than +/- 50h and theres the good code sat in memory. This is exactly what I did for this target, codes all end with the suffix GJF. Lets however break a few rules and reverse the algorithm, remember that most VB programmers are linear in nature and thus think linearly. Have a look with SmartCheck :-
With the name 'z' we can check the cmdOK_Click procedure and see that the required result is 754876960, and that this seems to be based on 32 'z's, so we immediately suspect that the name will be lengthened to 32 using a recursive method, this you can verify in SmartCheck if you like. We see also that Asc() is used to get the value in decimal of 'z' i.e. 122. Lets also see what 'y' produces.
Jotting down what we have :-
32 'z's produce a decimal result of 754876960.
So a single 'z' produces a result of 754876960 / 32 = 23589905.
32 'y's produce a decimal result of 748690976.
So a single 'y' produces a result of 748690976 / 32 = 23396593.
The difference between these consecutive results is 193312 and if you care to extend the pattern you'll already be able to see what 32 'x's will produce. What this result actually means is that for any letter we care to choose we'll always be able to calculate its individual contribution using the value we know for a single 'z'. You could also quickly convert 193312 into hex (2F320) and perform a disassembly search and take a look.