This section explains how to insert blocks of code to protect by Code Virtualizer in your applications (EXE), DLLs, OCXs, ActiveX, screen savers, etc. If you are protecting a device driver, please read here.
There are different ways to insert sensitive code blocks in your application:
•Via Inline assembly: A macro is just a definition of "dummy" machine code which is recognized by Code Virtualizer
•Via API call: A macro is a call to a function defined in VirtualizerSDK.dll. Code Virtualizer can recognize where a macro starts and ends by looking at this calls. The unprotected application will require the "VirtualizerSDK.dll" to run but once that you protect your application with Code Virtualizer, the linking with VirtualizerSDK.dll will be removed and you don't need to ship that DLL with your protected application.
•Via ASM module: You will link your application with a special Assembly Language file which defines some functions (with special code sequences on it). Code Virtualizer can recognize where you call those macros by looking at references to that special assembly language functions.
Code Virtualizer delivers a set of Include files for several programming languages. You just need to insert that Include file in your source code and you are ready to use the protection macros.
The VIRTUALIZER macro is the original name used in older versions of Code Virtualizer. In newer versions of our protection we recommend that you specify the name of the Virtual Machine that will be used to virtualize the code inside the START - END markers. For example, instead of using "VIRTUALIZER_START/END" for a block of code, you should select which Virtual Machine (from the Virtual Machine panel) will be used to virtualize that code (example "VIRTUALIZER_TIGER_WHITE_START/END")
We have also include a mutation macro (VIRTUALIZER_MUTATE_ONLY) which just mutates the code instead of virtualizing it. This macro has a very low protection compared with the above virtualization macros but it's suitable for specific code areas that does not require high protection but some obfuscation is desired. Also, the execution speed in VIRTUALIZER_MUTATE_ONLY macros is much higher than the virtualization macros.
Examples in C/C++ and Delphi
Here we show some real examples of using Code Virtualizer in C/C++ and Delphi:
LRESULT CALLBACK MainHandler(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam) { switch (message) { case WM_INITDIALOG:
VIRTUALIZER_LION_WHITE_START // the following block of code is protected under "Lion White" VM
if (WLRegGetStatus(NULL) == 1) { WLRegGetLicenseInfo(Name, Company, ExtraData); SetDlgItemText(hDlg, IDC_NAMEEDIT, Name); SetDlgItemText(hDlg, IDC_COMPANYNAME, Company); SetDlgItemText(hDlg, IDC_EXTRAEDIT, ExtraData); }
VIRTUALIZER_LION_WHITE_END // end of the block to protect
return TRUE;
case WM_COMMAND:
if (LOWORD(wParam) == IDCANCEL) {
VIRTUALIZER_FLY_WHITE_START // the following block of code is protected under "Fly White" VM
EndDialog(hDlg, LOWORD(wParam));
VIRTUALIZER_FLY_WHITE_END // end of the block to protect
return TRUE; } break; } return FALSE; } |
function TfmMain.GetCRC32(FileName: string): string; begin
{$I VIRTUALIZER_LION_WHITE_START.inc} // the following block of code is protected under "Lion White" VM
BuildCRCTable; CRC := $FFFFFFFF;
AssignFile(F, FileName); FileMode := 0; Reset(F);
{$I VIRTUALIZER_LION_WHITE_END.inc} // end of the block to protect
GetMem(Buffer, SizeOf(B));
{$I VIRTUALIZER_FLY_WHITE_START.inc} // the following block of code is protected under "Fly White" VM
repeat FillChar(b, SizeOf(b), 0); BlockRead(F, b, SizeOf(b), e); for i := 0 to (e-1) do CRC := RecountCRC(b[i], CRC); until (e < 255) or (IOresult <> 0);
{$I VIRTUALIZER_FLY_WHITE_END.inc} // end of the block to protect
{$I VIRTUALIZER_TIGER_RED_START.inc} // the following block of code is protected under "Tiger Red" VM
FreeMem(Buffer, SizeOf(B)); CloseFile(F); CRC := Not CRC; Result := '$' + HextL(CRC);
{$I VIRTUALIZER_TIGER_RED_END.inc} // end of the block to protect
end; |
Note for C/C++ developers
In the VirtualizerSDK.h file, you can find two special definitions:
#define CV_X32_INSERT_VIA_INLINE
#define CV_X64_INSERT_VIA_INLINE
With those special definitions, you can control if your macros will be inserted as inline assembly or as a API calls. We recommend that you insert macros as inline assembly for your 32-bit application and as API calls for your 64-bit application. Anyway, the protection is not related at all with the way that you insert macros.