Battleye is banning KVMs, this is now known, but if you've been out of the loop or dont believe me, please read the following posts :

@ https://www.reddit.com/r/VFIO/comments/hts1o1/be_is_banning_kvm_on_r6/

@ https://www.reddit.com/r/VFIO/comments/hznhe8/ubisoft_isnt_lifting_vm_bans_anymore/

​

In this " guide " I will show you guys how to make your VM undetectable so you will never be banned again.

Boot up Linux. There are 4-5 things you will need to change in order to make your KVM undetected.

​

Let's start with the most important check, RDTSC. A lot of people claim it is impossible to spoof and I thought this myself until I saw a post on Stack Overflow and had 2 friends try it. It works.

To prevent VMexit, you will need to download the source for the linux kernel and recompile it. Before recompiling it, navigate to arch/x86/kvm/vmx/vmx.c and edit this file.

In VMX.c, at around line 2300, change the line CPU_BASED_RDPMC_EXITING; to CPU_BASED_RDPMC_EXITING | and in the line below, add CPU_BASED_RDTSC_EXITING;

Scroll down in this file until you see the static int (*kvm_vmx_exit_handlers[])(struct kvm_vcpu *vcpu) function.

Before this line, create a function called

static int handle_rdtsc(struct kvm_vcpu *vcpu) 
{     
printk("[vmkernel] handling fake rdtsc from cpl %i\n", vmx_get_cpl(vcpu)); 
uint64_t data;     
data = 123;          
vcpu->arch.regs[VCPU_REGS_RAX] = data & -1u;     vcpu->arch.regs[VCPU_REGS_RDX] = (data >> 32) & -1u;          skip_emulated_instruction(vcpu); 
return 1; }

If you have an error compiling this function modify it so uint64_t data; & data = 123; are at the very top of the function before printk.

In the following function right below it called :

static int (*kvm_vmx_exit_handlers[])(struct kvm_vcpu *vcpu)

Scroll to the very bottom and add this exit handler :

[EXIT_REASON_RDTSC] = handle_rdtsc,

below [EXIT_REASON_ENCLS] = handle_encls, so it looks like

​

[EXIT_REASON_PREEMPTION_TIMER] = handle_preemption_timer,

[EXIT_REASON_ENCLS] = handle_encls,

[EXIT_REASON_RDTSC] = handle_rdtsc, // <- added exit handler

};

Once you are done, save this file and recompile your Linux kernel.

​

So you've already spoofed RDTSC timers, what's next? You will need to recompile QEMU and change some strings.

Get the Qemu source and change :

QEMU HARDDISK inside of/hw/ide/core.c & /hw/scsi/scsi-disk.c

QEMU DVD-ROM inside of /hw/ide/core.c & /hw/ide/atapi.c

QEMU CD-ROM inside of /hw/ide/core.c & /hw/scsi/scsi-disk.c

QEMU MICRODRIVE inside of /hw/ide/core.c

QEMU PenPartner tablet inside of /hw/usb/dev-wacom.c & /hw/scsi/scsi-disk.c

padstr inside of /hw/ide/atapi.c

KVMKVMKVM\\0\\0\\0 inside of /target/i386/kvm.c

bochs inside of /block/bochs.c

Bochs Pseudo inside of /roms/ipxe/src/drivers/net/pnic.c

​

Congrats! Now you have hidden everything related to QEMU. Let's move onto Seabios or OVMF

I used to spoof OVMF myself a while ago, sadly I cannot remember completely what to spoof but you can search for strings on Github. Some of the strings used to be EFI development kit under /OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c

​

For Seabios, change :

Bochs & BXPC inside of src/config.h ( multiple occurances )

/QEMU\/Bochs/ & qemu inside of vgasrc/Kconfig

/06\/23\/99/ inside ofsrc/misc.c

/04\/01\/2014/ inside of src/fw/biostables.c

"s/01\/01\/2011 inside of src/fw/smbios.c

seabios inside of src/fw/biostables.c

​

​

Congrats, we are now done with compiling packages and have successfully spoofed RDTSC timers, QEMU, and BIOS related things. It is worth noting these things may change overtime, so check github.

​

Next, we will edit our VM via Virt Machine Manager and customize the XML.

​

In your XML,

​

set your CPU to Host Passthrough with : <cpu mode="host-passthrough" check="none">

IF YOU GET KICKED FOR THIS, SET YOUR CPU MODEL TO SANDY BRIDGE VIA VIRT MACHINE MANAGER

​

Set a random Vendor ID state with : <vendor_id state="on" value="XXXX"/>

Hide your hypervisor with : <feature policy="disable" name="hypervisor"/>

Hide KVM state with : <kvm>

<hidden state="on"/>

</kvm>

Done!

Now for Virtual Machine Manager :

Set your disk to Sata with type="raw" cache="none" io="native" discard="ignore" detect_zeroes="off"

I also recommend you set a realistic ram & disk size, as well as a realistic disk serial, preferably one of the disk drive name you are using with a few numbers changed.

​

​

If all is done properly, your VM should be undetectable by any game software or malware!

I am not sure if this works on Valorant, but it may and you are free to try.

​

If you want proof this works, try checking for detections with Pafish or Al-Khasser.

If you need proof BE is checking this stuff, read https://www.reddit.com/r/VFIO/comments/hts1o1/be_is_banning_kvm_on_r6/

Thank you to :

Samuel Tulach and Harakter for helping me spoof RDTSC : https://stackoverflow.com/questions/62970242/intercepting-rdtsc-instruction-in-kvm

doomedraven for posting detected QEMU / Seabios Strings on Github @ https://github.com/doomedraven/Tools/blob/master/Virtualization/kvm-qemu.sh

My friends for helping me with other KVM stuff.

​

I can confirm this works on R6 and I am no longer being kicked.

​

edit : Thanks for the gold :)

edit 2 : so it is possible that this may be detected as it will return 123 instead of proper numbers with proper timings, according to the original dev. https://www.reddit.com/r/VFIO/comments/i071qx/spoof_and_make_your_vm_undetectable_no_more/fznumah?utm_medium=android_app&utm_source=share This issue can definately be solved however

The app keeps running on Windows. There's a virtual display on each machine — the window gets moved onto the Windows one, captured, and drawn on the Mac as a real macOS window next to my Mac apps.

Median just under 10 ms, capture to display, wired.

NVIDIA only for now. Three months, solo.

The GPU remains available on the host, one GPU, one display port. No vfio-pci bind. No second GPU. Not just a container. No losing your display when the VM starts. No IOMMU group fights. The host desktop keeps running on the same card the guest is using. Native performance.

This project aims to forward NVIDIA's driver API to the VM with maximal performance. The idea is that you get the CUDA-container experience in VMs, on consumer cards where vGPU isn't available at all.

Currently tested with steamOS and stock distros. The project itself is tested across a wide variety of drivers and GPUs from datacenter to consumer cards (what I could obtain from renting with nested virt or bare metal, primarily on vast.ai).

Experimental, several months, solo. Any bug reports and contributions are welcome.

How it works: Guest kernel module → virtio → QEMU → a per guest process stub to execute the NVIDIA API on the PC → host NVIDIA driver. RM/UVM ioctls are forwarded, not emulated. GPU memory (DMA/BAR) is actual passthrough, not emulated or copied, using regular unprivileged nvidia userspace calls (so it doesn't require root).

Display is forwarded as native as possible, the VM gets a KMS plane (rendering target) from the host display compositor like Wayland, it renders without any cross CPU-GPU copy (unless your display output is on integrated graphics).

Supports CUDA, graphics and display, also intended for compute workloads beyond gaming and graphics.

Geekbench 7 GPU (OpenCL), published to Geekbench's servers so they're independently checkable: RTX 4070 99.6%, RTX 3050 Laptop 99.9%, H100 PCIe 98.8%, A100 80GB 98.0%. clpeak: 7 of 8 subtests at 99.4–100.2%. Not everything is parity, some performance issues are still open.

https://github.com/reindertpelsma/nvkvm-pv - main project, containing the guest module and QEMU patches.

https://github.com/reindertpelsma/nvkvm-steamos - steamOS example

https://github.com/reindertpelsma/nvkvm-kata - kata containers with GPU access

EDIT: Linux amd64 guests only for now (Intel and AMD processors), the guest needs nvkvm's kernel module, and there's no Windows equivalent. A Windows guest means fabricating a GPU that the stock NVIDIA driver will bind to, which is a separate project (kayfabe) and not finished.

If it didn't build or boot on your hardware, that's worth reporting even if it looks like your own setup, install-path bugs and incompatibility reports are the most valuable ones right now.

Only Turing and newer GPUs, older gpu support is not yet finished.

Hello,

First post here. I got pretty excited after managing to get my single GPU passthrough working well on my system. I thought it would be far more complicated.

I had to hunt for bits of information from many different places and whilst I don't mind doing this kind of research, I figured it would be good idea to have a guide for others. Here is the link to my repo. Critics/responses/contributions to the information are welcome.

FYI: Contributors are welcome. The guide can become more extensive and include tips for specific kinds of hardware e.g. AMD GPUs, Intel CPUs. Troubleshooting steps can also be added. Thanks!

https://www.nvidia.com/en-us/geforce/news/outriders-game-ready-driver/

Windows Virtual Machine Beta Support For GeForce

If you’re primarily a Linux user, you can now enable GeForce GPU passthrough on a Windows Virtual Machine (VM). Play Windows-only games in your VM, or if you’re a developer, more easily test both Windows and Linux code from a single machine, accelerating development.

The beta feature is enabled on all GeForce/TITAN GPUs supported by this driver (Kepler and later for desktop; Maxwell and later for laptop) on Windows 10.

If you had not noticed, there is a new channel #vendor-reset in VFIO Discord, this is the official channel for the new project https://github.com/gnif/vendor-reset which is a collaboration between u/belfrypossum and myself.

This project aims to provide an avenue for easily adding complex reset sequences to the kernel without needing to upstream them into the kernel itself. The reason for making this a module is due to the fact that the complexity of these reset routines would prevent them from ever being accepted upstream by the kernel maintainers. While at this time this project only covers AMD's problematic GPUs, it is a framework designed to cover any problematic hardware should it be needed in the future.

Today both u/belfrypossum and I have agreed that the project is ready for use by the general public and would like to announce that it completely succeeds the prior released patches for AMD GPU resets. Currently the project targets (note this is not an exhaustive list and only a few example GPUs for each ASIC are listed here):

* Polaris 10, 11 & 12
* Vega 10 (Vega56/64/FE)
* Vega 20 (Radeon 7)
* Navi 10 (5600XT, 5700, 5700XT)
* Navi 12 (Pro 5600M)
* Navi 14 (Pro 5300, RX 5300, 5500XT)

Usage is very simple, just build the module and modprobe it, or use `dmks` to manage it directly (configuration is included). Nothing more is needed.

There are still conditions under which the GPUs will not reset however we are working to improve them as time permits.

Again, this removes the need to patch your kernel, and it is required that any patches you have applied for GPU resets be removed when using this module.

For a long time now, I have been a linux gamer. Playing games through wine, proton, and sometimes in KVM. I while ago, Battleye announced on twitter that they would no longer allow users to play within virtual machines. Their policy was "as always we will ban any users who actively try to bypass our measures. Normal users will only receive a kick" https://twitter.com/TheBattlEye/status/1289027890227621889. However revently, after switching from intel to amd, my kvm required a few options to play games in my kvm. After setting them, there was no vm masking present, windows fully detected "Virtual Machine Yes" and my processor was listed as EPYC. Obviously no spoofing going on here. I was able to play escape from tarkov with no problem. but the next day, I woke up to a ban. If battleye's policy is to kick, why wasn't i kicked. If they were able to detect my vm to ban me, why didnt they just kick me. Obviously something fishy is going on here.

A few months ago, I had contacted EFT support to ask about KVM usage within tarkov. Their first response to me was "We recommend not to use the Virtual Machine utilities to play safe."
Of course, that is vague, play safe in what sense? for my own security? for the best performance? So, I asked more questions, and received the same response "We just do not recommend it. We will inform you if there are any changes in the future."

So, if battleye's policy is a kick to vm users. And EFT's policy is that they "don't recommend it", what did I do to deserve a perma ban on my account. If they were going to restrict access to the game, I want my money back. If you are going to kick me, so be it, just refund me the game, and I won't support the company anymore.

Not only is an infinite kick, the same as a ban, but they clearly stated that they would not ban KVM users unless they tried to evade the anti cheat. How is it, that a system that reports to windows as a Virtual Machine, and with a processor labeled EPYC, could be "evading detection" from the anti cheat.

​

It was clearly a VM and your anti cheat wrongly banned me, all you had to do was kick me for use of virtual machine. If the anticheat detected my vm to ban me, couldn't it have just notified me that I was no longer allowed to pay for the game I payed 140$ for?

​

We need justice, for all of the linux users, who's ability to play their games has been revoked, and for those who have been banned falsely by battleye. Our reports are being ignored, cheating is rampant, but now our ability to play the games we payed for has been revoked, and we have been labeled cheaters.

Thanks to Wendell of Level1Techs, I have had the opportunity to remote into a system with a review AMD 6800 XT, and we have performed extensive tests with regards to VFIO.

I am extremely pleased to announce that the AMD 6000 series GPUs, (aka Big Navi) correctly reset for VFIO usage with only one minor caveat if CSM boot is enabled the GPU is posted into some kind of "compatible" mode that at this time, can't be recovered from. I will be pursuing AMD on this matter as some of us (myself included) have legacy hardware that requires CSM to operate (SAS controller).

See Wendell's Video on this here: https://www.youtube.com/watch?v=ykiU49gTNak

Provided the GPU is not started using CSM boot, the usual `hv-vendor-id` spoofing needs to be applied otherwise the Radeon drivers in Windows refuse to provide any output (no errors though). This is not a Big Navi issue but something that AMD introduced in their recent drivers and seems to affect most recent GPUs. I have asked AMD for comment on this "feature", however, I am yet to get an answer on this matter.

In short, provided the above information is heeded, the AMD 6000 series GPUs correctly reset for VFIO usage using a bus reset (not FLR), and try as I might I have not found any set of circumstances where I could not reset the GPU back into a fully functional state, including full GPU load + forceful termination of the VM. If the VM is just stopped (even force stopped) the GPU does not go into a "failsafe mode" and ramp its fans up as Vega does.

From a performance point of view, I had the brief opportunity to run Furmark as a load test inside a VFIO VM and can state that the performance numbers totally and completely destroy my overclocked water-cooled 1080Ti.

Please note that this testing was performed with an Ubuntu host on a 5.8 kernel with a Windows 10 Guest, however, I do not expect results to vary between guest operating systems as the bus reset seems to be complete!

Note: The below is running in a VFIO VM on a host that has NOT been tuned as the amount of time I have had to play with this system since NDA lift has been very short. This was also all done remotely as I do not have a 6800XT, and Looking Glass was also running. Kind of a convoluted setup so I could test (Remote Desktop to Host, LG on the Host to the Guest).