I'm curious about how, running Windows 7 on x86, you could execute some code in kernel mode. This is for my own personal use; so I'm not bothered about giving Windows a trillion permissions or whatever. Does kernel mode code have to be specially compiled or linked? etc
Only code from the kernel itself, and from certain device drivers, can run in kernel (supervisor, ring 0) mode.
So you will have to write a device driver.
EDIT: the question has already been answered here.
Ring 0 drivers can execute code in kernel mode.
You will need Windows Device Driver Kit for such development.
Also you have to be extremely careful with driver development because unhandled exception occurring in the kernel indicates a serious bug that exists in the operating system or (more likely) in a device driver and not in an application. Once memory in the kernel gets potentially corrupt, it isn't safe for the system to continue running and you see what is typically called "the Blue Screen of Death."
So normally your drivers should be WHQL certified.
Related
Why there is no GUI kernel debugger like SoftICE, which allows to debug kernel driver on a local machine nowadays? Why remote machine is obligatory for driver debugging in Windows 7 and higher?
An in-system kernel-mode debugger is an extremely complicated software because it must take care of many low-level kernel resources and operations. If kernel internals are changed in the next OS version, the debugger must be updated accordingly. Debugger developers must work together with kernel developers and have access to kernel source code. All that makes in-system debugger development complex and expensive.
And any kernel-mode debugging on the development system is a dangerous and inconvenient process. Even if no FS damages and/or other data losses occur due to a BSOD, booting a development system, starting all required applications to re-create convenient development environment is much longer process than rebooting a dumb target machine (hardware or virtual).
When hardware computers were expensive, there was no efficient remote debugging interface and there were no efficient virtual machine solutions, SoftICE was an acceptable tool. But in the last 15 years, remote kernel debugging in Windows had been greatly improved, so using WinDbg is much more convenient that using SoftICE, even though WinDbg has many flaws and bugs.
I have recently been attempting to create a GPIO Driver for SBC's using an Intel chipset that run Windows 8.1 and have begun testing it on an actual system. After loading the Driver and updating the Intel chipset I am using, the system appears to hang after loading the BIOS. Unfortunately, this disables my mouse, keyboard, and video, preventing me from entering BIOS or the boot manager.
While it is possible that the chipset update caused the system to become unbootable, it is highly unlikely considering we use that update for our other SBC's running the same chipset.
So my question: Is it possible for a Windows Kernel Mode driver to prevent a system from booting up past BIOS/POST?
I appreciate the help, since, clearly, I am no expert on this topic.
Yes, if your driver is being loaded at boot time it can prevent the booting of the OS and it will end up in BSOD(Blue screen of death) error with related bug check.
According to bugcheck displayed by the OS you can resolve the issues with your driver.
Or sometimes if its not giving any error and just hangs you can use WinDbg to check the bugcheck.
It depends on the error control of the driver service. Boot time drivers can also fail at any point. There is nothing special about the failure happening during boot. Instead, what is relevant under this scenario depends more on the ErrorControl value of the driver service which specifies how to proceed if it fails to load or initialize properly. A value of 3 (critical) would reboot the system to LKGC. Same rules apply to a win32 servic as well..
I have to maintain a WDF driver. This is a no-hardware driver: the driver use a disk file which is mounted as a Windows partition. All the data written to the disk are encrypted by the driver. The driver run in kernel mode.
The driver has been developed on XP and successfully ported on Vista and 7, 32 & 64 bits. I encounter one big problem on Windows 8. The driver lead to a fatal system error:
BugCheck 50, {ffffffffffffffd0, 0, fffff800002de33a, 0}
Probably caused by : Wdf01000.sys ( Wdf01000!FxDevice::DispatchWithLock+fa )
The problem occurs after deleting the device with WdfObjectDelete(). As long as the device is not deleted the driver run fine and there is no system error. When WdfObjectDelete has been called, the system crashes after a certain delay.
verifier detects no error in the driver. My questions are the following:
Is there anything special regarding WDF on Windows 8?
Is there any tool/technique that could help me finding the bug in the driver?
There shouldn't be anything specific to Windows 8 for this issue. I'd recommend starting to debug your driver with WinDbg via a remote system. With this you can set breakpoints, step through the code and most importantly get post-mortem information on the crash. Once you have connected a machine, and you can see they crash use analyze -v to get information. OSR is a great resource for BSOD debugging.
I am new to windows driver development, so please bear with me if my question is being too stupid. Well, I am not sure why, as MSDN suggested and also the way I perceived, the host computer, e.g developing the driver, and the target computer, e.g debugging the driver, need to be two separate ones. why such separation? I did try to merge those two by deploying and debugging a driver on the host computer, in which I am developing a driver, and it seemed work with no objection from windows. Thanks.
PS. Source like this http://msdn.microsoft.com/en-us/library/windows/hardware/hh698272(v=vs.85).aspx got me think so.
Practically, when you are developing and testing a driver, in many situation you will get system crash (BSOD) and your system may not be bootable. In such situations your development + debugger environment is also gone/in-accessible.
Two separate machines are required for kernel debugging. You cannot debug self by obvious reasons (a debugger and a debuggee are in the same kernel and a deadlock appears). Of course, the target machine can be a virtual one.
When we develop a driver and test it the system will crash and a blue screen (called BSOD - blue screen of death)will show up. This is not the case like developing a User mode application and it crashed due to a memory error. Your driver will be running as a kernel mode application , If it crashes due to any illegal memory operation then the whole system is gone. It is not a simple issue to resolve , You need to log into safe mode and remove the driver from your system to recover it.
Due to this it is preferred to use a target machine mostly a VM on which the driver is installed and a host machine there we will be using a debugger to debug the driver.
What is Windows Kernel Driver written with the WDK?
What is different from normal app or service?
Kernel drivers are programs written against Windows NT's native API (rather than the Win32 Subsystem's API) and which execute in kernel mode on the underlying hardware. This means that a driver needs to be able to deal with switching virtual memory contexts between processes, and needs to be written to be incredibly stable -- because kernel drivers run in kernel mode, if one crashes, it brings down the entire system. Kernel drivers are unsuitable for anything but hardware devices because they require administrative access to install or start, and because they remove the security the kernel normally provides to programs that crash -- namely, that they crash themselves and not the entire system.
Long story short:
Drivers use the native API rather than the Win32 API
This means that drivers generally cannot display any UI.
Drivers need to manage memory and how memory is paged explicitly -- using things like paged pool and nonpaged pool.
Drivers need to deal with process context switching and not depend on which process happens to have the page table while they're running.
Drivers cannot be installed into the kernel by limited users.
Drivers run with privileged rights at the processor level.
A fault in a user-level program results in termination of that program's process. A fault in a driver brings down the system with a Blue Screen of Death.
Drivers need to deal with low level hardware bits like Interrupts and Interrupt Request Levels (IRQLs).
It is code that runs in kernel mode rather than user mode. Kernel mode code has direct access to the internals of the OS, hardware etc.
Invariably you write kernel mode modules to implement device drivers.
A kernel driver is a low-level implementation of an "application".
Because it runs in the kernel context, it has the ability to access the kernel API and memory directly.
For example, a kernel driver should be used to:
Control access to files (password protection,hiding)
Allow accessing non-standard filesystems (like ext, reiserfs, zfs and etc.) and devices
True API hooks
...and for many other reasons
If you'd like to get know more, you can search for keyword "ring0" with your favorite search engine.
Others have explained the difference as the perspective of system level.
If you are doing development in C++, there are below differences in User mode development and kernel-mode development.
Unhandled exceptions crash the process in User mode, but in kernel mode, it crashes the whole system(face BSOD).
When the user-mode process terminates without free private memory, the system implicitly free process memory. But in kernel mode, remaining memory free after system boot.
The user-mode code is written and execute in PASSIVE_LEVEL. In kernel mode, there are more IRQL level.
Kernel code debugging done using separate machines. But you can debug user mode on same machine.
you can't use all C++ functionality in kernel-mode such as Exception handling and STL.
Entry points are different, in user mode, you use the main as the entry point. But in kernel mode, we need to use DriverEntry.
You can't use new operator in kernel mode, you need to overload it explictly.