Hooked: Find the Rootkit's Syscall-Table Redirects

The most iconic ring-0 abuse: a rootkit overwrites entries in the kernel's syscall table (sys_call_table) so a call jumps into the rootkit's own code instead of the real handler. Real rootkits typically hook one call to HIDE things (getdents/getdents64 for files, openat/read for /proc entries, recvmsg for socket listings) and one to CONTROL or PROTECT themselves (kill for magic signals, unlinkat to guard their files, delete_module to refuse unload, …). To a userland tool, files and processes simply vanish.

A captured syscall table is at /root/case/syscall_table.txt — columns <number> <name> <handler address>. The detection is an address check, not a guess:

• LEGITIMATE handlers live in CORE KERNEL TEXT — addresses of the form 0xffffffff81######.
• A HOOKED handler points into MODULE address space — 0xffffffffc#######, a loaded module's memory. No core syscall legitimately resolves there.

Two entries have been redirected into module space — which two differs from host to host. Find them by their addresses — not by which syscalls 'tend to be hooked': the table also holds commonly-hooked syscalls that are clean here.

1. Record the hooked syscalls' names (just the names, one per line, only the hooked ones) in /root/case/hooked_syscalls.txt.

2. Write a detector at /root/detect.sh that reads the captured table and prints the name of every syscall whose handler is in module space, one name per line. Grading runs bash /root/detect.sh, and also re-runs it against a second, unseen host's capture as bash /root/detect.sh <casedir> — so read the table from the directory given as the first argument, defaulting to /root/case (${1:-/root/case}/syscall_table.txt), not from a hardcoded path or syscall names. MITRE ATT&CK: T1014, T1562.001.