Clandestiny
October 31st, 2001, 22:42
Hiya Wonderwoman,
Its really nice to see a girl on this board once in a while

And judging from the 12 replies you've gotten in 2 days, I'd say quite a few folks would agree with me
Without downloading the target, I can only offer you some general suggestions/approaches. If you're in need of more specific help, I'd suggest providing a url to the target so that someone can take a closer look at the prog in question.
First, as aimless mentioned, chances are that you will NOT find the valid code in one of the registers. Even in basic key gen algorithms, there are often multiple mathematical checks across all or parts of the key.
2. You can probabaly gain a bit more information about your target from the Wdasm listing. Specifically, what APIs does the program use for text entry? GetDlgItemTextA, GetWindowText, ...ect. These APIs will also provide useful breakpoints or even provide a good boundary for setting up a backtrace. And sense you mention an expiry date, you should also spy out the timer APIs used by the program. These might include GetSystemTime, GetLocalTime, and GetTickCount to name just a few. Of course, expiry dates often smell of registry entries so it couldn't hurt to take a look at the registry access APIs either (RegCreateKey, RegOpenKey, RegQueryValue...ect).
3. Check for suspicious registry accesses using Regmon. Expriy information is sometimes stored in the registry.
4. Check for suspicious file accesses using FileMon. Snoop around any .ini or other initialization files the prog uses. Expiry information is sometimes stored here as well.
5. Gain a mental picture of code flow, particularly during initialization and during the serial # entry. An API monitor is a great resource in this situation and you can use it to spy real-time on all of those text entry, timer, and registry access APIs you found in Wdasm. Try to see significant patterns by correlating the order and proximity of the function calls. You could also use this information to set intelligent boundary breakpoints for a backtrace.
6. Make the most of your tools. The backtrace range feature of SI could be used effectively in a situation like this. A range could easily be defined between the text entry API and the invalid code message box such that you can examine the exact sequence of code flow between these 2 breakpoints. The syntax for the backtrace is bprw "module name" T. Check SI documentation for more details on this useful feature. Also, check out Kayaker's nifty TracDis tool. Its currently the only way to save SI backtraces to a file and version 2 will soon have a handy autodumping feature to boot.
Well, thats about all the general advice I can think of right now. Good Luck and keep learning
Cheers,
Clandestiny