I'm building a HW-simulator for our driver team. Now, the simulator is devided in to 2 modules:
First module runs inside the driver, in kernel mode and that's where the main interface between the driver and the HW-Simulator.
Second module is an executable user-mode code which generates data for the simulator and transports it to the simulator via calls to DeviceIOControl (under windows API)
My need is this: I want to be able to execute the user-mode executable from within the kernel-mode. And I need to be able to do this in a relatively portable way. Currently I'm only running on Windows, but that should change soon.
Further more, I need to be able to communicate with the user-mode code via it'sstdin pipe, in order to reconfigure it and eventually close it.
I found this:
Executing a user-space function from the kernel space
but it's only relevant for the linux-kernel. Is there a more portable alternative? Or a windows alternative?
Can I do this in Windows by simply using the ShellExecute/RunAs API functions?
Note: We are aware of the security risks involved in invoking user-mode code from the kernel-space. But as this is only meant to be used as a test-environment and will not ever reach our release code, then we are not concerned.
There isn't a clean way to do this in the Windows kernel. The user-mode API CreateProcess to create processes use undocumented APIs (NtCreateProcess/NtCreateThread) to create a process.
The recommended thing to do would be to have a "partner service", a user-mode service that communicates with your driver using IOCTL. You can use the inverted call model to have your driver call your service to have it create a process.
Really, there is no documented way to do it without triggering process creation from user-mode.
But there is one undocumented tricky way if You don't want to create user-mode application:
To create a valid win32 process the driver must communicate with CSRSS (what is undocumented).
You can enqueue a user-mode APC, allocate some virtual memory for the APC code in the context of any existing process. This code should simply call CreateProcess and anything else You want.
Related
i have a question for making a Kernel Driver
i hope to Run process using kernel driver when "notepad.exe" is started,
tried to using "PsSetLoadImageNotifyRoutine" and i successfully get a point what "notepad.exe" is launched.
but is there a way to run a "osk.exe" process in that point?
couldn't find code what i need to running it
i wanted to using this code "ZwOpenProcess" , "ZwOpenFile".
but there didn't enough what document to how to using it
You cannot start a regular Windows process from kernel mode.
While CreateProcess does call into the kernel to create a process, after doing that it connects the new process to csrss.exe and this is required for many Windows APIs to work correctly.
Create a service that can create processes for your kernel code. Use the WTS API and CreateProcessAsUser to create the new process in the desired session. The driver should use inverted callbacks.
If PsSetLoadImageNotifyRoutine is the only reason you are in the kernel then you can drop the driver and just use WMI in the service to get notifications about new processes...
I would like to write a code which is able to capture the screen at boot phase (when Autochk is running) and write to file. What is the best approach?
From what I know at this phase only ntdll.dll is available...so we can use this native API to open the Mirror Driver to get the screen data. However in order to get data from mirror driver we will need the GDI library which is not available yet. What should I do?
The main problem is that Windows is running Windows code at that time, not yours. There's possibly an exception for (disk) drivers, but since you're talking about calling Win32 DLL's that doesn't matter. You can't call GDI from a driver. Besides, why would your driver be called in the first place? Drivers react to OS requests to handle specific events.
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.
When I used C# i was only able to access user-mode registry accesses.
Is it very difficult to access kernel-mode registry accesses using C++?
I recall reading somewhere I may have to create a dummy windows driver or something?
EDIT: Basically as a hobby project I wish to create a simple registry monitor. However, I do want to catch kernel mode (as well as user mode) registry accesses..... last time I did this, using C# I could not access the kernel mode activity.
There are two ways to achieve this:
Hook the relevant functions in the kernel - the traditional way - which requires a C/Kernel Driver. This is possible on x86 Windows, but on x64 Kernel Patch Protection will detect these modifications and shut down the system (with a bluescreen).
Build a registry filter driver - this is the now encouraged way to attack this problem and is the way process monitor works. You can also build file system filter drivers this way. Essentially, you simply need to pass the information back to userland which boils down to:
IoRegisterDevice(...somewhere in \Devices\YourDriverName...)
IoCreateSymbolicLink(\\DosDevices\Name -> \Devices\YourDriverName)
then a C, C++, C# application should be able to open the file \\.\YourDriverName and DeviceIoControl to it and receive responses.
It is possible to use C++ to write kernel drivers, but see this before you embark on doing so. To be clearer, you need to be really careful about memory in kernel mode (paged, nonpaged) and you're not going to have access to much of the standard library.
As an aside, you should be aware that:
Not all registry hives are accessible to kernel mode drivers, depending on context.
The paths are not common. So the kernel accesses \Registry\System whereas userland accesses HKLM.
I was having a discussion with a colleague about whether or not the following is possible:
Install an MFC application from a USB drive in Windows XP (this installation would be initiated manually by a user with sufficient privileges to install software).
After rebooting, this application should start instead of the default Windows XP shell (explorer.exe).
Does anyone know how I might accomplish this?
You won't be able to run an MFC application before windows starts up because by definition MFC runs off of windows DLLs that are not loaded until windows itself is. Not to mention that Windows is what is responsible for loading a PE in the first place, so you won't even be able to load a compiled EXE or DLL without a custom bootstrapper.
In order to do what you want to do you have a few options. There are (easy) ways for windows to be set to load an application on startup. If that is what you want, then this is entirely possible.
However, if you wish to execute code before and while windows is starting up, then you must first overwrite the bootstrapper (with something like GRUB), execute your code (again, you will not have access to any standard library - you will have to operate directly on the buffers made available to you by the CPU if you wish to do any sort of I/O), then start up windows by launching its bootstrapper. I have no idea how to do this; but that is the general overview of what must happen.
You mentioned DLL injection, which is another possibility. I am not familiar with what DLLs, and in what order, are loaded during windows startup. That will be an exercise for you. What you will have to take into consideration, is that the higher level you want to exist in (i.e. what libraries are available for you to do File/Console I/O) the higher up you need to execute your code in the windows startup process.
My suggestion to you is simply write a program that executes as a service that is started up during windows initialization. Its easy to do, and you will have the entire HAL loaded and ready to actually perform tasks - rather then you having to write device-specific drivers in order to manipulate hardware before window's loads the HAL.
Modify HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit registry value with full path to your application. This key specifies what program should be launched right after a user logs into Windows. The default program for this key is C:\windows\system32\userinit.exe. Userinit.exe is a program that restores your profile, fonts, colors, etc for your username. It is possible to add further programs that will launch from this key by separating the programs with a comma