|
| ▲ | Gigachad 4 days ago | parent | next [-] |
| Because anti cheat want's to verify that the highest levels of the system are not being tampered with. When contained within a VM it's impossible to tell if some cheating script on the host OS is reading or tampering with the game memory. Probably the only workable solution is for windows to provide some kind of secure game mode where the game and only the game runs and can have windows attest nothing else is running. But that anti cheat has no access to the data in the real work OS which is currently not running. Ruins multi tasking, but assuming you can switch over fast enough it might not be too bad. |
| |
| ▲ | thayne 4 days ago | parent [-] | | How does it know it is in a VM? Couldn't the host system make it look enough like real hardware, possibly with hardware passthroughs that the AC can't tell it is a VM? | | |
| ▲ | Gigachad 4 days ago | parent [-] | | It’s pretty complex. To start with, off the shelf VMs make absolutely no attempt to hide the fact that they are VMs but even if you do, there are tons of tricks you can do to work it out. Things like timing api response times, finding quirks in the emulation, boot chain attestations from the hardware, etc. |
|
|
|
| ▲ | kaladin-jasnah 5 days ago | parent | prev | next [-] |
| I've read that they specifically look for this by finding RDTSC timestamps, which would include (?) the overhead of the hypercall or something. |
|
| ▲ | dandersch 5 days ago | parent | prev [-] |
| It can work on a vm, but for Valorant specifically it seems that detecting a vm triggers the anticheat and gets you banned. I believe this is the case for most anticheats except VAC. You can try to evade the detection, but then you just enter the same cat & mouse game as a cheater. Whether allowing/disallowing VMs actually cuts down on cheaters? I don't know. |
