OK, the way I cracked the date problem was using WinDasm32, I pulled disass. the corel app (I've been using PhotoPaint 7 Plus). One of the import functions is GetLocalTime (I think it's a kernel routine). Anyway, there's only one reference to it which happens to be within a standard MS C++ routine to convert the full date into seconds from 1970, with adjustments for time zone etc.
I actually stumbled in this routine whilst analyzing the demo version of Elan from their website. Try downloading the demo and adding the string "ELMDEBUG=1" to your environment. You'll find that when running, the protection displays debugging info which gives details of what the ???.lic file contains encoded in those long numbers.
Now, the commercial version still has the same debugging routines which are called at the same instances - however, they are disabled (presumably by some internal flag). This doesn't matter tho' because the demo gave me enough info on what the data was they would have been displaying. From this I located the "Get the date" routine which is the one I mentioned earlier.
It is then a simple enough matter (so long as you have access to the MS specification on how GetLocalTime returns its values) to fool the protection into always believing it is the same date - by adding a small routine to return the same date every time.
Now, base+metal has suggested a few things about the registry value which suggest that it contains the actual install date encoded. I believe that is could be a very simple matter to write a routine to get the value of this key, convert it to the date it indicates, and plug that into a crack. Thus making a generic crack for virtually all Corel 30-day trial apps and also many from other companies which use the system.
I'm actually quite interested in finding out how the ???.lic file encodes the information it contains, but I think that could be a little long-winded, and if I'm correct with the above assumption, also a little pointless.
