VMProtect "file corrupted" about scyllahide HOT 11 OPEN

Well the OS build number in the PEB can be changed with surprisingly few issues (changing OSMajorVersion or OSMinorVersion is more problematic because it's like running the app in compatibility mode, but that doesn't really apply here because the VMProtect people know that the build number is the only version number that's reliable enough to use). If you're dealing with a VMProtect packed exe then fudging the build number in the PEB seems like an OK tradeoff to me and probably fixes more issues than it causes.

What I see as the bigger problem is this: my build number is 7601. Let's say I change it to 7602 to fool VMProtect. That'll probably work for a while, until they get fed up with people like us and change the 'plain' build numbers list to a straight whitelist. That leaves only one fake option available, and that's whatever the current Windows 10 insider preview build is. Those are actual build numbers, plus they change like every other day because of MS's obsession with pushing updates, which is way too much for VMProtect to keep up with. Sounds great, right? Yeah, except Microsoft added a great new feature to KUSER_SHARED_DATA in Windows 10 that rats out your build number to VMProtect free of charge:

ULONG NtBuildNumber = *reinterpret_cast<PULONG>(0x7FFE0260);

Unlike the PEB this address can only be written to from kernel mode, and unlike syscalls we can't hook reading the value since it's just a pointer dereference. So that's the end of compatibility mode and fudging build numbers. Furthermore, if you say you're running Windows 10, the pointer above had better be valid or you've just outed yourself.

Man, I fucking hate Windows 10.

from scyllahide.

Update: as of 66ec9ad I can once again debug a fully VMProtected file (v3.3.1). But due to the way instrumentation callback hooks are implemented, this only works for x64, and better on Windows 10 than older versions. On Windows 7 I do see some improvement (the standard debugger detected message changes to "initialization error 1"), but only on Windows 10 does the hook fully bypass VMP.

I may look into WOW64 support in the future (this would be Windows 10 only), but I don't want to spend too much time on adding/maintaining this as there are several ways this hook can be detected. To be continued...

from scyllahide.

VMProtect makes use of direct syscalls (mov eax, xxx, syscall or x86 equivalent) based on your OS build number as of v3.x. This is basically unfixable in ScyllaHide due to it running in user mode. A suggesion that may work (but which I haven't tested) is changing OSBuildNumber in your PEB to a non-canonical value. If you're using Windows 10 this definitely won't work, see #51 for more info. If you're on another OS and it does work, don't expect it to keep working forever as the VMP people are of course bound to get wise to this. And there are ways to fuzz syscalls based on a few that return fairly unique error statuses, and based on this you can also make a pretty good guess of the OS version. So in the long term you're screwed either way.

Look at TitanHide for a kernel mode alternative if this is an option for you.

Re: your exception doing WoW64 debugging on Windows 10: this is probably the worst possible combination to use. There are hacks for x86, hacks for WoW64, hacks for Windows 10, and hacks for WoW64 on Windows 10 (all in the same file) and the general idea is basically to pray that god will sort it out. So there is definitely room for improvement there (or preferably, something more like a virtual nuke), but I don't know if anyone actually wants to do the work needed for this. I personally don't have any interested in this really (the WoW64 fixes for Windows 10 were contributed by someone else). Just making sure - you didn't happen to have 'query process cookie' set in x64dbg on the Windows 10 machine but not on the others? That setting is known to cause issues, but IIRC this was with NtQIP and not NtQSI.

from scyllahide.

new vmprotect does some tricks that scyllahide cannot deal with, see https://lifeinhex.com/use-of-syscall-and-sysenter-in-vmprotect-3-1/

from scyllahide.

@mrexodia Kao replied in his comment:"It can be done in ring-3 without patching any system files. I used Olly+modified ScyllaHide plugin to make that last screenshot in the blog post.". Hopefully, someone could submit a patch for ScyllaHide.

from scyllahide.

The issue is that the os version number gets all messed up so adding it probably won’t do any good

from scyllahide.

if there anyone who can help me also i am unable to hide OLLY with anything any settings under WIN7 X32 i have tried scylla,titanhide but always detected :( can not run

from scyllahide.

Getting this error also with Vmprotect 3.2
Also exceptions in a 32 bit environment.
Seems Scyllahide is not yet ready for vmprotect 3.2 ?

Tested with 32 and 64 bit vmprotect 3.2 protected exe
Env: win 10 x64 - 1809 / win 7 ult x86 / win 7 ult x74
Debugger : x64dbg (32 and 64 bits versions)

On W10 x64 debugging 32 bits gives an exception error (zwquerysysteminformation call)

from scyllahide.

Thank you for the explanation. I seems like VMProtect people finally defeated Scyllahide :(
I don't care not to use debugging WoW64 mode. I will just take another VM whichs is 64 or 32 bits.
Anyway, can you advise on how to change the buildnumber in the PEB.
Besides that, I will try titanhide as you mentioned.

from scyllahide.

To increment the OS build number in the PEB by one:
x86:

mov eax, fs:18h
mov eax, [eax+30h]
inc word ptr [eax+0ACh]

x64:

mov rax, gs:30h
mov rax, [rax+60h]
inc word ptr [rax+120h]

If you want to change other fields (e.g. OSMinorVersion as well if you're paranoid) it's probably easiest to just grab ntdll.h from either the ScyllaHide or x64dbg sources and do something like

NtCurrentPeb()->OSBuildNumber = 42;

changing the fields and values as needed.

from scyllahide.

from scyllahide.