Since I don’t really know who can help me, I’m trying to find a solution here, so …
Situation is this: I have three boys who played Minecraft for years so I decided to introduce them to something where new skills are required (Apex legends).
I’ve been using ESXi for over a decade and decided to build a gaming ring for all three of them.
Those are W10 machines with GPUs in passthrough. Everything works fine: main VM gets 100+ FPS on 1440p, two lesser ones are at 90+ at FHD.
But, since recent update, game (easycheat actually) detects that it runs under VM and exits the game.
Speaking with EA and opening a ticket over e-mail didn’t resolve the issue since people just don’t understand what I am doing.
So the question is: under ESXi, how can I hide from easycheat that it is running on VM?
Windows doesn’t know, and I’ve tried all available VMX options that I’ve found, but nothing works (eg hypervisor.cpuid.v0 = “FALSE”, and all isolation commands I’ve found).
It doesn’t matter if VT-x is enabled for VM or not, Hyper V and VM support are disabled in Win.
Any advice is appreciated since the kids really like this game!
Can you check the output of the command systeminfo ?
If its lists anything obvious like vmware or uses default network devices,
it may be getting flagged by anti sandboxing code in the anti-cheat software.
Sysinfo should be clean, but I’ll check it. Removed all VMware “goodies” except networking adapter. Didn’t think of that. Will try and report.
Trying to find a solution I’ve also read that some people are using it for cheating
I understand that it is hard if not impossible to allow VM for specific users and they won’t put work in that for maybe ten people in the world doing that, but I just couldn’t figure out how it can tell if it’s running in VM but advice above is a good starting point …
It wouldn’t be very good anti-cheat software if it was just doing basic checks, and basic user-level ESXi settings would fool it into thinking a VM is real hardware. It’s likely doing complex things like checking how long certain system calls take to process versus others, to determine whether it has been run from a VM or bare metal.
E.A. isn’t going to take your word that you’re using VMs for legit purposes and not cheating unlike most others with a similar setup. Even if they did, they’re not going to work up a fix just for you.
You can either keep an eye on the shady corners of the net, looking for a crack for the anticheat software to be released (and hope you don’t get perma-banned from the game servers), or you can give up on gaming on VMs.
I ran into the same issue: My gaming PC has been a KVM guest on a rack-mounted host for a long time. I’ve been occasionally playing Fortnite, and recently it stopped working with both EAC and BattleEye.
It’s a cat and mouse game. No one knows exactly what they are doing to identify VMs, but so far it’s been a combination of looking at how devices and drivers present to the guest, as well as timing system calls like @rcxb explained. Every now and then there are workarounds, which quickly become useless after publication.
I am pretty sure it all comes down to money: Epic doesn’t want to spend on developing a solution that actually identifies cheats in a VM (it’s a difficult problem to being with), so they just ban them outright. It’s a bit of a cop-out, and I don’t know how long this strategy will work for them. VMs are becoming more popular, and it’s a bit presumptuous to assume that everyone should dedicate an entire machine for gaming. Though that is certainly still the norm, it may not be in a few years time.
To make matters worse, cheaters aren’t even using VMs anymore. You can get a Windows drivers signing certificate for a few hundred bucks these days, and it’s a much more effective cheating solution to just shim in a hacked driver.
I have decided to just vote with my own money and stopped playing the games that lock me out. I don’t need Fortnite in my life that badly
From time to time I still experiment, and what I can tell you is that both EAC and BattleEye seem to work with Hyper-V. Not sure for how long, but it might be a deliberate choice on their end to allow Hyper-V.
I remember back in October I had to make some changes to bypass EAC on my Windows VM.
Don’t know what the equivalent would be on ESXi but I had to add smbios mode='host' to my VMs libvirt XML which I believe makes the VMs hardware appear to be the same as the hosts.
<os>
<smbios mode='host'/>
</os>
I also had to switch my disk to the sata driver instead of virtio, because I guess EAC is checking if virtio drivers are running. Weirdly enough I still use the virtio driver for my NIC so maybe it’s only checking for disk drivers??
I had a chance to experiment with this over the weekend, but unfortunately could not get it to work. I hit a roadblock with the emulated LSI controller not working in UEFI and not finding Windows drivers for it. I am not sure that I would want to go that route to begin with - it’s supposed to very much negatively affect disk I/O in the guest.
Tried the SATA device, manually copying the smbios data from the host, setting NIC MAC address and E1000 device, qemu args as specified in the Proxmox forum post. Also tried hidden=1, turned off guest services, remove the qemu DVD drive, etc.
Try adding a new/secondary disk on an LSI controller, boot-up and let Windows install the drivers. Once that disk is working, you can change the controller of your primary disk.
The IO performance difference between PVSCSI and LSI SAS is reportedly modest, with PVSCSI preferred for reduced CPU usage at high IO rates. I doubt you’ll notice the difference outside of a heavily utilized server.
Thanks, that’s a good idea. Do you have any thoughts on why the UEFI firmware isn’t able to “see” any drives attached to the LSI SAS controller? It wouldn’t let me boot the VM from the controller. Wondering if the disk image needs to be initialized with a raid header or something like that.
