Reading 'nblender' "Zendec" FLEXlm 7.2 info essay, I've concluded that it is relevant to 7.1 versions too (unless somebody proves me wrong - it is implied in the essay).


Some dis-assembled code:

.text:004171EA and edx, 8000h
.text:004171F0 test edx, edx
.text:004171F2 jz short loc_417217
.text:004171F4 cmp _user_l_sg, 0
.text:004171FB jz short loc_417217
.text:004171FD mov eax, [ebp+arg_8]
.text:00417200 push eax
.text:00417201 mov ecx, [ebp+arg_4]
.text:00417204 push ecx
.text:00417205 mov edx, [ebp+arg_0]
.text:00417208 push edx
.text:00417209 call _user_l_sg
.text:0041720F add esp, 0Ch


So here I was, noting relevant Args Ptr:
'eax' (@ 00417200) for a 'vendorcode' structure ptr,
'ecx' (@ 00417204) for a 'vendorname' ptr, and
'edx' (@ 00417208) for a 'job' structure ptr.

Here are the captured results:
"vendorcode ptr +4" - vendorcode.data[0] =.....some Hex value....
"vendorcode ptr +8" - vendorcode.data[1] - .....some Hex value....
"vendorname ptr" = ...some correct vendor name....

"job + 0" = 0x6600
.....= all '0's !!!!!!!!
"job + 8" = 0x0000
"job + C" = 0x0000
"job + 10" = 0x0000

Obviously, "job" structure filled with all '0's is NOT one would expect for FLEXlm Revisions greater than 7.0.

Feeding the above info into nblender's "calcs**d" - didn't result in correct s**ds (luckily enough I had the correct s**ds - this was just a test case).

Can somebody explain this phenomenon ?
TIA

Hiya,

Its no phenomenon.

Note down your 2 pointers, job and vendor code structure and trace over the call to populate them, then feed the values to calcseed.exe.

Regards

CrackZ.

From the essay, I understand that the 2 structures info is captured just BEFORE the "_user_l_sg" is called. However, I have captured it immediately after a 'step-over' - and still got the wrong keys.

After stepping over "_user_l_sg" - I get:

vendorcode:
0070F1F8 00000004
0070F1FC AB4F9720
0070F200 F04C9826
0070F204 458E21E7
0070F208 8C34FC32
0070F20C 4E83138C
0070F210 88C470CA

vendor name:
c***** (only the true 1st letter is given - relevant in ecryption/decryption)

job structure:
00A40240 66 00 00 00 12 00 05 00 83 A3 C2 DC 8D 59 ED 60
00A40250 87 C4 58 A5 00 00 00 00 00 00 00 00 00 00 00 00

calcs**d results:
69a214e4
32a11be2

These are definitely the wrong s**ds....(as I said - I have gotten the correct working ones some time ago) - Any clues ?

Hi All,

May be that the vendor name starts with "g"?

I have found an error in calcseed.exe

See my post on this topic.

Bye

I looked at the essay again, and its not made clear that you have to be past that "call to ptr" in l_sg before entering the values into
calcseed. I have addressed the problem with vendor names starting with 'g' however I suppose that I should test all possibilities before releasing a new version

"Step past the call to ptr before entering the values into calcseed"


--nb

I have tried both methods - "stepping-over"...and not.
In both cases I've captured "job" structure AND "vendor" structure SIMULATENUOUSLY (at the same clock tic) - to no avail...
E.g. - In both methods 'calcs**d' yielded WRONG s**ds !!!

There must be some cases where nblender's method fails, or that I've missed something !

Hi Roli,

If you have a daemon why don't you post it or PM ?

So we can try ....

Bye

I tried it with this daemon, and it worked fine.
417209 might be an interesting place to break.

Daemon is too big to attach - look for T*ming Des*gner

Hmm - I get significantly different results than you do.

1) I recorded the values on the stack (esp and esp+8) before the call.
2) after the call, I dereferenced these pointers and got this.
3) I used w32dasm to do this, but of course you can use softice if it
makes you feel leeter.


[008923D0] - 00000066 f...
[008923D4] - 00050012 ....
[008923D8] - bba5c4e4 ....
[008923DC] - 078a3eea .>..
[008923E0] - c23fa3e0 ..?.
[008923E4] - 00000000 ....


[0012EA48] - 00000004 ....
[0012EA4C] - cd5afc56 V.Z.
[0012EA50] - 9659f350 P.Y.
[0012EA54] - 2240477c |G@"
[0012EA58] - ea8896b8 ....
[0012EA5C] - 46571d1a ..WF
[0012EA60] - ef0a1d56 V...
[0012EA64] - 00000000 ....
[0012EA68] - 00000000 ....


data[0] = cd5afc56
data[1] = 9659f350

vendorname = chrond

job+0x08 = bba5c4e4
job+0x0c = 078a3eea
job+0x10 = c23fa3e0

Please note that I'm dereferencing the values as 32 bit values, **not**
char - on little endian machines such as the x86 machines, this is
important to note.

encseed0 = 09644769
encseed1 = 5267486f

With the values that you show, I can't dig out vendorkey5 either, which
to me implies that there is some sort of problem with that set of values.
I tried switching the byte order, but still no go.


If you have an alternate method of digging the seeds out perhaps
you should stick with that if this program does not work for you.


If you can provide greater detail on
how you extracted the seeds, it could help isolate the source
of difficulty.

--nb

Hi All,

I have obtained the some results of nb, I mean the rigth seeds.

I have worked with two different methods, nb and my personal one, and both gave the some results. I have tested these methods also with Fl*xlm v8.1 and they worked well.



May be you are not giving the right vendor struct?


Bye

Sorry,

Just some another things:

I have extracted the KEY_5 using the tool lmvkey,
than I have generated a license with SDK v8.0c and these structures:

2240477c
ea8896b8
46571d1a
ef0a1d56
==please try==> 3f....ca

ESeed_1=09644769
Eseed_2=5267486f

Please note that, generating the license, you have to check the box "add compatible license key" in evallicgen.exe
In fact it is this key that is checked, not the SIGN value.

Bye

There's your problem right there - the fake license/correct
arguments to the vendor daemon are required in order for the
program to correctly execute. If you interfere with the flow of
the program to make it call the lm_new routines with incorrectly
initialized data, you are bound to get incorrect results.



Well, there are several alternative approaches, which is part of
the reason the defects with calcseed weren't caught by me or
other users until recently

If there are people using flexlm reading this, here's some helpful hints:

1) use the crypt filters if you can (this needs the full API). This helps some, and at least keeps people from fishing serials easily, or simply generating a keymaker for your product by fishing the seeds out. This provides a fair amount of added security for about an extra hour of coding work, so spend that time.

2) If you're worried about people making keys for your program put RSA encrypted data in the vendor string, and check that as well. You can purchase the CRO option if you have deep pockets, and current versions of flexlm are very secure from a cryptographic viewpoint. It's like having the best Medeco locks on your screen door.

3) Remember that software protection is only a small part of the equation.

--nb

I haven't used the method you describe, I haven't fully traced it
out, being the lazy person that I am. If I can do stuff without
having to patch anything, so much the better.

Anyway, try this as your arguments:

chrond -T 6.1 3 -c license.dat

Of course the daemon will fail, since it can't communicate with
lmgrd, but you'll get it to trigger that call.

Also, you could set a breakpoint with the symbol loader first, then

lmgrd -c license.dat

and that would work as well.


--nb.

The above invocation method works with Unix based daemons (the exact Args list may vary, and is taken directly by grepping the daemon name with 'ps -auxww' command). However - does this method work with Windows ?

BTW - the above mentioned alternative method DOES NOT require any patch to the target - it just needs the extraction of some constants from the code - in addition with the already extracted 'vendorcode' & 'vendorname' data....

Yeah, I see - you just change the flags while tracing rather than patching.

Ahh well, - I guess everyone uses what works for them

** I use similar method ( roli )

--> i find rapidly txt : mov ebp, esp

--> i found at 40D6BD key unique : 0F 44 2D BF

--> after at 40 DA 19 : order for 2 3 0 1 ( shl .. )

--> i break at l_sg and pass the first jz

--> i run step by step and after the call i look the values

--> i use a licgen for retrieve the good seeds


** note : the seed & keys are similar to old flexgen T. DESIG.

CPCP