Hi, I'm trying to crack a FlexLM v7.2a-based program. When debugging the target exe with SoftICEI could not set bpx lc_init - it is not among imported functions. Therefore, I cannot procede with searching for encryption seeds, as it is discussed in several fravia essays. Does anybody know what should I do? Thnx

Lo fafel,

i cant help you much but i can give you some hints...
First your work shouldn't start with with Sice, it should start with IDA.
You have to get the FlexLM SDK of the adequate version your target is using.
As you mentioned in your case it's the 7.2a.
Without the proper SDK there is no simple way of crackin' this protection.

You will later need it to create a valid license file.

After you have got the SDK make signatures( i hope you are familiar with it, if not search the board or google) of the *.lib file in order to apply it to IDA to identify the common FlexLM funktions.

This will make your work MUCH easier in order to get realitic change to crack it ;D
Maybe your are the opinion of that the old fravia tuts on FlexLM are not very appealing for newbies: I agree. When i started FlexLM stuff they didn't helped me a lot...but listen i mean at the beginning ;D Later your are happy about those rare ones ;D

There is one tut out with is very good to read and understand for newbiez.
It show FlexLM protection on DevPartnerStudio from Numega.
You can find it on searchin the exetools board for FlexLM...

Maybe this is a little help for you...

So don't dismiss ;D It's worth to learn

Regards,

OHPen

You also might want to check out the CrackZ Archive linked at the bottom of the Forums. It contains a great deal of information about FlexLM systems and reversing and has many of the tools you would need to reverse such systems. Just a hint.

Regards,

To OHpen: Thanx, I had read the fravia essays before, they gave me good overview about flexlm cracking methods. I have followed the Nolan Blender's "Zendenc FLEXlm 7.2 cracking information". I found data[0] and data[1] (prior to l_sg call). The thing is, I could not find the pointers to the job structure at that point - values of job+8, job+c, job+10 were all null. Another curious fact: data[0] and data[1] were always the same during every execution of the prohram. What the hell is this?? Another unknown protection?