KASLD: A local kernel memory-layout derandomizer with an honest failure model

What KASLD actually solves

KASLD addresses a specific problem: from a local, unprivileged process, how much of the Linux kernel's virtual and physical memory layout can be recovered? The kernel text base is the primary target, because defeating KASLR is a common first step in local privilege escalation exploits. The tool does not promise a full break. Instead, it fuses evidence from dozens of independent techniques and the architecture's known invariants to narrow the kernel's placement to a residual window. That window is reported as a surviving slot count and bits of entropy, which the README describes as an upper bound on the protection KASLR retains from that vantage, not a guarantee the base is out of reach. This is for security researchers, red teamers, and defenders who need a concrete, quantified answer to 'how much ASLR is left?' on a specific system.

The vantage model: privilege, configuration, and confinement

The core design idea is that what KASLD can recover depends on three independent axes: privileges and capabilities, system configuration, and container confinement. These do not form a simple ladder. A container task with CAP_SYS_RAWIO can read /proc/kcore, something an ordinary user cannot, while a distribution might make /boot/System.map world-readable or not. Configuration is independent of privilege: root cannot read /proc/kallsyms under kptr_restrict=2, but a relaxed sysctl can give a plain user a leak. Confinement, such as a seccomp sandbox, can mask /proc oracles or block syscalls. The README stresses that more privilege is not a superset of less, because each leak source is gated by its own combination. This model is honest: it avoids the common mistake of assuming root is always the most powerful vantage. The tool opportunistically uses whatever the vantage grants, and the reported 'guaranteed' window never depends on privilege. That is a strong soundness claim, and it is the reason the output can be trusted as an upper bound.

How the inference engine combines evidence

The README describes an inference engine that fuses evidence from dozens of independent techniques. The example output shows 106 of 109 components running, with 3 experimental ones skipped unless you pass -x. Each component is a leak or side-channel technique, and the engine combines their results with the architecture's known invariants. The output is a table with a 'Certainty' column, which can be 'guaranteed', and a 'Window' column that shows the range of possible bases. For instance, the example shows 'Virtual Image Base' with certainty 'guaranteed' and a window of '0xffffffffa2e00000 slide +0x21e00000', with 1 candidate of 505. That means the engine proved the base to a single slot. The 'Grain' column shows the alignment, here 2 MiB. The engine does not simply take the union of all leaks; it narrows the set by intersecting constraints. The README points to docs/architecture.md for a detailed walkthrough of one leak from end to end. The key point is that the output is a set of surviving placements, not a single guess, unless the evidence forces one.

Getting it running: build, deploy, and output modes

The quick start is straightforward. You need libc-dev, make, gcc, binutils, and git. Clone the repository, run 'make', and execute './build/<arch>/kasld'. The build directory is self-contained, containing the 'kasld' binary and a 'components' directory with leak components. You can copy that directory to a target system. The default text mode prints an answer-first overview. There are several output formats: '-v' for verbose readout, '-j' for machine-readable JSON, '-1' for a single shell-pipeable line, '-m' for Markdown suitable for issue trackers, and '-H' to append a hardening assessment. The '-x' flag enables experimental components. The README gives an example where one component timed out after 30 seconds and was killed, which shows that some techniques are slow. The extra/weaken-kernel-hardening script can temporarily relax sysctls for testing, but it requires root. This is a practical tool, not a library; you run it as a binary and parse its output.

The honest limitation: sound but not complete

The most important limitation is stated directly in the README: on a fully patched modern kernel, where x86-64 side channels are mitigated and no direct kernel-text leak survives, full recovery is often impossible. The constraint set is rarely empty, but the residual window can be large. The README points to docs/limitations.md for what a result does and does not prove. A negative or partial result is sound but not complete, meaning the tool will not give you a wrong answer, but it may give you a wide window. This is the wrong tool if you need a guaranteed base address on a hardened system. It is also not a stealth tool; the README mentions docs/footprint.md, which describes the behavioural signature of a run on a monitored host. The tool is 'loud by design', so using it on a target that has EDR or kernel auditing is likely to be detected. That is a real operational constraint for red team use. The timeout example in the output shows that some components can hang, and the tool kills them after 30 seconds, so runtime can be significant.

A real alternative: manual leak hunting with kallsyms or side channels

The obvious alternative is to write a one-off script that reads /proc/kallsyms or /proc/kcore directly, or to use a single side-channel technique like prefetch or Spectre. The difference in approach is that a manual script gives you a single leak, which may be incomplete or unreliable. KASLD's value is its fusion engine: it combines many weak signals into a single sound window. For example, a manual script might read /proc/kallsyms when kptr_restrict=0 and get the exact base, but that is trivially easy and not a realistic target. A manual side-channel script might give a noisy range. KASLD formalizes the inference and reports the residual entropy, which a manual approach rarely does. The trade-off is complexity: KASLD is a large C project with many components, while a manual script can be 50 lines. If you only need one specific leak on a known system, a manual script is simpler. If you need a robust, evidence-fused answer across many systems, KASLD is more practical.

Maintenance, license, and what to verify before adopting

The repository is under the MIT license, which means you can use, modify, and redistribute it with attribution. There is no stated maintenance policy, but the project has recent releases: v0.3.0 in June 2026, v0.2.0 in June 2026, and v0.1.1 in April 2026. That suggests active development. The documentation is extensive, with docs for architecture, limitations, bypass techniques, exploitation, footprint, and utilities. The README mentions a CONTRIBUTING.md for adding leak components or inference rules, so the project is designed for extension. Before adopting, verify that your target architecture is supported. The list includes x86, ARM, MIPS, PowerPC, RISC-V, LoongArch, and s390, but not every sub-architecture is listed. Also check the kernel version; the example output shows '7.0.0', which is a future kernel, so compatibility with older kernels may vary. The 'guaranteed' certainty is a strong claim, so you should validate it on a test system before trusting it on a target. The README does not mention any automated test suite, so you should run the soundness validation utilities in extra/ if you plan to rely on the results.

Editorial conclusion

Adopt KASLD if you are a penetration tester, exploit developer, or defensive researcher who needs a concrete, evidence-based estimate of how much kernel ASLR a given local vantage can defeat. Do not adopt it if you expect a guaranteed kernel text base on a fully patched modern x86-64 system; the README states that full recovery is often impossible there. Before relying on a result, verify your kernel version, architecture, and the exact hardening sysctls (kernel.dmesg_restrict, kernel.kptr_restrict, kernel.perf_event_paranoid, kernel.unprivileged_bpf_disabled) on your target, and read docs/limitations.md to understand that a reported window is an upper bound, not a promise. Also check the license: MIT, so you can integrate or modify freely, but you must retain the copyright notice.

Official sources

1. Official README
2. Project repository
3. Release notes