oldbrat
November 15th, 2011, 23:28
G'day,
Reading the numerous articles around about FlexLM ECC in last 2 days, I was still confused how to defeat the FlexLM ECC signatures. Before sit down with the debugger, I think that can be wise to ask here about "available strategies".
Finding encryption seeds seem to be the easy part, at least I dont have problem in the past, ECC is new for me.
1/ The "l_pubkey_verify" patch:
If I understand right, going this way we must have few things in hand:
- ENCRYPTION_SEEDS (from vendor daemon)
- self-generated LM_SEEDS.
- self- generated CRO_KEYS???
- LM_STRENGTH= LM_STRENGTH_239BIT??? If we need the SIGN=120chars?
And what the patch supposed to do is patching l_pubkey_verify return 0, therefore bypass the elliptic curves checking.
The patch should be applied to both the vendor daemon, as well as the executable binaries.
Is this the right understanding?
2/ The VENDORCODE structure patching?
I see some experienced guys mention about VENDORCODE structure patching.
Again, if I understand right, VENDORCODE structure must be compiled into the .rodata section, and what I have to do is finding that struct, and modify the VENDORCODE->strength to force the old way licensing.
In that case ENCRYPTIONS_SEEDS are enough to generate old-style licenses.
It's seem to me the nice way, but how to find the structure inside data section is not so clear yet. Can anybody shed some light into this?
Can the RCE comment on these two approachs? What's prefered way to defeat FlexLME CC?
Thanks and best regards,
oldbrat
Reading the numerous articles around about FlexLM ECC in last 2 days, I was still confused how to defeat the FlexLM ECC signatures. Before sit down with the debugger, I think that can be wise to ask here about "available strategies".
Finding encryption seeds seem to be the easy part, at least I dont have problem in the past, ECC is new for me.
1/ The "l_pubkey_verify" patch:
If I understand right, going this way we must have few things in hand:
- ENCRYPTION_SEEDS (from vendor daemon)
- self-generated LM_SEEDS.
- self- generated CRO_KEYS???
- LM_STRENGTH= LM_STRENGTH_239BIT??? If we need the SIGN=120chars?
And what the patch supposed to do is patching l_pubkey_verify return 0, therefore bypass the elliptic curves checking.
The patch should be applied to both the vendor daemon, as well as the executable binaries.
Is this the right understanding?
2/ The VENDORCODE structure patching?
I see some experienced guys mention about VENDORCODE structure patching.
Again, if I understand right, VENDORCODE structure must be compiled into the .rodata section, and what I have to do is finding that struct, and modify the VENDORCODE->strength to force the old way licensing.
In that case ENCRYPTIONS_SEEDS are enough to generate old-style licenses.
It's seem to me the nice way, but how to find the structure inside data section is not so clear yet. Can anybody shed some light into this?
Can the RCE comment on these two approachs? What's prefered way to defeat FlexLME CC?
Thanks and best regards,
oldbrat