I’m using VMProtect Lite to protect a native function inside a C++/CLI (/clr) DLL, and I’d like to confirm whether the behavior I’m seeing is expected due to mixed-mode assembly limitations.
Setup:
- The project is a Visual Studio C++/CLI project (compiled with /clr), targeting x64.
- The function I want to protect (native, non-managed code, wrapped with #pragma managed(push, off) / #pragma managed(pop)) contains marker calls:
VMProtectBeginVirtualization(“Something”);
…
VMProtectEnd(); - I confirmed with dumpbin that the final DLL’s Import Address Table correctly contains VMProtectBeginVirtualization and VMProtectEnd (imported from VMProtectSDK64.dll), so the calls are present in the compiled binary.
- I also calculated the exact RVA of the function’s entry point from the linker MAP file and the module’s image base, and verified it against the VA/RVA reported by dumpbin /headers.
Problem:
- When I load the DLL into the VMProtect Lite GUI, the function does not appear in the marker-detected function list.
- Manually adding the function via “Add Function” using the calculated RVA/VA also fails - the function does not appear in the list or get added at all.
Question:
Is this happening because VMProtect treats this DLL as a “mixed-mode assembly” (i.e., a native PE that also contains a CLR/COR20 header from the /clr compilation) and therefore skips or restricts the native code analysis/marker-detection and manual “Add Function” logic for such files?
If mixed-mode assemblies are indeed unsupported for function marker detection and manual address-based addition, could you confirm this so I can plan a workaround (e.g., moving the protected logic into a separate pure native, non-/clr module)?