Pre-purchace questions

[mtx-electronics]

I'm evaluating various protector apps. because I want to upgrade to something that is more flexible with respect to my current product and enigma seems to be the most feature packed app in it's category. I do have a few last questions before I buy:

- What's the status of your virtualization features at this moment? How strong is this really and have you taken any action to stop reverse engineering of this since the last auto unpackers have been released? To me virtualization seems to be one of the best new technologies to stop cracking but if your opcodes have been decoded then it's useless. Have you thought about maybe using some way of random generation of opcodes so every protected file will be different?

- With my current protector I use the equivalent of your Reg_Crypt markers and this is obviously a good approach to protecting sensible information. Usually what I do is create 3 different sections for the levels of registration, is it possible to have the activation key hold decryption information for more then 1 section? Say that I want to give a full license user the possibility to use all code from section 1,2 & 3... but simple license user to only have access to code from section 1.

- Can virtualization & Reg_Crypt markers be used simultaneously on the same code? and is this approach any good to strengthen virtualization?

- Your software v3.80 was cracked very fast and you already said in another post that you were fixing this issue... Is the newest release fixed?

- Do you think your application can offer better protection to reverse engineering compared to asprotect? I know this is not an easy question to ask, obviously your product is the best but maybe if you can give a more technical reply backing your point of view.

Thanks.

[Enigma]

Hi mtx-electronics,

- What's the status of your virtualization features at this moment? How strong is this really and have you taken any action to stop reverse engineering of this since the last auto unpackers have been released? To me virtualization seems to be one of the best new technologies to stop cracking but if your opcodes have been decoded then it's useless. Have you thought about maybe using some way of random generation of opcodes so every protected file will be different?

There are more words about autounpacker than a real tools. If anybody succeeded with it in work I would be highly appreciated for the advice of it's usage.
Anyway, since version 3.80 there are being started adding of new virtual machine that does not have tools for de-virtualization.
And the core protection will be improved from version to version to be stronger.

- With my current protector I use the equivalent of your Reg_Crypt markers and this is obviously a good approach to protecting sensible information. Usually what I do is create 3 different sections for the levels of registration, is it possible to have the activation key hold decryption information for more then 1 section? Say that I want to give a full license user the possibility to use all code from section 1,2 & 3... but simple license user to only have access to code from section 1.

Reg_Crypt markers exactly allow same scheme. In the keys generator you may enable/disable the necessary section to activate necessary number of Reg_Crypt marker (for eg, section #1 in key unlocks RegCrypt1 marker).

- Can virtualization & Reg_Crypt markers be used simultaneously on the same code? and is this approach any good to strengthen virtualization?

Unfortunately no yet, but planning to make this ability soon.

- Your software v3.80 was cracked very fast and you already said in another post that you were fixing this issue... Is the newest release fixed?

Yes, in the newest release it is fixed.

- Do you think your application can offer better protection to reverse engineering compared to asprotect? I know this is not an easy question to ask, obviously your product is the best but maybe if you can give a more technical reply backing your point of view.

Oh, unfortunately, I do not want to discuss this in public (nor disadvantages or this protection, nor advantages of our compared to their), AsProtect is our competitor. The only thing I can promise you - continuing of the development and improvement of our protection, adding new features and improving existing.

[mtx-electronics]

I have two last questions:

1) Do you suggest using virtualization or Reg_Crypt as a better means of protection for sensible code? The definition of "sensible code" is maybe a little to generic but I would be interested in your opinion for:

- Code that has to do with registration scheme;
- Code that holds intellectual property that you would like others not to see.

2) For win32 apps I normaly use Borland C++ Builder 6 or Mingw32 (crossplatform compiling from linux using WXWidgets library). For BCB I'm sure it's not a problem but what do you think about the second scenario, will I be able to compile the app with anigma libraries under linux and later process/test it on windows with the protector?

[Enigma]

1) Do you suggest using virtualization or Reg_Crypt as a better means of protection for sensible code? The definition of "sensible code" is maybe a little to generic but I would be interested in your opinion for:

Instead of using RegCrypt markers I recommend to use the option Registration Features - Common - Encrypt with Encryption Constant. It encrypts whole application, with the similar way as RegCrypt does for a part of the code.
Since using this option makes application impossible to run without valid registration key, you should have two versions - full (available for registered customers only) and demo (public version, it could be not protected at all, but just miss some functionality, eg).
To check what sections are enabled in the key, you may use the function EP_RegKeyInformation.
Of course, you should use VM Makers for all "weak" code.

2) For win32 apps I normaly use Borland C++ Builder 6 or Mingw32 (crossplatform compiling from linux using WXWidgets library). For BCB I'm sure it's not a problem but what do you think about the second scenario, will I be able to compile the app with anigma libraries under linux and later process/test it on windows with the protector?

No, of course no. Enigma Protector does not provide any library, it provides functions to communicate with protection. After protection of the file, no any library is necessary for it.
And also, Enigma Protector supports only Windows executable files, Linux is not supported.

[mtx-electronics]

Instead of using RegCrypt markers I recommend to use the option Registration Features - Common - Encrypt with Encryption Constant. It encrypts whole application, with the similar way as RegCrypt does for a part of the code.
Since using this option makes application impossible to run without valid registration key, you should have two versions - full (available for registered customers only) and demo (public version, it could be not protected at all, but just miss some functionality, eg).
To check what sections are enabled in the key, you may use the function EP_RegKeyInformation.
Of course, you should use VM Makers for all "weak" code.

Ok, if I use the encryption constant option the whole app will be encrypted. Do the 16 possible sections all use the same decrypt key or does the registration key have a decrypt key for every section? I would not like to have an advanced cracker buy a basic license and then use that key to decrypt all sections.

No, of course no. Enigma Protector does not provide any library, it provides functions to communicate with protection. After protection of the file, no any library is necessary for it.
And also, Enigma Protector supports only Windows executable files, Linux is not supported.

Ok, but don't these function have a library (.lib) file or something that is used by the linker during compilation? If this .lib file is compatible with mingw32 compiler under windows then it might be possible compile on linux too. The application will always be used under windows OS, just compiling would be done on Linux.

One last question ( really this is it ) Is there a way to encode some extra information into the key that I can access later?

Sorry for all my questions but as I'm reading your online help new things come in mind.

[Enigma]

Ok, if I use the encryption constant option the whole app will be encrypted. Do the 16 possible sections all use the same decrypt key or does the registration key have a decrypt key for every section? I would not like to have an advanced cracker buy a basic license and then use that key to decrypt all sections.

Yes, all sections are using same encryption key as this option. Just imagine, the key is very short, how it would be possible to store 16 different encryption keys inside it?

Ok, but don't these function have a library (.lib) file or something that is used by the linker during compilation? If this .lib file is compatible with mingw32 compiler under windows then it might be possible compile on linux too. The application will always be used under windows OS, just compiling would be done on Linux.

Ok, there are lib files, but these are used just for compilation and for debugging. When you just compile your application, then yes, it will be using enigma_ide.dll and won't run without this dll. But, after protection, the protected file won't require this dll (because all Enigma API functions will be redirected inside protection).
These lib files, and enigma_ide.dll are empty files, the functions it contains return nothing and are used for debugging of non protected file only.

And even if you compile Linux version, how do you protect it? No ways.

One last question ( really this is it ) Is there a way to encode some extra information into the key that I can access later?

Sure, the solution is very curious from the first look. You may encode any data inside Registration Name field. Then, by calling the function EP_RegLoadKeyEx you may get registration key and extract all necessary information from it.

Sorry for all my questions but as I'm reading your online help new things come in mind.

No problems, I'm very glad to reply!

[mtx-electronics]

Yes, all sections are using same encryption key as this option. Just imagine, the key is very short, how it would be possible to store 16 different encryption keys inside it?

With my current protector what I do is have 3 sections and with the keygen I generate different keys that will unlock only one section each key. I supply the key to the user based on the features I want him to use.

And even if you compile Linux version, how do you protect it? No ways.

I would compile on Linux and protect in windows. I have Linux installed on all my computers and use windows with virtualbox only for few applications.

Sure, the solution is very curious from the first look. You may encode any data inside Registration Name field. Then, by calling the function EP_RegLoadKeyEx you may get registration key and extract all necessary information from it.

Never thought about this simple but effective solution.

[Enigma]

With my current protector what I do is have 3 sections and with the keygen I generate different keys that will unlock only one section each key. I supply the key to the user based on the features I want him to use.

No problems, you may use RegCrypt markers in the same way as you are doing with the current protection. This functionality is same in both protectors.
But if case you would not use RegCrypt markers, you may also use EP_RegKeyInformation function to extract the sections information from the key.

I would compile on Linux and protect in windows. I have Linux installed on all my computers and use windows with virtualbox only for few applications.

If so, no problems.