monks
monks copied to clipboard
Check if syscall table is faked
Procmon should check if the syscall table is already patched by something else (or even by a remaining stub from procmon itself, as of #31). If the syscall table is patched, procmon should do nothing.
Scratch last phrase. Procmon should be able to determine if the syscall table is already patched, and if it is, it should be possible to guess if it's patched by procmon's stubs. If so, it should be possible to get the real syscall address and re-patch.
Also scratch that last thing! It should be possible to do so, BUT, if user really wants to re-patch the syscalls (meaning patch the stubs with another stubs) tell him clearly why that it's not a good idea. Anyways, give him the option to do so... We won't fight against brave people! :smiley:
@alexandernst Alexander, what do you think about the option of restore original system call table using the vmlinux (or packed vmlinuz) images? Procmon may be used as a simple "anti-rootkit" solution in that case :)
@milabs Oh, that's an interesting point! You mean something like scan (with udis? :stuck_out_tongue_closed_eyes: ) a vmlinux binary, check where syscalls should be and then check the current syscall table, right?
@alexandernst Yes!
@milabs Procmon (Monks!) could expose the address of each syscall the same way it exposes the state of each syscall (via sysctl). That way we could do the checking part in the viewer rather than the kernel module. What do you think?
@alexandernst How do you intend to scan kernel's memory from the viewer?
@milabs No need.
1. Load the kernel.
2. Create entries for each syscall (currently we do that already) in ```procmon.syscalls.__NR_read.realsc_addr```
3. Start the viewer and check those values from ```sysctl``` while reading a binary vmlinux image.
I think it could work.
@alexandernst OK, I've got it. Do you think that sysctl is a good information exporting interface?
@milabs Maybe not the best one. sysctl is the first thing I thought, but it could be replaced with anything :) The main idea is to keep as little logic as possible in the kernel module. The kernel module itself should just expose information and swap real with fake syscalls.
@alexandernst I think proc interface is a good choice for that purporse. Sysctl not the best one as I see it.
In the end they both are quite the same. They place some files inside /proc, just that they place them in different locations. Ok, I'll open an issue for this
@alexandernst procfs allows to read one file to get meny things (list of broken syscalls, for ex.) I don't think that sysctl does it as well as proc besides of the same back interface :)
@milabs Ah, indeed! Good point :) If no other alternative shows up, procfs will it be
@alexandernst procfs is the simplier one :)