Next the following method is called to copy data onto the stack: RtlCopyMemory((PVOID)KernelBuffer, UserBuffer, Size)
For example, a sample call to a driver would look like this: char input = This call allows a process to pass data to a driver along with a command, and receive data in response. Now that we have an environment set up, let’s take a look at the driver code that we will be exploiting.The source code for the vulnerable method is found in StackOverflow.c.Ĭommunication with this driver is performed from usermode via a Win32 API call of DeviceIoControl. When rebooted, the driver can be loaded using OSR Online Driver Loader: This key must be provided to WinDBG when starting the kernel debugging session on the debugging VM, for example: This will provide a key, for example: 8j8vzcz To enable remote debugging support (which will also allow us to load unsigned drivers), use the following via the command line: bcdedit /debug onīcdedit /dbgsettings NET HOSTIP: PORT:50000
As Windows does not support unsigned drivers by default, there are a few configuration changes that we must make. Our exploitation machine will be responsible for loading the vulnerable HEVD driver. For this I use Visual Studio 2017 Community, which can be downloaded from Microsoft.
Make sure that you know the IP address of your VM, and that it is contactable from the exploitation VM, as we will be running the remote debugging protocol over TCP/IP rather than serial or USB.įinally you will need a compiler.
I usually use IDA Pro, however Radare2 provides a good free alternative. It is also handy to have a disassembler capable of loading PE executables should be fine. This can be done in WinDBG by navigating to Settings and providing the following as the Symbol Path value: srv*c:\symbols* Once WinDBG is installed, we will configure kernel symbols to make life a bit easier. Our debugging machine will primarily consist of WinDBG, which will be used as our kernel debugger, however I recommend trying out WinDBG preview if you have not had the chance, if only for the slick UI :) To exploit the driver, we will set up 2 virtual machines within VirtualBox, a debugging VM and an exploitation VM. Available on github here, the project provides a Windows driver with a range of vulnerabilities added to be exploited. If you want to learn about Windows driver exploitation, few resources are better than the HackSys Extreme Vulnerable Driver. This post will start off by laying the groundwork for future posts, and walking through a simple stack overflow exploit in the Windows kernel. If you haven’t had chance to read it, I’d recommend that you pause and give it a quick glance as some of this walkthrough will rely on concepts introduced previously.
If you modify the kernel or add extra multitasking features to the existing kernel, then your modifications remain open source because they are in effect part of the kernel, but your application that uses the kernel still remains closed source.« Back to home Exploiting Windows 10 Kernel Drivers - Stack Overflowįollowing on from my earlier post in which we walked through creating an exploit for the WARBIRD vulnerability, over the next few posts I’m going to be looking at Windows kernel exploitation. I’m not sure I can put it more succinctly than the table on this page: If your application makes use of FreeRTOS through its API but is not itself anything to do with implementing multitasking, then your application can be closed source, and only the kernel is open source.
No, as long as the code provides functionality that is distinct from that provided by FreeRTOS What does it mean “Do I have to open source my application code that makes use of the FreeRTOS services? –> What FreeRTOS does do, however, is provide tools that will tell you how close the stack has ever come to overflowing (the stack “high water mark”), so you have data you can use to adjust the stack accordingly to avoid RAM being wasted. You would calculate the stack size in exactly the same way you would for any other C program (what is the maximum function call depth, what is placed on the stack by your application when at the maximum call depth, etc.).
I was wandering how to calculate a stack size for a particular task ?