<< Click to Display Table of Contents >> Navigation: WinLicense > FAQ > Macros > What does it mean that my encrypted string are not removed from the original location? |
When a string is referenced from inside a STR_ENCRYPT macro or from a VM macro (when using the option Encrypt Strings in VM macros), the protection redirects the pointer to the string to a location inside the protection code and copy the string in that location (in an encrypted form). As the original location of the string is not referenced after being protected, the original string is patched with zero values.
In some cases, the same string is also used in a different location in your application code and due to compiler optimizations, the string is only stored once.
LRESULT CALLBACK MainHandler(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam) { switch (message) { case WM_INITDIALOG:
STR_ENCRYPT_START
printf("Hello World"); // "Hello World" string found and redirected the pointer inside "printf"
return TRUE;
STR_ENCRYPT_END
break;
case WM_COMMAND:
printf("Hello World"); // The "Hello World" string is referenced here again, from outside a STR_ENCRYPT marker
break; } return FALSE; } |
In the above example, as the "Hello World" string is also referenced from another location (outside of a STR_ENCRYPT marker) the protection cannot remove the original string "Hello World" from its original location, as it will be later referenced by a different code. In this case, there is an encrypted "Hello World" string that is referenced by the code inside the STR_ENCRYPT marker and an unencrypted "Hello World" that is used in a different code location.
In some cases, you only use a specific string one time inside the STR_ENCRYPT marker, but the string is not removed. The reasons could be:
•Your compiler is creating a pointer to the string in a different location in your application. Probably the linker is using a table of symbols that contains the pointer to all your strings
•There is a special code or data sequence in your application code that matches exactly an offset to the original string. In this case, this is not a real access to the string, it was just a coincidence that a specific code sequence matched the pointer to the string
If you are sure that there are no more access to the specific string (or to overcome the two above situations), you can go to the Advanced Options panel and add the following option:
OPTION_MACROS_ENCRYPT_STRINGS_FORCE_DESTROY=YES