Skip to content

Comment on Vanguard hits new 'bans-per-second' record

Comments

The reason they need “a method” to move the mouse is because Vanguard already outright rejects input from your non-primary peripheral device, and the reason I’m not disclosing that method here is because this is not a tutorial on fastest ways to get banned.

I know this isn't the lowest hanging fruit but for literally a few USD you could get the necessary hardware (i.e. any microcontroller, like a Raspberry Pi Pico) to emulate an input device with perfect fidelity. What do you do when a device pops up that has the same VID/PID as a real physical mouse and looks identical from the perspective of the HID reports? This is not theoretical FWIW.

I think the gameplan for anti-cheat developers is to just pretend they can't hear this, and to keep ramping up the amount of end-user surveillance for as long as possible. Good luck guys, looking forward to when the cheaters discover Arduino.

edit: Also, while I'm here saying unpopular things, this smarmy blog post gets a lot wrong about cheaters, probably on purpose just to piss them off. For example, something you'll notice with many cheating scandals is that routinely, extremely skilled players choose to cheat to try to get more of an edge, and they're better at it than unskilled players most of the time, too. I think the real reason why most cheaters suck is because the distribution of cheaters is probably mostly because most players suck and some portion of players are prone to cheating. If you need any evidence that cheating can easily become widespread at higher skill levels, check any speedrunning community with a sufficiently bad cheating problem, like Trackmania.

You do also need to have it act such as mouse. Since if you plug two Real Mouse in, only primary / first Mouse will work. If you Arduino its the cheat device Mouse, it will be plugged in first, you will not be able to click through menu or click play with your Real Mouse. You allowed one HID.

Most people lazy for this

Personally I assert that if you're already running a model to classify pixels on the screen to try to aim, passing through mouse movements from another mouse in addition isn't really a big deal.

If that was viable, they would have started with Arduino before trying DMA attacks.

One possibility: The Arduino added input latency cancelling out the cheating benefit.

If that was viable, they would have started with Arduino before trying DMA attacks.

I'm not describing something theoretical. I didn't use it for cheating, but I have in fact used an RP2040 to emulate an HID mouse and tried to make it look "invisible" from the other end. I don't have code posted to GitHub, but other people do have similar examples. If you wanted to get obsessive about it, it probably wouldn't even be hard to emulate vendor-specific proprietary behaviors, like whatever custom HID reports are used for things like mouse profiles and firmware updates. It requires a bit of reverse engineering, but nothing that crazy.

You can also just do it with a normal Raspberry Pi too, if it's one that has USB OTG support. This is how a lot of those Raspberry Pi KVM solutions send inputs without needing much external hardware.

Let's say you are still not convinced, and assume that this method is doomed to be detected somehow. One last thing: you could always hack up a real USB gaming mouse and rig the sensor up to a microcontroller or FPGA. That is substantially harder and more expensive, but I'm just trying to illustrate that if people are really driven to cheat and cheating is really a big expensive industry, this can be done.

One possibility: The Arduino added input latency cancelling out the cheating benefit.

I don't believe so, no. You don't have to stick to a specific hardware platform, but if there's one advantage that microcontrollers have over typical computers like Raspberry Pis it's latency. Even if their USB controllers are too limited or broken somehow, you can probably get away with bitbanging USB, especially on something with a nice and beefy microcontroller like the RP2350.

I believe the actual real reason why this wasn't a thing was because in the beginning for CV-based cheating, the CV part itself wasn't good enough. Now with computers having advanced a few more steps and with ML having advanced many many steps, being able to do very good classifiers in real time seems to be viable.

So really, the clock is ticking. There is no practical reason why the I/O part can't be done, so as long as the actual aimbot part works well enough. I'm willing to put my name on that.

The potential upside to pure usb cheating is much smaller than dma cheats, because it only gives you aim hacks, not wall hacks.

Even though that's true, the fact that pixelbot/colorbot type aimbots are still popular shows that they are perfectly effective. In fact, if you really want to remain undetected for long periods of time, "wallhack" style cheats have the obvious downside that someone analyzing the replays can easily see that you are routinely locking onto (nearly) the exact positions of enemies behind walls. This is inevitable even if you try to avoid it because without actually looking at the pixels on screen it's going to be hard for an aimbot to be pretty sure that you can actually "see" the target behind whatever obstacles or fog is on screen. This obviously can't happen if you are cheating using only the actual game output.

In the end, what matters to the cheater is being able to win, so if a pixelbot will do the trick and be less detectable, it's probably worth more rather than less. I believe it's just a matter of time before the pieces come together. (Of course, it has to actually be effective in order to really be worth more, but I think that's largely a function of how good the actual aimbot portion can be, and I really think with how good and fast ML has gotten you could really do a lot better these days.)

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.