PizzaPan
May 5th, 2006, 11:56
Sorry to bother guys, i have been working on a couple of targets for the past couple of days and after some analysis i came to the conclusion the files are encrypted using some type of des.
My analysis:
I am aware target specific code is not allowed, however i am not too sure about the name of the company, i couldn't see it mentioned in the FAQ, so i will go ahead and type it, and if i there is a problem please forgive me and edit it.
The targets i were working on both belong to the company COMPANY NAME DELETED, and they both use FlexLM, i had no problem retrieving the initial features, and patching the ecc verification process.
Later on it scans through your license file looking for various features in the format:
XXXX_YYYY: X = 4 Digit Vendor, Y = 4 Digit Product ID
Now they have a entire table of this, so i dumped it and wrote a quick parser, and everything is fine, until i come to the second target which is a addon for the first target.
Second Target:
The second target is a type of library addon for the first target and from what i could tell it uses the vendor string from the features as a decryption key to decrypt the library file.
Example:
FEATURE XXXX_YYYY DEAMON DATE EXP COUNT \
ISSUER=X HOSTID=X SIGN=ECC_239BIT_SIG
VENDOR_STRING=XXXXXXXXXXXXXXXXXXXXXXXX
It takes the "XXXXXXXXXXXXXXXXXXXXXXXX" checks its 0x18 in length and then splits it in to 2 strings, both 0xC in length.
This is then converted further into dwords and used later i assume in the decryption process.
My question:
If they are still using 3des which i assume is correct, there really is no way to decrypt these without the real key is there?
Also i am not a expert on encryption, but from reading the 168bit key is not going to be brute forced anytime soon, but could i assume that if i were to get the real keys from somebody else that everybody else would have that same string because in the end the 3des key must be the same to decrypt it ?
Example:
User X Buys Feature "XXXX_YYYY" and gets Vendor String "ABCD"
User Y Buys Feature "XXXX_YYYY" and gets Vendor String "ABCD" also ?
Thanks.
My analysis:
I am aware target specific code is not allowed, however i am not too sure about the name of the company, i couldn't see it mentioned in the FAQ, so i will go ahead and type it, and if i there is a problem please forgive me and edit it.
The targets i were working on both belong to the company COMPANY NAME DELETED, and they both use FlexLM, i had no problem retrieving the initial features, and patching the ecc verification process.
Later on it scans through your license file looking for various features in the format:
XXXX_YYYY: X = 4 Digit Vendor, Y = 4 Digit Product ID
Now they have a entire table of this, so i dumped it and wrote a quick parser, and everything is fine, until i come to the second target which is a addon for the first target.
Second Target:
The second target is a type of library addon for the first target and from what i could tell it uses the vendor string from the features as a decryption key to decrypt the library file.
Example:
FEATURE XXXX_YYYY DEAMON DATE EXP COUNT \
ISSUER=X HOSTID=X SIGN=ECC_239BIT_SIG
VENDOR_STRING=XXXXXXXXXXXXXXXXXXXXXXXX
It takes the "XXXXXXXXXXXXXXXXXXXXXXXX" checks its 0x18 in length and then splits it in to 2 strings, both 0xC in length.
This is then converted further into dwords and used later i assume in the decryption process.
My question:
If they are still using 3des which i assume is correct, there really is no way to decrypt these without the real key is there?
Also i am not a expert on encryption, but from reading the 168bit key is not going to be brute forced anytime soon, but could i assume that if i were to get the real keys from somebody else that everybody else would have that same string because in the end the 3des key must be the same to decrypt it ?
Example:
User X Buys Feature "XXXX_YYYY" and gets Vendor String "ABCD"
User Y Buys Feature "XXXX_YYYY" and gets Vendor String "ABCD" also ?
Thanks.