FlexLM: Finding LM_SEED1-3 or ENCRYPTION_SEED3-4

[atomix]

Thanks a lot to both of you for your feedback.
... and also for the nice tips provided in tutorials.

I have just a few more comments after breaking two targets:

1. I was able to find the seeds1-2 for 'target 1' name make a working license usable only with the vendor daemon (so it works fine as network license, even if the server runs locally). However, the target does not accept standalone license, even if I make them locked and time limited. I assume that this is because of not knowing seeds3-4, is that correct? These are probably used locally but not in the vendor daemon.

2. I worked last weekend on 'target 2' and found the encryption seeds1-2 for an older version of the target that used FlexLM 9.2. Then, I was able to make working standalone and network licenses.
Now I tried the newer version of the target which uses FlexNet 10.8. However, based on the seeds1-2 I found for the previous version (based on FlexLM 9.2) and using the lmcrypt generated with SDK 9.2 I was still able to make working working license files. I am puzzled ... how is this possible? Isn't the new FlexNet better than previous FlexLM versions? Or is it just because of not good implementation by the vendor of 'target 2'?

[CrackZ]

Answers;

1. The vendor daemon is designed to accept the lowest common denominator of FLEXlm license, hence it being the one reliable place for digging out the seeds. I commented on a previous thread elsewhere that a lot of implementations now explicitly check for HOSTID=ANY licenses and reject them, alternatively your target may be using the Security Builder routines, identifying lm_pubkey_verify() and checking to see if the code reaches it is a pretty good way of determining which problem your license has ;-).

2. FLEXlm's major flaw is its licensing layers backwards compatibility, that and in the marketplace FLEXlm operates (high-end CAD/CAM applications) developers are loathed to change licensing schemes and annoy customers, a lot of FLEXlm's internal functions are circa 1995-97, in fact I've seen the same bugs in several of the functions since about v5 ;-).

The other reason that developers won't upgrade is one Macrovision wouldn't care to publicise, the Security Builder add-on is something like $10k, since it can be compromised with a 1-3 byte patch, I'm rather pleased Macrovision's customers aren't desperate to upgrade.

I would like to add that with some work FLEXlm could also become a really good protection.

Regards

CrackZ.