Doubts regarding VMprotect checks

[Greatz08]

VMprotect does have 8-9 checks as per what u guided when its source code got leaked so my question to you is that have you implemented each of those checks which it performs for detection of vm in this project ? if yes then i wonder why i am not able to play marvel rivals which is VMprotected game. I pass all checks of this program in my vm so i wonder why its still able to detect vm.
Can you recommend some other tools to check for except al-khaseer and pafish as i clear pafish completely and almost al-khaseer too , so i cant figure out like what that game is still detecting so your guidance will be much appreciated . With hyper-v i can play tho with my advance settings but without it not possible yet unfortunately

[kernelwernel]

VMprotect does have 8-9 checks as per what u guided when its source code got leaked so my question to you is that have you implemented each of those checks which it performs for detection of vm in this project ?

Pretty much yeah, most of the techniques they use are already commonly found in the wild, and they're not obscure at all (like checking the hypervisor bit with cpuid for example)

if yes then i wonder why i am not able to play marvel rivals which is VMprotected game. I pass all checks of this program in my vm so i wonder why its still able to detect vm.

There could be a few reasons I could think of:

1. They probably have an RDTSC implementation which has a far lower threshold bar than what we have, and your system happened to flag it.

2. Maybe there is an oversight on our part with firmware tables which VMProtect also uses, but I doubt that's the case as we already implement that in the lib. They also heavily focus on VirtualBox, so if you're using a VirtualBox VM then maybe that could be the reason why (please let me know).

3. Perhaps they added more checks that we don't know about after the source code got leaked.

There's just not much information to go off on to determine why you got that result, and I can't confidently say why unless you could run a debug binary meant for development uses which will add additional outputs on the system's information. Maybe we missed a VM string key which VMProtect uses, I don't know. But if it's ok then I can share you the debug binary and you could share us the output to analyse why VMProtect could've detected a VM.

Can you recommend some other tools to check for except al-khaseer and pafish as i clear pafish completely and almost al-khaseer too , so i cant figure out like what that game is still detecting so your guidance will be much appreciated

Unfortunately there aren't any projects that covers as many VM detections as we do. Maybe Invizzzible could help but I think you'll receive the same result if I'm honest.

With hyper-v i can play tho with my advance settings but without it not possible yet unfortunately

Can you elaborate as to what you mean by advanced settings?

---

Additionally, can you tell us what your VM is? having NO checks passed is extremely rare for us, are you sure you ran it in a VM in the first place?

[Greatz08]

Pretty much yeah, most of the techniques they use are already commonly found in the wild, and they're not obscure at all (like checking the hypervisor bit with cpuid for example)

Nice good to know @kernelwernel

There could be a few reasons I could think of:
They probably have an RDTSC implementation which has a far lower threshold bar than what we have, and your system happened to flag it.
Maybe there is an oversight on our part with firmware tables which VMProtect also uses, but I doubt that's the case as we already implement that in the lib. They also heavily focus on VirtualBox, so if you're using a VirtualBox VM then maybe that could be the reason why (please let me know).
Perhaps they added more checks that we don't know about after the source code got leaked.

There's just not much information to go off on to determine why you got that result, and I can't confidently say why unless you could run a debug binary meant for development uses which will add additional outputs on the system's information. Maybe we missed a VM string key which VMProtect uses, I don't know. But if it's ok then I can share you the debug binary and you could share us the output to analyse why VMProtect could've detected a VM.

I have already patched my kernel to fix RDTSC detection :-), Plus i achieved it with QEMU and not virtual box or VMware and since i have patched QEMU so firmware table wont show QEMU or any virtual machine related thing :-)) so its not your fault i guess .
I feel the same that after their source code got leaked they must have added some more checks which i wonder what could they actually be. I will try to learn to debug VMprotect game exe and see what all things they do check and if i could achieve it i will definitely let you know.
If you by any chance are good at using x64dbg with ScyllaHide or Titanhide then please download Marvel rivals game and check for it and guide me as well like what and how you did it so that i can test on my part and let you know what was going bad with me.

Unfortunately there aren't any projects that covers as many VM detections as we do. Maybe Invizzzible could help but I think you'll receive the same result if I'm honest.

I was doubting myself of missing something valuable so thought to ask you about it no worries :-)

Can you elaborate as to what you mean by advanced settings?

By advanced settings i mean like patching qemu,ovmf,and hiding many things from vm using qemu options and not having any virtio or virtual machine related driver or registry and so more things.

Additionally, can you tell us what your VM is? having NO checks passed is extremely rare for us, are you sure you ran it in a VM in the first place?

Haha so get ready to witness my masterpiece :-))

This ports detection was the extremely tough to bypass but i did it and for this only we did have one discussion 2 days ago. If you remember or can go through that github discussion it was not showing any ports it was weird issue on my side because of which it should be showing but it wasnt i cant explain why it happened at that time but when i clean installed again with my new patch i fixed it and boom its 0/135 finally on vm finally
(btw do you know anyone else who achieved 0/135 ? )

[kernelwernel]

Pretty much yeah, most of the techniques they use are already commonly found in the wild, and they're not obscure at all (like checking the hypervisor bit with cpuid for example)

Nice good to know @kernelwernel

There could be a few reasons I could think of:
They probably have an RDTSC implementation which has a far lower threshold bar than what we have, and your system happened to flag it.
Maybe there is an oversight on our part with firmware tables which VMProtect also uses, but I doubt that's the case as we already implement that in the lib. They also heavily focus on VirtualBox, so if you're using a VirtualBox VM then maybe that could be the reason why (please let me know).
Perhaps they added more checks that we don't know about after the source code got leaked.
There's just not much information to go off on to determine why you got that result, and I can't confidently say why unless you could run a debug binary meant for development uses which will add additional outputs on the system's information. Maybe we missed a VM string key which VMProtect uses, I don't know. But if it's ok then I can share you the debug binary and you could share us the output to analyse why VMProtect could've detected a VM.

I have already patched my kernel to fix RDTSC detection :-), Plus i achieved it with QEMU and not virtual box or VMware and since i have patched QEMU so firmware table wont show QEMU or any virtual machine related thing :-)) so its not your fault i guess . I feel the same that after their source code got leaked they must have added some more checks which i wonder what could they actually be. I will try to learn to debug VMprotect game exe and see what all things they do check and if i could achieve it i will definitely let you know. If you by any chance are good at using x64dbg with ScyllaHide or Titanhide then please download Marvel rivals game and check for it and guide me as well like what and how you did it so that i can test on my part and let you know what was going bad with me.

Unfortunately there aren't any projects that covers as many VM detections as we do. Maybe Invizzzible could help but I think you'll receive the same result if I'm honest.

I was doubting myself of missing something valuable so thought to ask you about it no worries :-)

Can you elaborate as to what you mean by advanced settings?

By advanced settings i mean like patching qemu,ovmf,and hiding many things from vm using qemu options and not having any virtio or virtual machine related driver or registry and so more things.

Additionally, can you tell us what your VM is? having NO checks passed is extremely rare for us, are you sure you ran it in a VM in the first place?

Haha so get ready to witness my masterpiece :-))

This ports detection was the extremely tough to bypass but i did it and for this only we did have one discussion 2 days ago. If you remember or can go through that github discussion it was not showing any ports it was weird issue on my side because of which it should be showing but it wasnt i cant explain why it happened at that time but when i clean installed again with my new patch i fixed it and boom its 0/135 finally on vm finally (btw do you know anyone else who achieved 0/135 ? )

I looked up the VMProtect changelogs and yeah, 2 of their updates after the leak contains new VM detection checks. I’m not a reverse engineer though but I wish i can figure out what their new checks are. Must be interesting as hell.

As per the score, 0/135 is only achievable with VM hardening, but I assumed that wasn’t the case for you and thought you were running a pure VM with no customisation which is why I was surprised at first. I know a few people who managed to bypass the lib but those were older releases like 1.8 from months ago. You’re the first person to bypass the 2.0 as far as I’m aware.

[Greatz08]

@kernelwernel oo Nice , I haven't checked the changelogs but now will see if i can find from anywhere over internet about those recent changelogs . I am also interested in knowing about those vm detection changes if you find something then please do let me know buddy :-)) you already did great job in developing this tool and if we can know about it then this project can become better plus we will have new challenge to bypass those detection to no do anything wrong but atleast comfortably play game in better quality without having to leave linux environment.

I tried ScyllaHide with default and advanced setting to debug game but it detected debugger as expected so couldnt debug and understand what else it is trying to detect which i am missing (will have to learn more on titanhide which is i guess better and much tough to detect by games and see if i can debug it or not , Will let you know for sure if i find something interesting but me noob so cant expect much i guess haha :-)

As per the score, 0/135 is only achievable with VM hardening, but I assumed that wasn’t the case for you and thought you were running a pure VM with no customisation which is why I was surprised at first. I know a few people who managed to bypass the lib but those were older releases like 1.8 from months ago. You’re the first person to bypass the 2.0 as far as I’m aware.

Good to know :-))

[kernelwernel]

@kernelwernel oo Nice , I haven't checked the changelogs but now will see if i can find from anywhere over internet about those recent changelogs . I am also interested in knowing about those vm detection changes if you find something then please do let me know buddy :-)) you already did great job in developing this tool and if we can know about it then this project can become better plus we will have new challenge to bypass those detection to no do anything wrong but atleast comfortably play game in better quality without having to leave linux environment.

I tried ScyllaHide with default and advanced setting to debug game but it detected debugger as expected so couldnt debug and understand what else it is trying to detect which i am missing (will have to learn more on titanhide which is i guess better and much tough to detect by games and see if i can debug it or not , Will let you know for sure if i find something interesting but me noob so cant expect much i guess haha :-)

As per the score, 0/135 is only achievable with VM hardening, but I assumed that wasn’t the case for you and thought you were running a pure VM with no customisation which is why I was surprised at first. I know a few people who managed to bypass the lib but those were older releases like 1.8 from months ago. You’re the first person to bypass the 2.0 as far as I’m aware.

Good to know :-))

Sounds good! thanks for the feedback :)