I’m building a Windows DLL on Linux and using VMProtect on Linux to protect the resulting DLL. But for some reason, some functions seemingly are generating address conflicts (see screenshot). The only way I can work around this is to turn off protection for the conflicting functions, which is not really something I’d want to do. Checking the load addresses, the functions clearly don’t use the same addresses, so this must be something internal to VMProtect. Doesn’t matter if I use Virtualization, or Virtualization + Mutation. This only happens when trying to protect the windows DLL. The Linux shared library version of the same code is working perfectly OK.
I saw another topic on the forum regarding this, but the thread contained no resolution information. How do I work around this issue?
Could you send us a test example (original DLL+VMP files) that shows your problem?
Certainly. Do you have an e-mail or FTP server I can upload this to? I saw build@vmpsoft.com being used by some others. Is that a valid target?
Please send to info@vmpsoft.com
E-mail sent. Thank you for your help!
Please try the 938 build.
The new version works perfectly! Thank you very much, I’m very impressed at the speed of your support!
Thanks 
)
I believe I’ve run into the same issue when trying to compile a Mac build of my library using VMProtect 3.1.2.938 on Linux. It’s not detecting the end marker and reading past the VMProtectEnd marker, resulting in multiple protected code segments overlapping. I’ve sent the binary to info@vmpsoft.com. If you could please take a look at this, I’d very much appreciate any help.
Try the 939 build.
Thank you. Now I can compile the file, but when I try to load the dylib into the application, I get this error:
dlerror:dlopen(.../mac.xpl, 6): no suitable image found. Did find:
.../mac.xpl: malformed mach-o image: segment .vmp1 file content overlaps segment .vmp
.../mac.xpl: malformed mach-o image: segment .vmp1 file content overlaps segment .vmp
I used the compilation defaults in VMProtect, just to make sure I didn’t break something on my own.
Just FYI, I’ve been able to get the dylib to load into the application when by disabling output packing in the VMProtect options. Is that a known limitation for dynamic libraries on Mac?
It just new useless checks in dyld:
https://opensource.apple.com/source/dyld/dyld-433.5/src/ImageLoaderMachO.cpp.auto.html
Thank you for clearing that up. Unfortunately I can’t change the library loading routines (they’re done by a 3rd application), so I had to disable output packing on Mac.
Try the 947 build.
Build 947 does something really weird. It seemingly replaces entire portions of the output binary with what looks like some stored binary blobs from the earlier versions of my compiled code. Quite how it does that, I do not know, but when I enable output packing on Mac, it behaves as if I had compiled an old version of the binary (probably the one I sent you). Are you shipping pieces of my code for replacement inside of VMProtect? That would seem like a very strange approach.
Do you really think that we store your old code in VMProtect? ) It’s not true.
Ok, just asking, because I have no idea where the old binary is coming from. But let me do some more digging in my build infrastructure, I’m sure it’s something on my end.