Question BO7 — Troubleshooting 24h Delayed Bans and Driver Vectors

[byte_corvus]

Getting clapped by Ricochet with a delayed 24-hour ban is the classic signature of a flag being triggered by telemetry rather than an instant signature match. If you're running an external for BO7 and the hammer drops the next day, your logic is likely solid, but your stealth is non-existent.

Let's break down a specific stack and identify exactly where the anti-cheat is sniffing the trail.

The Current Setup

1. Loader: KDMapper using iqvw64e.sys (Intel NAL) to map a driver, cleaning PiDDB, MmUnloadedDrivers, and KernelHashBucketList.
2. Driver: Manually mapped, no .pdata, uses IoCreateDevice and a symbolic link with randomized names.
3. Communication: IOCTL with randomized codes and pool tags.
4. Features: CR3 walks (MmMapIoSpace) for memory, and MouseClassServiceCallback for aim input.
5. Usermode: Disguised process in %TEMP%, basic D3D11 transparent overlay.

The Critical Fail Points

1. IoCreateDevice Suicide
If you are manually mapping a driver and then calling IoCreateDevice, you are practically asking to be banned. Ricochet (and most modern ACs) enumerate device objects. When they find a device whose "DriverObject" points to a memory region that isn't backed by a legitimate entry in PsLoadedModuleList, it's an instant flag. You need to move toward a communication method that doesn't rely on a named device — look into data pointers, hook a legitimate driver's dispatch, or use shared memory.

2. The iqvw64e / KDMapper Trap
While everyone uses the Intel NAL driver, it's also the most watched vuln driver in existence. Even if you clean the lists, there are other traces (MSRs, remaining mapping artifacts). Consider moving to a custom exploit or a less public vulnerable driver. If you're sticking to KDMapper, ensure you are nuking the telemetry stubs properly.

3. MouseClassServiceCallback Scanning
Yes, Ricochet/Vanguard/EAC all scan the mouse stack. Walking the device chain and checking if the ClassDeviceObject pointer or the callback itself points to unbacked code is a standard check. If your handler is sitting in a manually mapped (hidden) memory region, you are dead in the water.

4. Overlay Detection
Using a transparent D3D11 window with WS_EX_LAYERED is 2015-tier technology. Ricochet can easily detect top-most windows with these attributes. It's time to start hijacking overlays. Look for legitimate processes like NVIDIA, Discord, or Steam and hijack their swapchain to present your frames.

Spoiler: Technical Flow & Code References

 // Example of why IoCreateDevice is risky in a mapped environment
 NTSTATUS status = IoCreateDevice(DriverObject, 0, &devName, FILE_DEVICE_UNKNOWN, 0, FALSE, &deviceObject);
 // If DriverObject->DriverStart is 0 or doesn't match an entry in PsLoadedModuleList, you're flagged.

Input Resolution:
Instead of hooking MouseClassServiceCallback, consider using hardware-based solutions like a KMBox or a custom HID descriptor if you want to stay external. For native controller support without remapping, you need to look into virtual bus drivers (like what DS4Windows uses) or direct XInput spoofing, though Ricochet is increasingly sensitive to virtual controllers.

Quick Advice for the Next Build:

1. Ditch IOCTL: Stop creating system device objects. Use a communication hook (e.g., function pointer in a legit driver).
2. Kernel Memory: MmMapIoSpace is generally safer than MmCopyVirtualMemory, but don't leave the mappings hanging.
3. Input: If you can't go hardware, at least use a method that doesn't point directly to your unbacked memory region.
4. Clean EVERYTHING: Ricochet is aggressive with disk forensics. Randomized service names in %TEMP% are better than nothing, but still suspicious if the entropy is high.

Anyone else noticed an increase in delayed bans involving the CR3 walk method lately?

Drop your thoughts below—let's see if we can narrow down the latest Ricochet telemetry changes.