You are right on the first point, but I don't think you are right on the syscall part - a kernel level module can just read the PT directly without resorting to a syscall, no? You get access to CR3, and besides kernel-level PTs have a fixed logical (and if memory serves, physical - though maybe just on windows) address.

When in the non-PAE mode, I think one can still practically trigger page faults on attempted reads on the PDEs mapped by a kernel-level aimbot, force flushing of TLBs when anti-cheat tries to read the PT, and effectively conceal the cloning (although if the anti-cheat is doing this often enough, the performance impact might be too much?).

When in PAE mode, I do not know of a practical way to do it, but I haven't been researching such exploits for a few years now.

I think at this point, the most practical way to implement an open-source, undetectable aimbot proof-of-concept would be to perform static reversing of the game engine to get the network protocol, peform a MITM to listen in and recreate state on a separate process or machine, do a PnP input injection via a real or fake mouse/keyboard.

Reversing the code (as opposed to memory structures) is very hard these days, though, and not because of anti-cheat software, but because of the high-end anti-piracy runtimes and layers upon layers of abstractions which are annoying to analyze in assembly. (But sure, not impossible, and I am sure people are doing this considering the crazy amounts people are willing to pay for private aimbots).

For a system programming geek its all very interesting and intellectually stimulating, but boy does it ruin the fun of multiplayer gaming :-( I think the best way to protect against cheaters would be to run streaming-only servers where all the processing happens server-side.