建议看看一下，我只是一知半解，需要e文好的翻译一下！
from CrackZ：
Whats in a SIGN?
The tutorial above describes a mechanism by which we can patch the FLEXlm licensing layer to use the license key checkout (this is the oldest and simplest of the FLEXlm validation methods and was chosen purely for simplicity). The basic SIGN attribute was added by Globetrotter at around v7.x (it has only 12 chars) and offers merely an improved algorithm (perhaps more resistance to brute forcing) and better seed hiding, these are about the only 'enhancements' if one wishes to call them that.
These days a lot of customers have switched to using the CRO or TRO (counterfeit/tamper resistant options), really the same thing under a new name. This offers customers the ability to generate the newest style ECC SIGN licenses with strings starting at 58 chars, as far as I know and can verify there have been no successful attacks against ECC FLEXlm which enables either complete recovery of the private key or the LM_SEED's (I do not rule out however that there is enough processing power somewhere to recover them).
The new SIGN length has resulted in most crackers choosing to patch _lm_pubkey_verify() and generating a SIGN= license using their own LM_SEED's. There is however an alternative approach which involves forcing the licensing layer to do the old style SIGN=12 chars checkout and it simply involves patching only the 2nd bad flag we found inside _l_n36_buf() (see above). We can then recover the encryption seeds as before and generate a license using either the SDK or Lmcryptgui available on this site. The patch works by simply telling the licensing layer not to get the address of _lm_pubkey_verify() which is checked shortly after _l_sg().
Another important thing to note, its easy to verify if your target will allow the old style SIGN= checkout, after _l_sg() set a breakpoint on the mangled seeds in the vendor code structure, if it hits the seeds are being recovered and you can generate the old style standard SIGN, if not, you'll need a patch; after a patch a breakpoint on the mangled seeds should hit, just prior to them being recovered.
代码:-------------------------------------------------------------------------------- I also remembered that the checks for the default seed codes (shipped with the SDK) was a good place to fish the correct
seeds, a simple disassembly search for '87654321' finds this code :-
:00429C4C CMP D, [EBP-34], 87654321 <-- Check for encryption_seed1. :00429C53 JZ 00429C5E <-- Jump to Error. :00429C55 CMP D, [EBP-30], 12345678 <-- Check for encryption_seed2. :00429C5C JNZ 00429C85 <-- Good jump. :00429C5E MOV EDI, FFFFFFA5 <-- Error Code (-91).
Routines inside Ser85.exe detect bpx type breakpoints and patching of key files, the checking code starts at 0040EFD3, here
you'll see the names of the files that are checked and the rather obvious 'PUSH 7' instructions which produce a cryptic error
message box asking you to call Ansoft for assistance. The files verified should give us a good idea where to look for other
parts of the protection, Ansoft's developers evidently tried (as is good policy) to identify possible points of attack. Using
bpmb style breakpoints we can quickly recover (what we think are valid) encryption_seed1 (0x7CB2B081) & encryption_seed2
不好意思啊 laoqian,你自从加了我，就么说过话，qq里好多人，不晓得哪个是你了，呵呵，你提醒一下，你第一个字是什么来着？对不起啊，
（当然对比法验证方法除外）
好贴，顶.......
