Any speculation as to how this worked on a lower level ?
There are multiple ways to detect this. Hardware breakpoints were already mentioned, but they only work per thread, so if one is sniffing on your memory from another process or the kernel then these won't help.
The most stealthy and evil way I found was to allocate a page but never actually use it.
Windows lazily allocates physical memory for fresh memory pages when they are first used.
The detection is to periodically poll the page map from your process and check your canary pages via NtQueryVirtualMemory. If your unused page suddenly is backed by some physical memory then something happened to read from it! Bonus-points for putting such canary pages into places previously used for real game data.
This method is not foolproof: Anti-virus programs can read memory of all programs (but don't, Overwatch e.g. does not like this and crashes randomly due to this exact protection method). A bug in the program could also read from the page accidentally (e.g. out-of-bounds array read). But it's a /very/ good indicator that something is wrong when other cheat detection mechanisms also trigger.
Once you know how this works it's pretty easy to defeat unfortunately: Read the page map first, then avoid reading pages that have no backing physical memory, because those contain no useful data at best and are canary pages at worst.
Antivirus was a concern but easily solved by the fact that cheats access memory many times a second, antivirus does it rarely if ever.
(Jokes aside, the kernel does not provide any information about which application reads a canary page. It's best to just use this as necessary condition and take it with a good pinch of salt.)
Obfuscation and deobfuscation is also super interesting. I think overall reverse engineering and figuring out how things work is one of the most interesting things in computer science.
https://github.com/obfuscator-llvm/obfuscator/tree/llvm-4.0/...
https://blog.quarkslab.com/deobfuscation-recovering-an-ollvm...
It took like a decade before anyone noticed, but all screenshots were very very very slightly modified to hide (in plain sight) a blob of data that gave the account name, date, time, server, etc.
Just in case a screenshot ever got posted and they really needed to know who took it and when.
Leaking user data to me is a betrayal of trust, incredibly distasteful, and probably borders on illegal (it ought to be imo). Note that this is fundamentally different than watermarking streaming content or other material that the user is not legally permitted to copy. Watermarking the game binaries themselves, for example, would be entirely different and perfectly acceptable from my perspective.
This trick is used to catch cheaters on minecraft, by spawning in fake diamond blocks that would only be visible to specific cheats (xray). If a user suddenly were to dig to these blocks, you can be reasonably certain there's something fishy going on.
Other way to think about it, is adding an invisible field to a contact form that is only hidden through CSS
Watch out for autocomplete though.
do current browsers not prevent this by only filling in credit card numbers when that particular field in focus?
Whenever I focus on a CC field and autocomplete Chrome throws up a biometric auth before it will fill out the textfields
https://learn.microsoft.com/en-us/windows/win32/memory/creat...
Of course, there's plenty of detection techniques for VMs too.
It can just be something exposing a data structure that gives the player some unfair advantage and them watching the players that could only have achieved some very unlikely advantage in the game by exploiting this information.
In a FPS for example, if a player consistently anticipates their adversaries sneaking behind a wall, well beyond what would be dictated by probability laws, there's a very high chance that he is cheating in a way that allows him to "see" their adversaries behind walls.
Specifically - I wouldn't fancy writing the "consistently anticipates their adversaries sneaking behind a wall" heuristic you describe but the earlier post describes the API that already exposes the "has read canary page" functionality.
I know it only from stories, so forgive me mistakes.
So basically
action X at patch Y sends instruction Q1
and then
action X at patch Y+1 sends instruction Q2
but cheating/botting software when ran straight after the update still sends old instruction Q1,
which is now impossible to be generated by legit player and this way you can instantly mark player as botter.
but I think it cannot be it since modern cheaters wouldnt be this stupid, right?
you might not trigger the cheater-flag on a single access (because of, as mentioned, antivirus etc.) but if your page gets accessed over and over again, you can be quite certain that someone is reading it who probably shouldn't...
to be clear, this was not a honeypot, but they claimed it to be
_edit_
To whoever downvoted me later - I would consider it a bug if it was user settable without cheats. Similarly you could see trough smokes in CS for a long time by changing some video settings. You don't (usually) ban people for bugs.
struct player_info {
std::string name;
vector4 position;
vector3 orientation;
int level;
...
}