Diamorphine is a loadable kernel module rootkit for Linux 2.6.x through 6.x on x86, x86_64, and ARM64, used by defenders and researchers to study kernel-mode stealth techniques in isolated labs.
| Tool | m0nad/Diamorphine — LKM rootkit for Linux kernels 2.6.x–6.x (x86/x86_64/ARM64), written in C |
| Category | Kernel-module rootkit / security research and training artifact |
| Primary Use | Studying kernel-mode hiding techniques — process hiding via signal 31, module visibility toggling via signal 63, privilege escalation via signal 64, and file hiding via MAGIC_PREFIX — inside authorized lab VMs |
| Safe Use | Strictly for authorized security training, rootkit-detection research, and isolated lab experimentation; never deploy on systems you do not own or administer |
| Telemetry Note | Kernel-level hooks and hidden modules are observable via integrity checking of kernel structures, module-list cross-validation against sysfs, eBPF-based monitoring, and memory forensics tooling; signal-triggered kill() patterns are detectable anomalies |
Diamorphine, hosted at m0nad/Diamorphine and written in C, is one of the most widely referenced educational loadable kernel module rootkits in the Linux security community. With roughly 2,487 stars on GitHub and a lineage stretching across kernel versions 2.6.x through 6.x on x86, x86_64, and ARM64, it occupies a distinctive niche: it is simultaneously a live demonstration of kernel-mode stealth tradecraft and a canonical test target for defensive tooling. This writeup treats it as a documentary subject for authorized professionals — an artifact worth understanding because it distills decades of LKM rootkit technique into a few hundred lines of readable kernel code.
Architecturally, Diamorphine is a textbook example of what happens when an attacker obtains the ability to insmod a module into a running kernel. Once loaded via insmod diamorphine.ko, the module immediately removes itself from visibility — the README states plainly that it "starts invisible" when loaded. That single design decision matters for defenders: the usual lsmod-based inventory of kernel modules becomes unreliable the moment kernel-mode code has executed, which is why integrity-based and cross-referencing detection approaches exist at all.
The tool's control interface is signal-based, which is an elegant and notably low-noise channel. Sending signal 31 to a PID hides or unhides that process from userland views; sending signal 63 toggles the module's own visibility in the module list; and sending signal 64 to any PID elevates the associated user to root. The signal mechanism is worth studying because it means the rootkit's C2 surface is effectively zero-network — there is no listener, no socket, and no beacon. Everything is done through the ordinary kill() syscall interface, which traditional network monitoring simply cannot see.
File hiding is handled through a MAGIC_PREFIX convention: any file or directory whose name begins with that prefix becomes invisible to directory listings once the module is active. For a defender, this is the classic reason file-integrity monitoring and cross-view detection — comparing what the kernel reports against what raw filesystem access reveals — remains a core control. It is also a reminder that name-based hiding is trivially cheap for kernel-mode code, since the module hooks the relevant syscall paths and filters results before they reach userland.
The README is admirably compact but complete, covering kernel version verification with uname -r, a standard make build, loading with insmod, and — importantly for lab hygiene — an uninstall path. Because the module starts invisible, removal first requires making it visible again with kill -63 0, after which rmmod diamorphine unloads it as root. That uninstall sequence is itself educational: it demonstrates that a hidden rootkit must expose some re-materialization trigger, which is an inherent design tension in stealth software.
What the README's reference section reveals is arguably as valuable as the code. It cites canonical material: the Wikipedia rootkit article, LDD3 (Linux Device Drivers) from lwn.net, the archived THC paper on LKM_HACKING, phrack issue 58 on on-the-fly kernel patching, and more modern resources like xcellerator's "Linux Rootkits: New Methods for Kernel 5.7+" series and Elastic Security Labs' FlipSwitch syscall-hooking research. This bibliography positions Diamorphine squarely in the educational lineage rather than as an operational weapon; the author is explicitly curating the learning path around LKM rootkit internals.
The repository's own topic tags reinforce that dual identity: advanced-persistent-threat, redteam, lkm-rootkit, and malware sit alongside security-audit and security-tools. For red teamers operating under explicit authorization, Diamorphine-style modules illustrate the post-exploitation value of kernel privilege — but the module itself requires root to load, so it models persistence and stealth elevation maintenance rather than initial access. For blue teams, that distinction matters: detecting Diamorphine-class threats means assuming the attacker already had kernel-level privileges and looking for the artifacts that persist afterward.
Detection angles are well documented in the broader research the README points to. Cross-view validation — comparing /proc/modules, sysfs module listings, and kernel memory structures — exposes modules hidden only from the linked-list walk. Unexpected kill() calls carrying signals in the real-time range (signals above 31 in Linux conventions are unusual traffic) are a behavioral tell. Memory forensics frameworks that scan for module structures outside the official list, plus kernel-integrity measurement approaches, are the standard countermeasures against this entire class of technique. Vendors like Elastic have published detection research (FlipSwitch) precisely because LKM rootkits remain a relevant threat model.
From a defensive engineering standpoint, Diamorphine is best understood as a test harness. Detection product teams and researchers deploy it in disposable VMs to validate that their kernel-integrity sensors, EDR behavioral rules, and forensic tooling actually fire against signal-based privilege escalation and module hiding. Its simplicity — no obfuscation, no packed payloads, no network component — makes it an ideal baseline: if your tooling cannot catch Diamorphine, it will not catch anything more sophisticated.
The license is marked NOASSERTION on GitHub, which anyone repurposing the code commercially or in products should treat as a caution flag — review the repository before embedding or redistributing it. The project's longevity across kernel generations from 2.6.x to 6.x also signals active-enough maintenance to remain a relevant teaching artifact, since syscall-hooking internals shift meaningfully between major kernel releases.
Used appropriately — in snapshots, VMs, and isolated lab networks with explicit authorization — Diamorphine delivers concentrated lessons in kernel attack surface, syscall-hook hiding, signal-covert-channel design, and the corresponding defensive countermeasures. Deployed anywhere else, it is a rootkit, full stop, and this analysis is offered strictly so that authorized professionals can recognize, study, and defend against the techniques it embodies.
m0nad/Diamorphine.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.