You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Can't defeat KASLR yet, so you may need to enter your password to find linux_proc_banner in the /proc/kallsyms (or do it manually).
Here's a modified version of meltdown.c using an extremely simplistic implementation (lazy hack) to find the kernel virtual address space, from which the base address can be inferred, without requiring root privileges (x86_64 only). Leaving this here in case it is useful.
Given the size of the kernel, and that the kernel is aligned, it is reasonable to expect that some symbols (such as debug or linux_proc_banner) can be found within the first ~100 bytes while iterating over the potential kernel virtual address space.
This technique iterates with a step of 0x100000, across the kernel virtual address space 0xffffffff80000000 to 0xffffffffffffffff[1], and checks the first 100 bytes for debug or linux_proc_banner.
Possibly the laziest and slowest approach possible. It is not efficient. It is not optimized. It does not implement the techniques in the paper.
Also, not that the printed offset may be off by a couple of bytes. I cared only about locating the kernel, not the exact offset.
Usage: ./a.out <start address> <number of bytes to search>
Depending on the target kernel, a faster technique may be to modify the hard-coded step to iterate 0x1000000 (rather than 0x100000) using offset a00000; ie: ./a.out 0xffffffff80a00000 100.
Here's a modified version of
meltdown.c
using an extremely simplistic implementation (lazy hack) to find the kernel virtual address space, from which the base address can be inferred, without requiring root privileges (x86_64 only). Leaving this here in case it is useful.Given the size of the kernel, and that the kernel is aligned, it is reasonable to expect that some symbols (such as
debug
orlinux_proc_banner
) can be found within the first ~100 bytes while iterating over the potential kernel virtual address space.This technique iterates with a step of
0x100000
, across the kernel virtual address space0xffffffff80000000
to0xffffffffffffffff
[1], and checks the first 100 bytes fordebug
orlinux_proc_banner
.Possibly the laziest and slowest approach possible. It is not efficient. It is not optimized. It does not implement the techniques in the paper.
Also, not that the printed
offset
may be off by a couple of bytes. I cared only about locating the kernel, not the exact offset.Depending on the target kernel, a faster technique may be to modify the hard-coded
step
to iterate0x1000000
(rather than0x100000
) using offseta00000
; ie:./a.out 0xffffffff80a00000 100
.Ubuntu 16.04 (4.4.0-21-generic)
Debian 9.0 (4.9.0-3-amd64)
Diff
Source
The text was updated successfully, but these errors were encountered: