Using FLEXlm Internal Diagnostics to reveal ALL |
||
|
|
|
|
||
|
|
An essay on the simplicity of using inbuilt Diagnostic functions inside FLEXlm to reveal information normally kept hidden. Many previous methods offered by Pilgrim : FLEXlm handy hints (more stuff on FLEXlm) and : FlexLock...less secure than the rest of FLEXlm) utilised the SDK from GlobeTrotters (FLEXlm Programmers Kit). This essay utilises the inbuilt generation of ACCESS keys in the lmgr325c.dll to supply codes for any type of license and uses the diagnostics function to deliver the information to the user.
|
Previous essays on FLEXlm required the use of the SDK to generate
licenses. Since I couldn't be bothered downloading 7Mb's I originally
investigated the information at hand which involved the executable
and the standard lmgr325c.dll.
|
W32Dasm, Hex Editor.
|
No target just our dear old FLEXlm.
|
BACKGROUND INFORMATION
Examination of the lmgr325c.dll string references shows an interesting String "FLEXlm_DIAGNOSTICS". This is a global variable which FLEXlm uses to indicate the level of diagnostic information that is required to be shown when a lm_checkout returns an error. The global variable is stored in the registry at :-
[HKEY_LOCAL_MACHINE\SOFTWARE\FLEXlm License Manager]
"Service"="FLEXlm License Manager"
"FLEXlm_DIAGNOSTICS"="2"
"LM_A_DIAGS_ENABLED"="1"
LM_A_DIAGS_ENABLED = 0 ; Deactivates Diagnostics
LM_A_DIAGS_ENABLED = 1 ; Activates Diagnostics
FLEXlm_DIAGNOSTICS = 1 ; Basic Diagnostics
FLEMLM_DIAGNOSTICS = 2 ; Enhanced Diagnostics
This registry key is only present if you have installed the SDK.
GENERATION OF KEYS
1). Information required for generation of key.
The serial key would be required for the license file. This key is generated internally by the lmgr325c.dll from information inside the license file. Before commencing generate a FAKE license file :-
FEATURE f1 VENDOR 1.000 1-jan-0 0
10203040567898765432 ""
ANY
FEATURE f2 VENDOR 1.000 1-jan-0 0
10203040567898765432 ""
ANY
FEATURE f3 VENDOR 1.000 1-jan-0 0
10203040567898765432 ""
ANY
FEATURE f4 VENDOR 1.000 1-jan-0 0
10203040567898765432 ""
ANY
NOTE : The 2nd 4th 6th 8th digit in the key is used for the date so they must be zero. This is only valid for ver 5.12. In version 6 I believe these are missing. f1,f2,f3,f4 are feature names for your program. Search around for these or just run the program and let it tell you which feature is missing in the license file. VENDOR - This is needed and can easily be found (see Pilgrims essays). 1-jan-0 - Unlimited time access. 10203040567898765432 - serial key (required).
NEXT STEP
If you follow pilgrims essays you will find the key 5 generation point. Continue stepping over local functions until you see the extract date followed by another call :-
CALL 10030850 <- Key 5 Generation.
ADD ESP, 0C
MOV EAX, DWORD PTR [EBP+10]
MOV EAX, DWORD PTR [EAX+04]
XOR EAX, DWORD PTR [EBP-04]
MOV DWORD PTR [EBP-24], EAX <- Seed 1.
MOV EAX, DWORD PTR [EBP+10]
MOV EAX, DWORD PTR [EAX+08]
XOR EAX, DWORD PTR [EBP-04]
MOV DWORD PTR [EBP-20], EAX <- Seed 2.
LEA EAX, DWORD PTR [EBP-28]
PUSH EAX
MOV EAX, DWORD PTR [EBP+0C]
ADD EAX, 48
PUSH EAX
* Reference To: LMGR325C.l_extract_date
CALL 100030EE <- Extract date from fake license file.
ADD ESP, 4
PUSH EAX
MOV EAX, DWORD PTR [EBP+0C]
PUSH EAX
MOV EAX, DWORD PTR [EBP+08]
PUSH EAX
CALL 10018F10 <- Look at what this returns.
ADD ESP, 10
Examine the location EAX is pointing to. Does this look like a KEY for the license file. You don't think that the FLEXlm would really create a system where the license key is generated and then COMPARED to the one in the license file. YES they would because this is exactly what they do and not only that they leave it in memory untouched when they are finished with it. Note this key generated by lmgr325c.dll matches the license file criteria i.e ANY and 1-jan-0, so note the location of this CODE.
2). Let FLEXlm do the work for you.
Now wouldn't it be nice if FLEXlm would display this code along with the feature name when you ran it. Now for some information. Diagnostics only comes into effect when the key is incorrect. With our FAKE license file the diagnostics kick in and save a flexNNN.log file in the directory where you ran it. Examining a typical flexnnn.log file on DIAGNOSTICS level 2 shows that they kindly show FLEXlm checkout error: Invalid (inconsistent) license key (-8,130).
license file(s): c:\FLEXlm\license.dat
lm_checkout("f1", VENDOR, (null), 0x12345678, ..., 0x12345678)
Lets use this lm_checkout line to show us the feature name and the correct KEY.
Search through the dead listing and find
lm_checkout("%s", %s, %d, 0x%x, ..., 0x%x)"
Now patch the routine before it to push the location of the CODE/KEY and voila. The first time you run your program it will report an error and give you the correct key to use. Replace the key with the generated key in the license file and its up and running. The nice thing about this patch is that it does not interfere with the operation of the program The patch only operates when there is a problem.
Having just read pilgrims essay about using lc_baddate() as a place to insert code wouldn't it be easier to use the diagnostic function to spit out the keys and seeds and anything else you need.
Note : To add more information to the print out edit the lm_checkout("%s", %s, %d, 0x%x, ..., 0x%x) to anything you like :-
LM %s,%s,%s,%x,%x,%x,%x,%x,%x,%x,%x,%x,%x) will supply a lot of information as long as you push it to the stack before calling it.
|
Let me just say how can FLEXlm be so stupid as to generate
a key and then COMPARE it and leave such a large amount of room
for the casual programmer to extend the working operation of their
own program. Anyway let us further examine FLEXlm in order to
find easy solutions to complex problems