Closed Sargastico closed 3 years ago
Hmmm.. This is an interesting one! I've spun up a VM with the same kernel as you and I get the same result.
/var/log/journal
made me suspicious of systemd, especially that it's trying to create the same file over and over again.
Turns out, on my Debian 10 VM, that /var/log/journal
didn't actually exist! After creating that directory, and repeating things, it's much cleaner:
[ 831.011747] rootkit: Loaded >:-)
[ 831.011751] rootkit: Found the syscall table at 0xffffffffb7800280
[ 831.011753] rootkit: mkdir @ 0xffffffffb6e662a0
[ 831.011755] rootkit: hooking mkdir syscall
[ 831.016731] rootkit: Trying to create directory with name: a
[ 831.033894] rootkit: restoring mkdir syscall
[ 831.033897] rootkit: Unloaded :-(
Looks like a Debian bug where systemd is installed and running, but the logs folder doesn't exist.
Please let me know if the above fix works for you! Glad you're enjoying the blog series and are writing the modules yourself too!
Nice! This works and fix the issue!
Hi! I was playing around with the LKMs from the project (which is awesome btw) and I came across a bug while trying to reproduce the hooking of "sys_mkdir" from the code at
linux_kernel_hacking/3_RootkitTechniques/3.1_syscall_hooking/rootkit.c
(I didn't modify any part of the code)I made it work in my own repo (you can check my code if you want). I was testing on a VM
Linux debian 4.19.0-16-amd64
and my hook doesn't use thept_regs
and it works. I didn't understand why, because as mentioned on the blog post (and the linux docs says that this change affects the versions 4.17.0 and above):Any idea why this is happening?
here is my
dmesg
output: