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.
Related
There is a multithreaded program that operates simultaneously with a device via COM port based communication and remote (IP) video stream. The program also uses OpenCV library to process the data.
The trouble is that it shuts down without any signals (neither run-time, nor any other errors are caught; log file has no anything useful as well). The most top level application error event handler is set and still there are no any signs of the program crash. It just closes after awhile.
The biggest difficulty is that it works fine on all our PCs for days non-stop. But fails on customers PCs so that testing process is very slow. Customer is in a different country (Asian localization, whilst ours is European), but the program is built with Unicode support.
So far we have got some assumptions about localization issues and antivirus activity... but it gives nothing in result.
The program is written with MinGW 4.4.x C++ and wxWidgets 2.9.3
Any suggestions of the probable origin would be appreciate.
Solved.
The problem was inside OpenCV build 2.3.1, that we use. The function cv::imdecode(...) uses stdio.h`s tempnam() function to generate temporary file during decoding. Under x86 Windows systems this function fails after 32767 new names for temporary file. Under x64 Windows systems it returns some nonsense string, but it still works.
So the solution I came with was to change the way of receiving-decoding images from our device.
Thanks everybody for comments.
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.
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
I'm writing some software that automatically connects a Bluetooth device using the Windows Bluetooth API. When it connects, Windows automatically starts installing the Bluetooth HID device driver, as expected:
This takes about 10-15 seconds, after which Windows displays the familar "ready for use" message:
The problem is that BluetoothSetServiceState() returns as soon as the driver install begins, not when the device is actually ready for use. This causes some problems for my code, because it invokes a separate library for device communication as soon as it's "connected". The first few calls fail because the drivers haven't finished installing, and making those connection attempts appears to interfere with the driver installation, because if I try to use the communication library before the driver installation has finished Windows wants to restart before the device can be used.
What I'm looking for is a way to hook that "ready to use" event, when driver installation has actually finished, so I don't make my communication library calls prematurely. Is there some Windows API call I can use to either register a function callback or directly polling the state of driver installation?
I'm writing this in vanilla C/C++, no .NET. Thanks for your help!
You might want to have a look at
this sample code and RegisterDeviceNotification function. I'm not sure for 100%, but it seems to work if you specify correct guid for your device class.
Here is what I would do:
Download Winspector (or use Spy++)
Start up Winspector, and begin watching for Window Messages
Install your driver
Watch for WM's indicative of a completed driver installation
I wish I could be more descriptive on #4, but I'm not familiar with the specific window message you need. Have a look here for possible Window Messages to expect.
However, once you determine the correct window message to look for, then programmatically have your program wait for (and handle) this WM. CodeProject has an excellent write up on how to do this in C++. Personally, I'd prefer to do it in Delphi.
If it is a network binding then RNDIS sends a message when it completes installation as per RNDIS Driver Implemenation guide
and definition of RNDIS
or
You can install or query the device list programatically through Devcon utility (source code is available with MSDN ) as given in Examples