I am working on a target that gives you the usual 30 goes and the usual option to register with name and serial number. I have found that the number of uses count is stored in a dll file in ascii. When you exceed 30 uses it writes ascii 51 to
the dll file. You can zero the count even after 30 uses. Looking at this dll both with a hex editor and with Wdasm it seems to contain nothing but two ascii characters in locations 012C and 012D the file length is 1024 bytes long.

I previously established that the program exe is packed with asp v2 and have expanded it into a new unpacked exe using aspack die. This seems to work ok.
I'm thinking that when the prog starts it must read the 'number of uses' value in and compare it to 30. I've tried looking for things like 'GetOpenFileNameA' to set a break point on.

What I would like to know is how does a prog like this know what file to open?
Where would the file name be stored and in what form?

The program itself uses none of the usual message box api calls.


-------------------------------------
learning slowly and a long way to go !!

?? CreateFileA??

OR
?? _lopen ??

Thanks guys, those are answers to the dumb part of the question. Perhaps I did not ask the right question.
There is in this case no input from the user as to the name of the file or DLL to be written so the name of the file (FRED.DLL) must be contained within the program itself but I have not found it yet.

Am I right in thinking that 'CreateFileA' will need the file name passed to it to create it on the hard drive. How is the File type determined (exe,dll,sys.)

The simplest answer would be that you should search for the string FRED.DLL in memory both as an ASCII and UniCode string, but I doubt the protector would be dumb enough to store an important part of the protection in plain sight. It may be encrypted somewhere or read from another file or resource. However if and when you break on CreateFileA or _lopen or one of a handful of APIs used to open files (check the list of imports, the API name is there for sure), the file name FRED.DLL should be clearly readable at the top of the stack. When the API returns, you should be able to figure out how FRED's name was generated/recovered plus you should be at the center of the protection.

Ummhhh, Now that I think about it, storing the time used in a fake .dll file is quite dumb. so by all means search for the name hard-coded somewhere in the app folders. (Use a GREP for windows utility).

Anyway, you should hook the unicode versions instead. Like CreateFileW.. else you may miss the call...