Hi, I do not know where to turn for help, so I am writing here. So sorry

[x64dbg]

Hi, I do not know where to turn for help, so I am writing here. So sorry

[Mattiwatti]

It took me a while to reproduce this, because at first I tried on Windows 10 (1903 to be precise) where it "just worked". On Windows 7 however, VMProtect's well-known manual syscalls kicked in because it has the syscall numbers hardcoded for that OS.

There is a bit of an issue here due to the fact that this is a DLL and not an EXE. The instrumentation callback in ScyllaHide is really only designed for regular executables. The problem with checking the return address against the loaded DLLs is that you'd have to whitelist specific system DLLs (not just ntdll) which gets messy quickly.

Regardless, I hacked something together that was "good enough" at least for this specific file, and the result was an access violation later on. The cause of this is VMProtect hiding its threads with NtSetInformationThread(ThreadHideFromDebugger), which unlike NtQueryInformationProcess(ProcessDebugObjectHandle) is something the instrumentation callback can do nothing about, since it is called "after the fact" and there is no way to reverse the ThreadHideFromDebugger flag: it can only be set, not unset.

What worked for me after applying above mentioned hacks: the standard VMProtect profile in ScyllaHide with ThreadHideFromDebugger additionally selected in TitanHide. I didn't see any ProcessDebugObjectHandle queries, but those may have been caught by the instrumentation callback. In that case you will also need to check that flag in TitanHide.

[Pyffbot]

Thanks a lot, it really works.
I'm very sorry that I distracted you.
I am very grateful to you.
I do not know whether to close the issues.

[Mattiwatti]

I'll leave the issue open: it is an issue in ScyllaHide because this DLL's protection can only be circumventend in combination with TitanHide. However I don't see any plausible way to fix this from user mode, so the issue will most likely remain open forever.

For people who don't want to disable PatchGuard/install a kernel mode driver, the best advice I can give is to run the latest version of Windows 10. VMProtect's syscall tables seem to be somewhat behind the times, at least right now.