Why can a kernel-mode rootkit lie to a user-mode program but not the reverse?

## The one rule that organises the whole subject Concealment is directional. **A layer can lie to the layers above it, and never to the layers below it.** Everything else on this topic - why user-mode tricks are cheap and weak, why kernel implants are expensive and strong, why boot and firmware implants are in a different category again - falls out of that single sentence. The reason is compositional. Software does not perceive a machine; it asks a lower layer a question and believes the answer. Whoever *composes* the answer controls what the asker believes. ## User mode: rewriting one process's view A user-mode implant works inside a process's own address space. Two classic shapes: - **Import-table patching**: a program calls library functions through a table of addresses filled in at load time. Overwrite an entry and the call goes to the implant, which forwards to the real function and edits the result on the way back. - **Inline hooking**: overwrite the first instructions of the target function with a jump into the implant, which does its work and jumps back into the untouched remainder. Either way the deception is bounded by the process. A different process on the same machine, unhooked, asks the kernel and gets the real list. Even inside the hooked process, code that bypasses the patched function - issuing the system call directly rather than going through the library stub - sees through the lie. That fragility is exactly why user-mode hooking is the cheap rung: it costs no privilege beyond writing into the target, and it buys correspondingly little. ## Kernel mode: rewriting what the machine reports Move below the system-call boundary and the picture inverts. Kernel code is not a participant in the conversation; it is the party that answers. Two families of technique: - **Filtering the enumeration.** The implant interposes on the path that services a request - a filter driver in a stack, or an intercepted dispatch routine - and removes rows from the result before it is copied back to the caller. Every user-mode caller, hooked or not, gets the same edited list, because the editing happened before the boundary was crossed. - **Manipulating the objects themselves.** The kernel tracks live objects in linked structures. Unlink a process's entry from the list that enumeration walks, and there is nothing to filter - the process still runs, because scheduling uses different structures, but the walk that builds the answer never reaches it. The second family is the sharper illustration of the rule: the implant did not intercept a question, it edited the source of truth the question is answered from. ## Below the kernel: the same relationship, one rung down The kernel is not the bottom. A boot-chain implant runs before the kernel and decides which kernel image is loaded and with what patches applied - so the kernel's own integrity checks may be running in an environment their author never anticipated. Below that, platform firmware decides whether the boot chain is the one that shipped, and runs on the flash chip before any operating system exists. A peripheral's option ROM gets execution during platform initialisation for the same reason. At each step the newly-lowest layer can compose what the layer above believes about itself. This is why *level*, not *family name*, is the useful classification. Calling two implants both `rootkits` says nothing; saying one is a hooked library inside one process and the other rewrote the boot manager says everything about what each can and cannot control. ## The corollary you will be asked for If the rule is `a layer can only lie upward`, then a statement about a machine is worth exactly as much as the lowest level the adversary reached. Ask a compromised kernel to describe itself and you receive the answer the implant wrote. Any claim of a clean machine has to come from a vantage **below or outside** the implant: the storage read on different hardware, the platform's own hardware-rooted measurement of what executed, or simply removing the hardware from service. And the rule cuts the other way too, which is the part candidates forget. A user-mode implant cannot hide from kernel-level code, and a kernel implant cannot alter what the platform recorded about the boot before the kernel existed. Depth is a two-sided constraint: it is what makes an implant strong against everything above it and completely powerless against everything beneath.