Okay...before we start anything, I am currently quite new to FlexLM protections (there, I said it!!).

I need help in trying to break a FlexLM protection. The actual process of breaking is going to be mine, but along the way, I need some clarifications on how FlexLM actually works. This question is one of those clarifications. Yes, I know there is a user manual, a reference manual and a programmers guide. Yes, I also know there is Crackz archive and google. However the previous guides and manuals do not give me insight to FlexLM working from basis of RCE, where as Crackz site is...well, if I am unable to understand FlexLM internal working based on RCE, then it's pretty much quite alien stuff to me. So please bear with me as a FlexLM newbie and hope that I can get certain clarificaitons. This example is specific to: uncounted, permanent and unserved licensing model. No deamons are used.

The program that I am trying to RCE has got a DLL that does the grunt work. This DLL is actually protected by DYNAMIC FLEXLM DLL (yep, the DLL was not compiled with the FLEXLM static library, but was compiled to use the dynamic Flexlm DLL). This means, that I now have a DLL that does my usual jobs and a Flexlm DLL that it dynamically calls to find out license details.

My first clarification: how it looks from above
=================================
I would like to get the basics of how FlexLM works from a bird's eye view. Let me know if the following is correct:

1. Vendor contacts Macrovision to purchase FlexLM licensing SDK
2. Macrovision sells the Flexlm SDK to the vendor at $$$
3. Macrovision also gives the vendor, his own vendor keys (these are 5 in number) and his vendor name
4. Vendor codes his own .exe or .dll file as the application exe/dll
5. Vendor uses the static flexlm library or the dynamic flexlm dll to act as its protection. If static, he links to the same during comilation/linking process, if dynamic, he needs to ensure that the dynamic flexlm dll is given in the distribution. The protection is a combination of his 5 vendor keys given to him by Macrovision, plus 2 additional encryption keys which can be of his choosing.

Please let me know if this overall process of Vendor getting Flexlm protection is correct.

My second clarification: how it really works
================================
1. The user (for simplicity sake, assume he is creating a application dll file which will use the dynamic flexlm dll) starts to code his dll (in either Visual Studio or Borland Studio)
2. In his code, he uses the API calls that are part of the dynamic flexlm dll and other miscellaneous flexlm files)
3. He compiles/links and produces the necessary dll.
4. He creates a text file (which will act as the license file) with the necessary features, expiry dates and signatures
5. He opens lmcrypt.c and enters his vendor name, his 5 vendor keys that Macrovision have provided and his 2 encryption keys which he has himself chosen
6. He then compiles lmcrypt.c into an executable file called, say, lmcrypt.exe
7. He runs this freshly compiled lmcrypt.exe on the text license file that got created. This results in the proper license file, in encrypted format, getting created.
8. He distributes his (a) application dll, (b) the flexlm dynamic dll and (c) the proper encrypted license file

Please let me know if this is correct.

My third clarification: So what are these?
===============================
1. If I have to run lmcrypt.exe on the text license file to get the correct license file, then why does some applications protected by Flexlm work with the above text files only. Why don't they also use the encrypted files? For example, a file with options such as FEATURE, permanant, HOST_ID=any etc text file is used as a license file for some flexlm protected licenses such as Intel Compilers and Vtune where as others use the encrypted format of files such as IBM Rational Rose etc. So where does it say that this app will use a text file as license and this app will use encrypted file as license?
2. In text files, you often see SIGN=12345678. How is this generated? And is this typically given by macrovision to the vendor (unlikely) or generated from compilation or running of the lmcrypt.exe on the text license file?
3. If I get to know (a) the vendor name (b) the 5 vendor keys and (c) the 2 encryption keys, can I generate a valid copy of lmcrypt.exe from the source?
4. How do I get to know the vendor name?
5. How do I know whether the software will accept the text file as license or it will have to be run through lmcrypt.exe
6. How do I get the SIGN=<how do I get this?>
7. WHen I am creating a text file or encrypted file for licensing, how do I know I have given all parameters? For example, I may be trying a perfectly valid text license or encrypted license using the FEATURE option, but it does not work. Turns out, the app also needs the PACKAGE line in the license file. How to I know that it needs the PACKAGE and other such lines?

Trust someone knowledgable and very familiar with Flexlm (Crackz comes immedately to mind) reads this and spends the time to reply. Thanks to all who reply in advance.

Have Phun

You'd better start from the actual manuals ... almost all your questions can be aswered by simply reading it.

nathan

Hiya Aimless,

An apology first of all because I think I remember losing an e-mail from you where you asked my answers to these ;-).

first clarification - all 5 correct, but depending on the FLEXlm options purchased the vendor may also have been provided with additional keys (CRO keys - for the counterfeit resistance option) or the option to generate his own set of seeds (LM_SEED1/2/3) used by the ECC (Certicom add-on).

second clarification - all correct.

third clarification - 1. not sure what you mean here, all FLEXlm licenses are standard in unencrypted readable format, any additional encryption is provided by the developer, the check out routines don't do any decrypting of the license file at all. 2. SIGN=signature (12 digits), this was introduced around v7.x or so, its a variation on the default FLEXlm checkout just computed slightly differently. In later versions this can be really long like SIGN=1234 4321 1234 ..... this is the later Certicom add-on. 3. Yes, but this setup tends now to be older versions. 4. Vendor name is passed to various FLEXlm functions (e.g. _l_36n_buff()) which you have to trace to recover seeds anyway, also through other higher level API's, as someone said above, you can find this detail in the manuals. 6. In the manuals, but for the new FLEXlm you've no hope of generating a valid SIGN. 7. Answer, you don't, I spent some time chasing down an old target wondering why it wouldn't check out, turned out they wanted a VENDOR_STRING in there, a lot of the time when I've had problems like this the FLEXlm API actually tells you the problem, a lot of other times, the applications themselves don't care, since the licensing layer returns success.

Regards

CrackZ.

Noticed I forgot:

third clarification - 5. You might be confused here. lmcrypt.exe is the developers license generator, end-users never see it obviously ;-). Not sure what you mean by knowing whether software will accept a license file.....as I understand it targets either query a license server for a license or a license file (license servers have their own license file).

Regards

CrackZ.

Sweet. Thank you Crackz. It's good to get the cowebs beginning to get cleaned.

A couple of questions (seems a bit naive, maybe...)

1) Why should I trace all API calls from the FlexLM dlls et all (unless of course, I am trying to make a valid license). Is it not better to merely give positive responses to all calls that the app makes to the flexlm dynamic dll? Or is there something I am missing (perhaps the code from the application is encrypted and is decrypted during run-time by the flexlm dll??)

2) Also, to clarify what I requested in the lmcrypt.exe, if the files are going to be perfectly text, then why do I need to run them through the lmcrypt.exe? Unless, the lmcrypt is used only during served models? Simply put, what does that damn file do? Is it even necessary to compile the file for creating an application with uncounted, permanent and unserved model?

3) CRO, ECC, Own seed generation? *Ouch!!* I'm already quaking in my boots.

4) Finally, would you like to continue the discussion on the board or would you like to now converse via email? As per your convenience.

Have Phun

If it's all the same to you, you are of course very welcome to continue it here, so we get to keep all the nice info on the board.

Hiya Aimless,

In reply briefly ;-).

1. As you say, there isn't any reason to trace the FLEXlm lmgr*.dll's used by a target unless you want a valid license (i.e. dig out the pertinent vendor information), on my page, ZiGo's dll's do just as you say and return probably nothing more than EAX=0 to the various FLEXlm functions, BlastSoft's FLEXGen does much the same but also intercepts the routines. There is a big caveat here - the ratio of developers using the FLEXlm dll's to the static library is not a favourable one now for modern software, or at least it isn't in my experience (10:1 or more against maybe), the dll's are regarded as *old* FLEXlm technology, of course FLEXlm dll or static library aside, anyone can patch the _lc_checkout() return to 0 and have it return success.....but then what happens when your target go's to checkout the demo_feature you'd really not like to have licensed ;-).

2. lmcrypt.exe is simply a convenient way for developers to generate their licenses. You fill in the license with 0 as the key, run lmcrypt.exe against it and it updates it with the correct licensing information. The pre v8 SDK's still ship with GenLic which is a more friendly UI for doing exactly the same, the only reason most people choose to build lmcrypt.exe if they can is that it supports the advanced FLEXlm options, such as old format licenses, PACKAGE/INCREMENT/ISSUER lines etc, etc. You don't have to build it to generate the very basic licenses, but some might say 'WHY NOT ;-)'.

3. The CRO option was a very poorly implemented add-on (extra sales maybe? ;-) and I think was probably just added to 'get away' from the default FLEXlm checkout; but don't scoff at the Certicom stuff ;-), no-one I know of or have seen in either the formal or informal scene has been verifiably successful against it.

4. Up to you, if you feel what you are asking is of interest to the people browsing here, by all means we'll continue here, but I'll leave that judgement up to you ;-).

Regards

CrackZ.

Hrm...therefore, continuing where we left off:

1. My application used a .dll to do its main work.
2. It also uses another .dll dynamically (a flexlm license manager .dll) to do the necessary verification, compared to the common practice of including the .dll
3. The flexlm license manager .dll checks the XXXXXXXXXXX.lic file and allows me to work or throws me out of the application (by not starting at all, with a decent message that there were no licenses found)

By discussing the above scenario with Crackz, it comes to light that if we just want to work the application (without bothering about generation of valid licenses) then we can just patch the calls that ensure that the licenses are valid. This leads to patching of _lc_checkout(). Now here are my further queries:

1) Application DLL ----> Flexlm DLL -----> License File (.lic)
2) Where should the point of attack ideally be:
....a) The Application DLL?
....b) The FlexLM DLL?
....c) The License File (.lic) - highly unlikely as we are not bothered with valid licenses

My hunch tells me it should be the Flexlm DLL, but Crackz can inform me of my error if its not so. Also, I have tried the same and some interesting queries arise:

1. If Application DLL -----> Flexlm DLL, then there have to be exports in the Flexlm DLL (which there are, by ordinal, of course) and subsequent imports in the Application DLL (which is a holy mess of calls, getting me confused, but strangely the IAT does not show ANY import from FlexlmDLL. Huh? I thought that the Application DLL calls some function (by name, by ordinal, by whatever,) but the import table should contain the FlexlmDLL name right? wrong. The Applciation DLL does not contain the Flexlm DLL name.) My question is: Is this some new form of obfuscation? or simply renaming of the FlexLM dll (note the FlexlmDLL is not called as lmgr8xxx.dll, but instead the correct name is UnManagedFlexlm.dll, wow!)

2. If I need to ensure that _lc_checkout() returns 0, then obviously, I first need to find the _lc_checkout() function. I assume (I know, but better to confirm) that the _lc_checkout() function resides in the FlexLM DLL and not the application DLL. Now, there is no .LIB file (library file) or and .OBJ file (object file) in the FlexLM 9.2 SDK (nope, it *is* indeed complete. No missing files). So when you say (Crackz, its for you) that you can create the lmgr8xxx.lib and open it in IDA, does that mean you first need to compile it? Or for that matter is there any compilation needed in any file in the SDK for me to actually find the _lc_checkout() routine? (I *know* you must have mentioned in it one of the tutorials, but I just want to reconfirm). I'm trying to currently follow your steps from 2004, but am getting confused by NOT finding the necessary files in the SDK readymade(its a different story if they have to be compiled) to open in IDA and generate signatures from. So, what files do I have to compile to get the .LIB/.OBJ/.PDB etc. file that will enable me to open it in IDA and generate signatures so that I can make out where _lc_checkout() really is. Crackz, if you feel however, that's this method is sufficently examined and detailed in the 2004 essay on Flexlm from you, and not worth repeating again, just tell me so and I'll try to re-read that essary again.

3. Hmmm..never thought of invalid license/patched .dll neverthless, can actually screw up the DEMO mode for that application. My app dll has a demo mode and a full mode, protected by the Flexlm lic. So assuming I manage to find _lc_checkout(), return 0 so that its always positive, what will be the result. Will I run the full version or the Demo version? And how is the precedence determined?

Whew! quite a lot of questions. Crackz, thanks for taking me so far. I've cleared up lots of doubts about the internal workings from your posts. Trust you'll answer this one as well.

Have Phun.

Hiya Aimless,

1. You need to work out whether UnManagedFlexlm.dll is :

i). Really just a lmgr****.dll in disguise (try lmtools and see if it reports a FLEXlm version)
ii). A dll with the FLEXlm static library inside, or
iii). A dll acting as simply a forwarding wrapper to lmgr****.dll which does the real work.

Point of attack should always be the _lc_checkout() routine, depending on the above scenario that might mean you have to patch both or only one of your DLL's.

2. Point of clarification. I used lmgr.lib (from the SDK) as a starting point in IDA for FLEXlm applications protected with the static FLEXlm library, since lmgr.lib is what is linked against applications which use FLEXlm this way, essentially you load up your target application and lmgr.lib and then start labelling ;-). The reason I did this was mainly that when I generated signature files for use in IDA from lmgr.lib, several functions (_l_sg() and others, notably the top layer API _lc_checkout() etc, etc) got missed, the FLEXlm developers know this and obfuscate their code accordingly to produce just this effect.

_lc_checkout() should be clearly visible inside the FLEXlm lmgr****.dll as an export. Have a re-look at the 'muster' part of the FLEXlm 2004 page.

3. The precedence depends on which feature the developer tried to checkout first, if he's read his FLEXlm manuals, checkout success of the demo means you'll never checkout the full version. On the other hand he might try checking out the full version and then simply assume you must be a demo user. You'll just have to test your implementation to see which it is.

Regards

CrackZ.

Hrrrr.....if only the vendors would give everything in one directory...

Still trying to compile the lmgr9a.c and getting reports of missing dependencies...but I'm getting there.

The good news is that the unmanagedflexlm.dll is actually the FlexLM dll. The lmutils reports it as Flexm v9. Good. So I'm just gonna break the checkout() func in this dll and give it a good 0 in the return. (It;ll be fun to watch the demo mode giving wierd results, heh!)

Hrrrr...still no compilation....trying to find some .h files in the source..I hate the .mak file....grrr!

This looks like it'll take a long week...Weekly updates of whether I've been successful in compiling the same will be put up on this notice board (aww..just kidding)


Have Phun

Hi
I have a target which uses flexlm 9.2. I found the checkout functions using the library from an older SDK (8.?). Anyway after forcing _lc_checkout() to return 0 my application just crashes.
Is there anyway I can snoop the assembly to find the correct SIGN ? and enter this into the license file? Seems like the protection is based somehow on the hostid of my computer.
Thanks

Maybe your target has CRC check

I have tried a few things including returning 0 form _lc_checkout in a live debug session with SI. There is no CRO added protection since the SIGN= requires only 12 characters. From reading CrackZ's latest tut it is doing the new style checkout authentication just like his GerbT**l target. I'm going to try his technique of forcing it to do an old style checkout. I'll let you guys know what happens.
Oh ......how do you get by the checksum check?

Your target could check the presence of a VENDOR_STRING that
usually cointains some other usefull information...
Another thing: verify if it is called lc_authorize (or something like this, I don't remember well the name), this is another check.

regards,

rs

Hiya,

Just a quick few additional thoughts.

1. If your sure the target will accept just a SIGN=12 digits attribute, try a fake license with any 12 digits, run it through _lc_checkout() and see what it returns, if you get -8 as an error you ought to be able to generate licenses by using an older SDK version and plugging in vendor keys/derived encryption seeds. If you get another error look up the define in lm_client.h (think thats the name), might be you get LM_PUBKEY_ERR.

Caveat, if the target uses some sort of vendor defined checkout filter, then start reading up on those (lc_set_attr()).

2. I've seen a few targets now that really dislike direct patches to _lc_checkout(), both of them crashed with nasty null pointer errors, a few of them used a very simple 'check the file for tampering' routine, one other required additional things in the license line and refused to run without them.

Regards

CrackZ.

Not sure if this is appropriate, but I found it to be quite helpful (not enough to help me attack mine, though).

h**p://dev.csdn.net/user/zxg32 - 7 part analysis based on the source code the guy had available to him.

Hi,
I'm still getting stuck with my flexlm 9.2 protection. Seems like I get a different job structure every time I run the program and hence different seeds. Is that supposed to happen?

Does have anybody right FlexLM 9.2 or 9.x signature file for IDA ? I couldn't compile it ;o(

Hrrr.....!!!! Welcome to the club buddy!

I'm using VS .NET and the appy is giving me .h not found error after .h not found. Even though the .hs are all there! And the paths are also correctly changed in the files.

But what's life without challenge. For those who are following this thread...sorry, but I am *yet* to compile the file. *Sigh*

Have Phun

I got success at last. My app is now working. Thanks for everyone's help!!

Why don't you guys use an earlier flexlm sdk. I used 8.0 lmgr.lib and it still helped me track down the relevant funtions for flexlm 9.2 in IDA using Crackz' tutorial.

I'am using Mingw ... yes 8.x is ussefull but .. continue trying

BtW> Sorry 4my bad english iam only human ;o)