I don't want use LD_PRELOAD mechanism in user mode to hook dlopen, because Malicious Code can bypass user mode hooking.
I want to do this in kernel mode. Hooking 'open' has great side effects. Is there any other better way?
Related
I was debugging a program in which I hit
int 0x80
I know this means a system call and then the kernel executed it. However, GDB does not allow me to look at the instructions run by the kernel while executing this system call. It just executes the system call and takes me to the next instruction.
Is there anyway I can look into the kernel mode code while debugging a user mode program? If not, then what are the over best alternatives available to me?
Is there anyway I can look into the kernel mode code while debugging a user mode program?
No.
(Actually, you could do that if you use UML, but that is likely too complicated for you to set up.)
I'm writing a driver for Windows NT that provides Ring-0 access for userspace application. I want to make a utility with exclusive rights to execute any user's commands that would be protected from any external harmful influence.
Surfing the Internet I found that it is necessary to hook some native kernel functions, such as NtOpenProcess, NtTerminateProcess, NtDublicateObject, etc. I've made a working driver which protects an application but then I realized that it would be better to prevent it also from external attempts of removing the driver or forbidding its loading during OS starting like firewall. I divided the task into two parts: to prevent physical removing of the driver from \system32\drivers\ and to prevent changing/removing registry key responsible for loading the driver (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services).
The matter is that I do not understand how to hook the access to the registry key from kernel space and even not sure that it is possible: all functions from ntdll that work with registry are in the userspace, unavailable from kernelspace. Also all API hooks that I can set from userspace would be in specific proccess's memory context. So we need to inject Dll into every proccess be it current or new.
Is there a method to hook all NT-calls in one place without injecting Dll into every proccess?
You do this in wrong way. Registry calls is also nt syscalls and reside in SSDT (as another Zw* syscalls). But hooking SSDT is bad practice. Major drawbacks - its dont working on x64 systems because of PathGuard. Right way is use documented specific filtering mechanisms of OS. For registry calls it is Configuration Manager callbacks. There are some caveats for windows xp version of this callbacks (some facilities are unimplemented or bogus) but xp is dead now =). It`s very simple to use it. You can start (and end =) ) from this guide http://msdn.microsoft.com/en-us/library/windows/hardware/ff545879(v=vs.85).aspx
http://www.makelinux.net/ldd3/chp-2-sect-3#chp-2-ITERM-4135 this link describes the user space and kernel space communication.
could anyone explain it with a simple user space application program in c that links & communicates(send / receives values) to the kernel object.?
The program insmod, available on most Linux machines (but requiring sudo privileges to run) instructs the kernel to load a specified module (kernel object) through the system call init_module.
More generally, user-space programs communicate with the kernel through these system calls, which are essentially requests to the kernel from user space. Any application you write in C must use system calls in some way to interact with the system (for example, printf uses the write system call under the hood to put characters on the screen).
Just open a file with open(2). The compiler will add code to the application for this call which will put the function arguments on the stack and make it crash in a certain way (see system call). The kernel catches all the crashes and handles them.
Since this is a "good" crash, the kernel will look up which function to invoke, get the arguments from the stack and invoke the function.
The reason for this complicated approach is security: By "crashing", the application completely relinquishes control. The CPU will switch to a different mode, too. In this mode, it can access the hardware (in "application" mode, any access to the hardware leads to an "illegal access" crash which terminates your app).
The open(2) function itself can't do much. Instead, it will check which file system can handle the request and invoke the open function of the file system. File systems are implemented as kernel modules.
Is there a way to create a user-mode process from kernel-mode on Windows NT platform (XP-W7)?
EDIT: I must install only the driver. This is a specific of the project.
To create a valid win32 process the driver must communicate with CSRSS (what is completely undocumented). So I ended up by queuing a user-mode APC and allocating virtual memory for the APC code in the context of the existing win32 process (that code will call CreateProcess and do the job).
It is a tricky way but it works.
I don't know an easier way to achieve this. But what about having a Windows service running which makes an overlapped DeviceIoControl into your driver? On return the service could examine the data it has received from the driver and start the according application.
This can't be directly done - Creating a win32 process requires some set up by the user mode part of CreateProcess, not just creating the process object in kernel mode.
You need some user mode code here - either a service, a desktop app, or so on, to launch the your user mode application.
Reading Monitoring certain system calls done by a process in Windows, I'm wondering about a Windows equivalent to the ptrace system call or a programmatical workaround.
You can use ETW to trace system calls. When starting the trace, in EVENT_TRACE_PROPERTIES, you can add EVENT_TRACE_FLAG_SYSTEMCALL flag to EnableFlags. This enables SysCallEnter and SysCallLeave events, as described here.