Diamorphine: a loadable kernel module rootkit for Linux 2.6.x through 6.x

The problem Diamorphine solves, and the people it is written for

A rootkit is judged by what an administrator cannot see. Diamorphine's stated feature list is exactly that: the README says the module starts invisible when loaded, that any process can be hidden or unhidden by sending signal 31, and that files or directories beginning with MAGIC_PREFIX become invisible. Those three behaviours are the whole product. There is no management daemon, no configuration file, and no network listener.

The audience follows from the topics attached to the repository: pentesting, redteaming, advanced-persistent-threat, security-audit. This is a tool for someone who already has root on a Linux box and wants to test whether the defensive stack notices a kernel module that removes itself from the usual views. It is also a reading exercise. The repository is small (LICENSE.txt, Makefile, README.md, diamorphine.c, diamorphine.h), which makes it one of the few rootkits a person can read end to end in an evening.

It is not an exploitation framework. Nothing in the README describes privilege escalation from an unprivileged account, persistence across reboot, or a command-and-control channel. Loading it requires root and insmod, and the README says so plainly.

How the module hides itself, processes and files

Diamorphine is a loadable kernel module, so it runs in kernel space with the same privileges as the rest of the kernel. The Makefile builds it the standard out-of-tree way: obj-m := diamorphine.o, with KDIR pointing at /lib/modules/$(shell uname -r)/build. That single line ties every build to the headers of the kernel that is currently running, which is the constraint that shapes everything else about using the project.

The interface is signals rather than ioctls or a /proc file. Signal 31 toggles the visibility of a process. Signal 63, sent to any pid, toggles the visibility of the module itself. Signal 64, also to any pid, makes the given user become root. Signal numbers are a deliberate choice: they need no file descriptor, no device node and no userspace helper, so the module exposes no new attack surface in the filesystem namespace. The trade-off is that the interface is opaque. There is no status output, no log line, and no way to query the current state except by observing what other tools no longer show.

File hiding keys off MAGIC_PREFIX, a constant defined in diamorphine.h rather than a runtime setting. Anything whose name begins with that prefix is filtered from directory listings. Because the prefix is compiled in, changing it means editing the header and rebuilding, and the README does not document the prefix value itself; you have to read diamorphine.h.

Installing Diamorphine and hiding your first process

The README gives a five-step install. First confirm the kernel is in the supported range, then clone, enter the directory, compile against the running kernel's build tree, and load the result as root. The uname check matters because the Makefile resolves KDIR from uname -r at build time; building for a different kernel than the one you boot is not covered.

uname -r
git clone https://github.com/m0nad/Diamorphine
cd Diamorphine
make

make invokes the kernel build system through $(MAKE) -C $(KDIR) M=$(PWD) modules, so you need kernel headers or a full kernel source tree at /lib/modules/$(uname -r)/build. If that path does not exist, the build fails before any of Diamorphine's own code is compiled. On success you get diamorphine.ko in the repository directory.

insmod diamorphine.ko

Loading prints nothing to the terminal. From this point the README states the module is invisible, so a plain lsmod will not list it. To hide a process, the README says to send it signal 31, and the module also accepts signal 31 to reverse that.

The process stays alive and keeps its pid; it simply stops appearing in the process listings that Diamorphine filters. The README does not describe which listing interfaces are filtered, so treat the effect as scoped to whatever the source implements rather than to every tool on the system.

Removing it is a two-step procedure, and that is a real failure mode

The uninstall instructions are the part most likely to strand a user. Because the module starts invisible, rmmod diamorphine will not work first. The README says you must make it visible by sending signal 63 to any pid, and the example uses pid 0:

kill -63 0
rmmod diamorphine

If you lose the ability to send that signal, you cannot unload the module through the normal path. There is no documented fallback, no module parameter to disable hiding at load time, and no recovery mode. On a remote machine that is a genuine hazard: a mistake in the module's own code, a kernel panic, or a host that reboots into a kernel without the module means the only route back is console access or a reinstall. The README does not document rollback beyond the two commands above.

The second limitation is kernel version drift. The supported range spans 2.6.x through 6.x, which is a very wide window for code that touches internal kernel structures. Kernel interfaces that a module of this kind depends on have changed repeatedly across that range, and the README points to external write-ups on newer hooking methods rather than claiming the code is portable across every point release. A module that compiles on one 6.x kernel is not guaranteed to compile or behave on another, and there are no releases in the repository to pin against, so you are always building from the tip of master.

How Diamorphine differs from a userspace rootkit such as ld.so.preload tricks

The obvious alternative for hiding processes and files on Linux is a userspace approach: a shared library injected through /etc/ld.so.preload that interposes on libc calls like readdir and open. That technique never touches the kernel, needs no headers, survives on almost any distribution, and is removed by deleting one file. Its weakness is that it only affects dynamically linked programs that go through libc. A statically linked binary, a direct syscall, or a check from outside the process's own address space sees the truth.

Diamorphine sits below that line. Because it runs in kernel space, the filtering happens before the data reaches any userspace caller, so statically linked tools and direct syscalls are covered by the same mechanism. The cost is everything that comes with kernel code: a build that is bound to one kernel's headers, a load step that requires root and insmod, a real risk of panicking the machine, and an unload procedure that depends on the module cooperating. The userspace library is the safer experiment; Diamorphine is the more faithful one if the question you are testing is whether kernel-level hiding is detected.

Licence, maintenance and what a build actually costs you

The repository carries a LICENSE.txt at the top level, but the licence is reported as NOASSERTION, meaning the automated classification could not map it to a known identifier. Read LICENSE.txt yourself before you build it into anything you distribute; a kernel module links against the kernel, and the terms under which you may ship a derived module are a question for your own legal review, not something this article can settle. There is no homepage listed for the project.

The repository is not archived and the last push was on 2026-04-27, which is recent enough that the code is not abandoned. There are no retrieved releases, so there is no tagged version to depend on and no changelog to read between builds. Upgrading means pulling master and rebuilding against whatever kernel you are currently running, which is the same operation as installing. The maintenance cost is therefore low in effort and high in attention: every kernel upgrade on a machine that carries the module is a rebuild-and-retest event, and any change to the internal interfaces the module uses can turn a working build into a compile error with no upstream fix to wait for.

Editorial conclusion

Diamorphine belongs in a lab or an authorised red-team engagement on a kernel you are willing to reinstall, and it is the wrong tool for production hardening, for container workloads, and for any kernel whose headers you cannot match. Before you load it, verify the running kernel against the Makefile's KDIR path, confirm you can reach the machine out of band, and rehearse the kill -63 0 then rmmod diamorphine sequence, because a module that starts invisible cannot be removed by rmmod until you make it visible.

Frequently asked questions

Official sources

1. Issues
2. m0nad/Diamorphine on GitHub
3. README