You can explicitly add a custom manifest resource to your protected application in case that it's not present in your unprotected application.
▪Add Manifest from XBundler files: Sometimes a bundled DLL (not extracted to disk) requires a manifest to operate correctly (for example, it requires admin's rights). If the DLL is bundled, that manifest is not seem by the operating system, so it cannot apply it before the application starts. This option extracts the manifest of the bundled files and apply them to the protected application.
▪Add Manifest from File: You can add any manifest information into your protected application from an external text file. If you require to extract the manifest from an external binary (EXE/DLL) you can use any PE file editor that can read/display the resources section and you can grab the manifest (in text format) from there. After that, just create a text file with that information and pass the path to that file into the "Add Manifest From File" option. This is an example of the content of a possible external manifest file to require admin's rights in the protected application:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<requestedExecutionLevel level="requireAdministrator" />
You can insert a splash image (JPG image) that will be displayed before your application starts (while the protection boot code is running). If you use a heavy virtual machine for the boot protection in the Virtual Machine panel, a splash screen is ideal to let your customers know that your application is booting up.
When the splash is displayed, there are several ways to close the splash screen, like Close on Mouse Click, Close after a number of seconds or close it from your code.
To close the splash from your own application, you can read the splash window from the environment variable SecureEngineSplashWnd. Once you get the splash window you can just send a WM_DESTROY message to that window. This is an example in Delphi:
WndStr := GetEnvVarValue('SecureEngineSplashWnd');
SendMessage(StrToInt(WndStr), WM_DESTROY, 0, 0);
In some cases or for specific applications, you can sacrifice some complexity in the protection ir order to gain extra speed or a smaller size of your protected binary. The following options help on that:
▪Favor speed over protection: This option reduces the complexity of the protection boot loader to increase the boot time in the protected application
▪Favor size over protection: This option reduces in minor degree the protection and uses a different compression algorithm in order to achieve a better compression
▪Optimize for Windows on ARM: The Windows on ARM emulation produces some penalties when emulating specific code or data accesses. This option produces a protection code that is emulated faster on Windows on ARM with just a small reduction in complexity in the protection code.