Most userland EDR works by installing inline hooks at the top of interesting ntdll functions and inspecting the arguments as they go by. It is a reasonable design. It is also a design that lives entirely inside a memory space you control the moment you have code execution.
The hook
The agent rewrites the first few bytes of NtProtectVirtualMemory (and friends) with a jmp into its own inspection routine. Everything that calls the Win32 or native API is quietly routed through the agent first. Great for telemetry — right up until someone politely restores the original bytes.
Asking nicely
“Unhooking” is a grandiose word for reading a clean copy of ntdll from disk and copying the original .text section back over the hooked one. No exploit, no privilege escalation, just a memory copy the process is fully entitled to make. The syscalls it makes afterward are unmonitored, because the thing that was monitoring them is no longer in the path.
Why “trusted process” carries a threat model
The uncomfortable part is that from the kernel’s perspective nothing wrong happened. A trusted, signed process modified its own writable memory. The lesson is not that unhooking is clever — it is barely clever — but that a defense which lives in the same trust boundary as the attacker is a suggestion, not a control. Put the sensor where the attacker can’t reach it, or accept that it is decorative.