FlexLM: Finding LM_SEED1-3 or ENCRYPTION_SEED3-4

[atomix]

Some time ago I had the feeling that SentinelLM is more difficult to crack than FlexLM - however I had no practical experience with none of them.

Recently I have reversed some targets protected by SLM and thank to the many tutorials and tools available I was able to succesfully crack them in a relatively short time. Bottom line is that if you know the VendorID than SLM tools become a nice keygen.

Now I moved on to FlexLM and tried to crack a target protected by FlexLM 9. I studied many tutorials available (including topics on this forum) and learned about this security by obscurity protection. To me FlexLM seems quite messy and it is not that nice as SLM.
Anyway, I was able to find the encryption seeds 1-2 and generate the vendor codes using the available tools (many thanks to those making and sharing them). Now all you need to create a keygen for FlexLM apps is SDK and the LM_SEED1-3 values. Alternatively you can go on using the ENCRYPTIONSEED1-2 and ENCRYPTIONSEED3-4 (optional sometimes).

I kinda know the answer to my next question but I do have to ask it to get some feedback from you so I can get some clear answers and the peace of my mind.

While many tutorials describe the way to find encseed 1-2, it seems very difficult or impossible to find encseeds3-4 or/and lm_seed1-3. Is there any way to recover these values? Can you share some info?

Additional question: Is it possible to get the encryptionseed1-2 from the encrypted strings in the license.dat files (providing that you have one)?
What I mean is something similar to SLM, where you can find the VendorID from an encrypted string taken from existing valid license files (see the nice tool posted by souz).

[FoxB]

see source of the FlexLM SDK v9 as starting point to search LM_SEED1-3.
it not possible, imho.

[atomix]

OK, then it's what I expected ... too bad.

What about the full recovery of encryptionseed3-4?
Note that I am aware of this tutorial of Nolan Blender about partial recovery:
http://www.woodmann.com/crackz/Tutorials/Flexecc.htm

As a side note, do you think FlexLM will/can become unbreakable?

[FoxB]

encryptionseed3-4 not used in last daemons....

[CrackZ]

Hiya,

"As a side note, do you think FlexLM will/can become unbreakable?"

Having spent a considerable time taking apart the Certicom code that Macrovision bought in and also a lot of very tedious time labelling up the 1000+ Security Builder functions inside IDA (you don't get much FLIRT out of the Certicom lib), it would seem to me there isn't much hope of recovering enough information to make a key generator.

"Additional question: Is it possible to get the encryptionseed1-2 from the encrypted strings in the license.dat files (providing that you have one)?"

I never tried this but I can probably answer it, the FLEXlm licenses i.e. default license key or SIGN=short key use one of 2 functions to do encryption and formation of the actual license key, in reality both functions create a license buffer of all the pertinent licensing data and then xor/encrypt over it in 8 byte chunks using the seeds.

With a valid license file one would be able to recreate the original licensing buffer used during the generation process, however I'm fairly unconvinced it would be practicle to mount an attack since you have potentially a 64-bit keyspace to search (2 * 32 bit seeds) and to verify any of the key candidates you have to perform the complete FLEXlm encryption to verify the result.

Regards

CrackZ.

[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.

[atomix]

Many thanks Crackz, I really appreciate the information you share.

1. I'll try to use your tip, but I imagine that patching will be required to make it work.
BTW, you did not comment on the usage of encryption seeds3-4 for standalone licenses. Is my assumption correct?

2. I am also pleased that most vendors are not upgrading their FlexLM protection, it makes life easier for the moment.

3. I do agree that FlexLM could become a really good protection, but I do hope that it will not become unbreakable. And as long as you don't work for Macrovision, I don't see them improving much anytime soon.

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.

I don't see that this assumption is correct. It should be nothing to do with seeds3-4. Some Guru in this thread had already shown us that after v8.2 seeds3-4 did not take any role in the SIGN= or SIGN2= generation. Actually, it only used for l_handshake between vendor daemon and the protected clients' handshaking. The real seeds used for SIGN or SIGN2 generation are derived from 3 unsigned long double-words which are indirectly derived from 3 lmseeds.
IMHO, FlexLM is indeed a very good software protection which is almost becoming unbreakable when upgrading to version 10.8.x ECC protection. The only time-reasonable breaking way is through binary program patching. So simple rule is if NO PATCHING then only original legal vendor can generate good license.