External Module Loading

Previous Top Next

This documentation page is meant for developers who are familiar with EXEs & DLLs and want very precise control over what is loaded by Thinstall versus what is loaded by Windows.

Menu -> Options -> External Module Loading

This dialog allows you to control how Thinstall handles external DLL and EXE files.

External DLLs modified

The first tab, External DLLs modified, controls which DLLs will be modified by Thinstall after they have been loaded into memory by Windows to see the virtualized environment.
In some cases, a DLL may not be fully virtualized because its DllMain function executes before Thinstall has modified the DLL. Because of this, it is preferable to have Thinstall load the DLL completely by itself without Windows being involved. DLLs that are marked with the version information "Windows Operating System" cannot be loaded by Thinstall, and this approach must be used. DLLs that are loaded by Windows cannot have import references to virtual DLLs since Windows will try to resolve the reference and fail.




There are two list displayed:

·	Modify system loaded DLLs matching these patterns (if not banned)

This tab list patterns that will be tested against a DLL filename for a substring match.

Since \ matches all filenames, the default behavior for Thinstall is to modify every DLL loaded into your process. For best compatibility, performance, and security, we recommend limiting the number of external DLLs that are modified. In order for the virtual registry to work with COM controls, the minimum set of external DLLs include:

advapi32.dll

ole32.dll

oleaut32.dll

comctl32.dll

·	Do not modify DLLs matching these patterns.

If any pattern in this list is found as a substring of the filename, Thinstall will not try to modify the DLL in question. For example, if you specify c:\windows\system32\ Thinstall would not modify any DLLs loaded from from the system directory.

Patch External Exports - This option causes Thinstall to modify (in memory) the export tables for external DLLs. This approach can be used for ill-behaved DLLs that try to lookup system functions directly from memory addresses. For example, the Crystal Reports runtime requires this option to be set in order to work.

External DLLs loaded

This tab allows you to specify external DLLs which should be loaded by Thinstall instead of Windows. If a DLL (and all of its dependencies) are loaded by Thinstall, it may have import references that refer to virtual files. DLLs loaded by Thinstall will not be reported to a standard debugger such Visual Studio 6 and will not be visible to applications such as System Internal's Process Explorer. For .NET based debuggers, DLLs loaded in this fashion will still be reported to the debugger and you may set break points inside the DLL after the program has started.

·	Thinstall loads DLLs matching these patterns (if not banned)

Since all entries are macro expanded, one example would be "%InstallPath%\". This would cause Thinstall to load all DLLs in your application directory (and subdirectories).

·	Thinstall does not load DLLs matching these patterns (banned)

If any pattern in this list is found as a substring of the filename, Thinstall will not try to load the DLL in question. The banned list takes precedence over the matching list.

Presearch Paths

This tab allows you to add paths to look for DLLs before the standard system32, Current Directory, and PATH environment variable are consulted. This search path is slightly altered from the standard windows search path order. Thinstall automatically adds "%InstallPath%" to your project to allow multiple EXE packages to find DLLs located in %InstallPath% even if they are executed from alternate directories.

Thinstall search path order for DLLs is:

When LOAD_WITH_ALTERED_SEARCH_PATH is NOT specified to LoadLibraryEX:
1. The directory from which the current running EXE was loaded from (*)
2. Specified Presearch Paths provided by this dialog
3. The system directory (c:\windows\system32). This directory is returned by GetSystemDirectory()
4. The Windows directory (c:\windows). This directory is returned by GetWindowsDirectory()
5. The 16-bit system directory (c:\windows\system).
6. The current directory
7. The directories that are listed in the PATH environment variable

When LOAD_WITH_ALTERED_SEARCH_PATH is specified to LoadLibraryEX:
1. The directory of the specified by the referencing parent module. For example if a.dll references b.dll, Thinstall will search in the directory where a.dll is located.
2. Specified Presearch Paths provided by this dialog
3. The system directory (c:\windows\system32). This directory is returned by GetSystemDirectory()
4. The Windows directory (c:\windows). This directory is returned by GetWindowsDirectory()
5. The 16-bit system directory (c:\windows\system).
6. The current directory
7. The directories that are listed in the PATH environment variable

For more information about DLL Search Path order, consult the following MSDN documentation: Dynamic-Link Library Search Order
(*) - To comply with Windows standards, if your Thinstall package contains multiple EXE files, secondary EXE files may have a different search path from the starting EXE if they are located in different real or virtual directories.






External EXEs loaded

This tab allows you to specify external EXE files which will be loaded by Thinstall. EXE files which are loaded by Thinstall will have access to the virtualized environment. For example, they may load virtual DLLs, files, and access virtual registry keys. When you application executes process that matches the list specified, Thinstall will load the process instead of Windows. For best compatibility, you should limit the applications which Thinstall will load to a set of applications you have previously tested in Thinstall. Some applications may not function properly under Thinstall so it can lead to problems if any arbitrary executable may be loaded by your application.


.NET XML Serialization
.NET Applications that use XML Serialization (Web Services), will cause .NET to invoke csc.exe and cvstres.exe to compile generated C-sharp code. If you do not link the .NET Framework directly into your application, csc.exe may need to access byte code from your EXE or other linked DLL files. If csc.exe is not loaded by Thinstall it may fail in such situations, for this reason we include these EXEs for default new Thinstall project files.

·	Thinstall loads EXEs matching these patterns (if not banned)

Since all entries are macro expanded, one example would be "%InstallPath%\". This would cause Thinstall to load all EXEs in your application directory (and subdirectories).

·	Thinstall does not load EXEs matching these patterns (banned)

If any pattern in this list is found as a substring of the filename, Thinstall will not try to load the EXE in question. The banned list takes precedence over the matching list.

What options should I set?

The options that will be best for you depends on your programming language of choice and the 3rd party libraries you use. The options shown above work best for most people. Below are some suggestions that we have found work.

For best security: For best security, you want to eliminate all external DLL and EXE loading - this introduces points where hackers can inject their code into the virtual machine.

For best load performance: For best performance, you should limit the number of DLLs modified and loaded externally, as well as limit the number of external EXE files loaded.

For sticky problems: We have found a few cases where it is necessary to enable "Patch External Exports", for example the Crystal Reports 9 runtime for .NET.