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.
Related
So I need to simulate Isis2 in ns-3. (I am also to modify Isis2 slightly, wrapping it with some C/C++ code since I need at least a quasi real-time mission-critical behavior)
Since I am far from having any of that implemented it would interesting to know if this is a suitable way of conduct. I need to specifically monitor the performance of the consensus during sporadic wifi (ad hoc) behavior.
Would it make sense to virtualize a machine for each instance of Isis2 and then use the tap bridge( model and analyze the traffic in the ns-3 channel?
(I also am to log the events on each instance; composing the various data into a unified presentation)
You need to start by building an Isis2 application program, and this would have to be done using C/CLI or C++/CLI. C++/CLI will be easier because the match with the Isis2 type system is closer. But as I type these words, I'm trying to remember whether Mono actually supports C++/CLI. If there isn't a Mono compiler for C++/CLI, you might be forced to use C# or IronPython. Basically, you have to work with what the compiler will support.
You'll build this and the library on your mono platform and should test it out, which you can do on any Linux system. Once you have it working, that's the thing you'll experiment with on NS/3. Notice that if you work on Windows, you would be able to use C++/CLI (for sure) and then can just make a Windows VM for NS3. So this would mean working on Windows, but not needing to learn C#.
This is because Isis2 is a library for group communication, multicast, file replication and sharing, DHTs and so forth and to access any particular functionality you need an application program to "drive" it. I wouldn't expect performance issues if you follow the recommendations in the video tutorials and the user manual; even for real-time uses the system is probably both fast enough and steady enough in its behavior.
Then yes, I would take a virtual machine with the needed binaries for Mono (Mono is loaded from DLLs so they need to be available at the right virtual file system locations) and your Isis2 test program and run that within NS3. I haven't tried this but don't see any reason it wouldn't work.
Keep in mind that the default timer settings for timeout and retransmission are very slow and tuned for running on Amazon AWS, inside a data center. So once you have this working, but before simulating your wifi setup, you may want to experiment with tuning the system to be more responsive in that setting. I'm thinking that ISIS_DEFAULTTIMEOUT will probably be way too long for you, and the RTDELAY setting may also be too long for you. Amazon AWS is a peculiar environment and what makes Isis2 stable in AWS might not be ideal in a Wifi setting with very different goals... but all of those parameters can be tuned by just setting the desired values in the Environment, which can be done in bash on the line that launches your test program, or using the bash "Export" command.
I want to write a program that will monitor memory in a driver and print the memory contents every so often.
However, I'm not finding any resources in the Windows API that seem to allow me to grab a pointer (Handle) to a specific driver.
I'd appreciate any answer either from User space OR kernel space.
If you want to know exactly what I'm doing, I'm attempting to duplicate the results from this paper except on Windows. After I gain the ability to monitor a buffer in a basic windows console program, I intend to monitor from the GPU.
[For the record: I am a Graduate Student who is pursuing this as a summer project... this is ethical malware research.]
============UPDATE ==================
This might technically be better suited as an answer, but not really until I have a working solution.
My initial plan of attack is to use WinDbg to do dynamic analysis on the keyboard driver when it gets loaded, so I can get some idea about normal loading/unloading behavior. I'm using chapter 10 of this book, to guide setting up my testbed and once I understand more about the keyboard structure and its buffer, I'll work backwards towards getting a permanent reference to this structure and see about passing it into the graphics card and monitoring it with DMA as the original paper did on Linux.
You won't solve this problem by "grabbing a pointer to a specific driver". You need to locate the specific buffer used by the keyboard driver that resides on top of the USB driver.
You will have to actually grok the keyboard and USB drivers for Windows. At least part of which is probably available if you have a DDK (driver development kit) [aka WDK, Windows Driver Kit]. You will definitely need a graphics driver for this part of the project.
You will also have to develop a driver mechanism to map an arbitrary (kernel) lump of memory to your graphics driver - which means you need access to the source code for the graphics driver. (In theory, you could perhaps hack about in the page-tables, but Windows itself isn't too keen on software messing with the page-tables, and you'd definitely need to be VERY careful if the system is SMP, since modifying page-tables in an SMP system requires that you flush the TLB's of the "other" CPU(cores) in the system after updates).
To me, this seems like a rather interesting project, but a really tough one in a closed source system like Windows. At least in Linux, the developer has the source-code to read. When it comes to Windows, most of the relevant source code is completely unavailable (unless your school has special license to the MS Source code - I think there are some that do).
I'm just curious: I have a Windows dll which does some rendering/drawing jobs with openGL and then returns the result to the application.
Would it be faster if the code didn't run in user-mode but in kernel-mode? (no interruptions and higher priority)
Running in kernel mode doesn't get you higher priority, and it doesn't get rid of interruptions. Unless you ask it to, which you can do in user mode too for the most part.
The biggest problem you would face is that openGL is simply not available in kernel mode. It is a user mode API, that talks down into a device driver to implement some of its logic, but a lot of the logic is implemented entirely in user mode. It isn't like there is a syscall for every openGL API.
Even if you could overcome that (which you can't), as Erbureth mentions the security risk would be huge, debugging it would be a nightmare (have you ever used a kernel mode debugger?) and installing it would require admin privileges.
So all in all, no - it isn't possible.
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.
i need to add some files to results returned by FindFirstFile and FindNextFile under windows. Is this possible by file system filter driver or what type of drivers?
Thank you
You can do this by File System Filter Driver. But you can do this by implementing a system wide API hook. I have not tried it before but you really don't need to take the pains of writing the drivers and making the system unstable in case of spoiling the driver stack.
System Wide API Hooking
API Hooking Revealed
As pointed out you can use a file system filter driver (legacy or mini-filter, based on fltmgr). However, I would strongly recommend against the system-wide API hooking. Simple reason: if you do it in usermode it's not really going to be system-wide and if you use an SSDT-hook or some hotpatching method you risk the system's stability. An alternative, albeit equally shady as system-wide hooking, would be entry-point stealing. In this case you use the device object of the volume (in which you're interested, just listen for the attach notifications or enumerate them at startup) to find the driver responsible for it and modify the major function entry points in the driver object (Ilho pointed you into the right direction already).
A file system filter driver is the supported method to do just that.
In the latest Windows 7 WDK the sample under 7600.16385.1\src\filesys\miniFilter\minispy provides a good starting point. Biggest problem with mini filters for a private person is to get assigned an altitude for the driver to load at. Because using just any altitude can well lead to BSODs - and in case of FSFDs you might even risk your data integrity (although the kernel steps in with the BSOD to prevent that). You only need to fake IRP_MN_QUERY_DIRECTORY - this is the minor control code you're looking for when you are handling the IRP_MJ_DIRECTORY_CONTROL major control code. All others you can pass through as long as you don't need to allow the file to be opened, read or written and such. How to do that can be seen in the 7600.16385.1\src\filesys\miniFilter\passThrough sample source.