Is there a way to make a Flexlm License 'for ArcInfo 7.12, or Arcinfo 8.01' work when the date is expired?

I will appreciate the help...

I tried to force this to happen yesterday with Rational's Purify, set the date to 4 weeks in the future to expire the 15 day license, it expired and then I set the clock back 5 weeks. However, the bloody thing then said I had 3 weeks to evaluate it!

Why can't people expire there programs properly? I wanted some kind of "No, go away, this programs expired!" message but got none

Still, didn't take too long to patch the program to make it think that the license check out always succeeded, and then I just set my clock back to the original date. I'll create a proper license for it this weekend.

Yes there is.

ArcInfo 7.12 and ArcInfo 8.01/8.02 use different algorithms for calculating the VENDOR_INFO field.

First, extract the seeds from the daemon IIRC it was just standard flexlm.

Build an lmcrypt with the correct seeds.

Update your license file, and process it with lmcrypt.

The VENDOR_INFO field has to be update to match the license key.
Using your favorite debuggger and disassembler, reverse the routine which matches
the license key to the VENDOR_INFO string and make a keygen.

NB, could you be more specific when you say "reverse the routine which matches the license key to the VENDOR_INFO string and make a keygen" . Perhaps, an essay on this would be welcomed by all. Vendors are becoming very clever in customizing flexlm and essays on how to overcome such as this "VENDOR_INFO" problem would be enlightening. Your last essay on flexlm - crypt filters was useful to me in reversing several programs

Well, there's not much to say, except that the technique that they used in this particular
program was very similar to what many shareware authors use. The basic process is this:

1) the particular license line is grabbed.
2) the license key and the VENDOR_INFO string are grabbed.
3) the license key is passed through a custom transformation.
4) the output of the transformation is compared to the VENDOR_INFO string.
5) if they are the same, the key is good, else the key is bad.

This keygen is slightly unusual in that they use a lot of floating point math
in the calculations - a lot of shareware uses integer math or table lookups.

Here's a piece from the keygen:

dqNum_90 = (double) iNum_50;
dqNum_98 = iNum_84;
dqNum_98 = dqNum_90 / dqNum_98;
dqTmp = sqrt(dqNum_98) + 1.0;
fNum_10 = (float) dqTmp;
dqTnum = (double) fNum_10;
dqNum_a0 = iNum_84;
dqTmp = pow(dqNum_a0, dqTnum);
iNum_4c = (int) dqTmp;

and there's lots of that sort of thing.

Since everyone does it differently, it's not amenable to a generic solution.