The last weeks I have been working with some serious reversing.
The target is a program called Advanced Design System 1.3 from
Agilent Technologies. It is an simulator for DSP and Microwave
designs. The target uses FlexLM 6.1 for license management and
I'm running it under Windows 98. I have a demo license file
for this target.

I started running lmgrd in the bin directory. This program
executes the vendor daemon 'hpeesofd'. Using a bpx on
'GetCommandLineA' I found the command line to execute
the vendor daemon directly.
The command line was 'hpeesofd -T myhost 6.1 -1 -lmgrd_port 6978'
Running this vendor daemon with a breakpoint on 'GetCommandLineA'
I can bpx the functions that I'm interrested in.
I have found some functions by comparing the vendor daemon with
lmgr326b.dll. The code in this dll and the code in the vendor
daemon are not identical, but it is still possible to recognize
some functions.

I first started to do the standard approach by breaking at
lc_init and write down the values stored in the vendorcode
structure. Then I used a generator for vendorkey 5 and created
a new license file. This didn't work.

Then I read the essay from Dan some more and tracing around
using w32dasm. After a lot of tracing I put a breakpoint on
the decrypt function in l_sg. The daemon is very similar to the
target described in Dan's essay about lc_new_job(). Passing
0 as the first argument to this function disabled the alternative
seed encryption. This will cause the seed encryption part of the
job structure to remain zero.
Watching the vendorcode structure after the call to decrypt
gave me another set of seeds which I tried without success.

I must say that I'm not really sure about what's happening after
the seed decryption. I think that somewhere the vendorcode
structure and the job structure would be used to generate
a license key which then would be compared to the key in the
license file.

Any idea on what I should try?

Thanks in advance,
David

I'm assuming that this app makes use of lc_new_job as the seeds from l_sg did not work. What you need to do is trace through the l_n36_buff function that is pointed to at the beginning of l_sg (See the check to see if a flag is set by test var, 80.. if yes go to function pointed to by another var.) Inside there is a point after the random time based data is acquired where the real seeds are built (or at least can be found through an xor). Read Nolan Blender's excellent essay for more specific information on how to do this and which bytes from the random data to use.

HTH

Why does everybody always want to find the vendor code hidden in the target? However, even you don't know the vendor code, you still can generate license key from the target itself (just let one comparison be correct, then the license will come out).

hmm..

why don't you use "BPX Createfilea" ?
When daemon reading License file, You can find lc_init & lc_checkout!!

first.. you have to check some symbolic bytes in those routine.
when finding it!! if you so genius , can find Vendor 5 & decrypted seed1 &2..

V5 , Seed 1 & 2 have some symbolic routine like "PUSH XXXXXXX" , "CMP reg , XXXXXXX" & "MOV reg, XXXXXXX"

farewell. =)

Hi everybody,

Finally I got the license generation working.
Thanks alot for your great help.

Regards,
David