Protection beyond standalone executables
Protect Windows DLL and ActiveX OCX Components
Libraries and ActiveX controls cannot be treated exactly like ordinary EXE files. DotFix NiceProtect protects native x86 and x64 DLLs and OCX components while accounting for relocations, loader behavior and component-specific executable structures.
Why libraries need a different protection strategy
Windows can load a DLL or OCX at different virtual addresses. Its relocation data, exported entry points, initialization code and host-process interaction must remain valid after protection. A fixed EXE-oriented loader design is not sufficient for every component.
NiceProtect can generate relocation data for both protected code and generated code, or use an alternative loader strategy when the file’s structure calls for it. Protected EXE files also retain DEP and ASLR compatibility; separate x86 and x64 protection engines account for each architecture’s relocation and loader requirements.
Protection available for Windows components
Native x86 and x64 DLLs
Apply packing, anti-analysis layers and supported code transformations while preserving architecture-specific loader requirements.
ActiveX DLL and OCX files
Protect COM/OLE components, including files that carry Type Library information and are loaded by another application.
TLS callbacks
Preserve multiple service or application-defined Thread Local Storage callbacks instead of assuming that only one compiler callback exists.
MAP-based function selection
Use a matching compiler MAP file to select native functions for x86 or x64 virtualization and mutation.
Protect ActiveX controls without treating them as ordinary EXEs
OCX files expose component interfaces and are hosted inside another process. NiceProtect’s component support is designed around those loading conditions rather than simply wrapping the file with a generic executable packer.
The NiceProtect architecture article explains the relocation strategies used for DLL and OCX protection and illustrates both component types.
Validate the component in its real host
Use the trial with the same DLL or OCX build, host application and operating-system architectures that you plan to ship. Exercise initialization, exports, registration, COM activation, callbacks and application-specific integration before releasing the protected component.
Practical scope: support for the file type does not guarantee that every third-party framework, custom loader or non-standard PE layout will behave identically. Test the resulting component in its actual deployment environment.
Test your DLL or OCX before choosing a license
Open the actual component, review the detected structure and verify its protected build in the host application.