Reliable kernel injection method for Win10 – EAC?

I am maintaining a private driver for fucking around a bit
in some BE/EAC games. I used to dual-boot to windows 7 as
the weaker PatchGuard allows easy loading of unsigned drivers.

Recently I spent some effort and managed to also make my drivers
work on Windows 10 (some TDL variant basically..).
Unfortunately exactly the same code of injecting seems to fail
there (only when injecting into a protected game, normal injection
into i.e. notepad works).

I basically only read/write memory from the driver and then use
KeInsertQueueApc on a “hijacked” thread to execute the dll initializers
and the dll entry point. I know that on Windows 7 EAC hooks
“KiUserApcDispatcher”, so I have some code in place to unhook
that api before calling. BE is even easier.

To debug I also unregistered their “ObRegisterCallbacks ”
and dumped the game, indeed I saw that they do not
even seem to hook the “KiUserApcDispatcher” api (ntdll) on
Windows 10. Still somehow my Apc-calls do not go through…

I know that hijacking threads is very delicate, i.e. it may
crash on threads without an ActivationContextStackPointer
and it makes problem on GUI threads etc, etc (I tried also
to use different threads but they all do not seem to work or crash the game).

Of course I can hook some API that is likely to be called
and hijack a thread that way but that would really be the
last resort… There must be some reliable way to run
remote code from kernel, or are we lost?

TLDR:
How are kernel apc calls intercepted on Windows 10 by EAC?
It seems to be a different method than hooking KiUserApcDispatcher, also they do not seem to hook any sub-functions. Maybe they place a hardware breakpoint or something?