I'm installing my driver using dpinst.exe. But before installing my driver I wish to delete all the oem files from inf directory corresponding to my hardware ID.
I want to do this programatically. Please suggest me a way to do this.
**Update :**
I want to do this without device connected as I may pre-install the driver before connecting the device. My device is PNP device.
Use SetupDiEnumDeviceInfo and SetupDiGetDeviceRegistryProperty to match your hardware ID
Use SetupDiOpenDevRegKey and RegQueryValueEx to read the corresponding InfPath
Call SetupUninstallOEMInf
PhilMY has already posted an excellent answer, which is still relevant. However, it is more than ten years old now, so I wanted to update it with more recent/recommended APIs:
Use SetupDiEnumDeviceInfo() and SetupDiGetDeviceRegistryProperty() to match your hardware ID
To get the OEM INF path, SetupDiGetDriverInfoDetail() can be used instead of reading the registry directly
Call DiUninstallDriver() on the resulting INF path (Microsoft recommends using it instead of SetupUninstallOEMInf(). In addition, it returns the needReboot flag, which may be useful in some scenarios.)
#2 is a little tricky as it requires SP_DRVINFO_DATA on input. To acquire it, one typically needs to call SetupDiBuildDriverInfoList() and SetupDiEnumDriverInfo() to iterate through all installed drivers for a particular device (use SPDIT_COMPATDRIVER flag to enumerate 3rd-party drivers).
It has a significant advantage in scenarios when multiple drivers are suitable for the given device, and this approach allows one to choose exactly which driver to uninstall.
Related
how to get harddrive serial number(not the volume # wich change at each reinstall of windows) in C or asm, without wmi (cause wmi required admin right). Any clue would be helpfull cause right now i found nothing on web in C without wmi, in dayss of searching... Thank you.
EDIT : For windows system
Please try my open source tool, DiskId32, which also has the source code at http://www.winsim.com/diskid32/diskid32.html . I only have an Win32 version at this time. Maybe some day I will add a Win64 version.
Hard drive serial number and other information about the harddrive like firmware version, etc. can only be obtained using SMART as far as I know and that requires special ioctls to the the block device node (/dev/sda or /dev/sdb) which is usually not available to a regular user.
I know there is a tool called smartctl which does exactly this:
sudo smartctl -i /dev/sda
Similar tools exist (hdparm, lshw, etc.) as well.
As far as trying to figure it out this info without being a privileged user, it might be possible only if it is exposed via /proc or /sys which I highly doubt is being done in the current SATA block device drivers.
I have a Program.exe that I need to intercept. That specific program uses CreateFile & ReadFile, however I need to intercept ReadFile function.
I thought about writing my own File System Filter MiniDriver.
I found this link by Googling: http://msdn.microsoft.com/en-us/library/ff551862(v=vs.85)
It seems that is the correct way to do this. However last time I did any driver development, I remember that >= VISTA did not allow drivers to be installed easily. You needed to acquire "Signed" priviledge from Microsoft(you had to pay).
My question is that, can I create Simple File System Filter Driver for my USB stick and intercept any readings from ReadFile()? All I want to do is to allow ReadFile by a specific process.
1) I need this legally
2) I need to avoid unsigned drivers, so the driver would always work.
Will one minifilter driver work for every OS starting from XP?!
Prohibit of loading unsigned drivers is exist only on x64 versions of windows >= vista
On x64 versions you can
1) Switch to test mode to turm off this restriction
2) Add test sertificate as root to certificate storage
But if you want distribute this driver you must bay certificate.
Yes, minifilter is the preferred way for this. You can intercept system calls/IRPs and allow-deny any of them depending upon your criteria.
Also, same driver code can be used for multiple OSes, however you need to build for specific Os.
WDK 7 can be used to build drivers from XP to Windows 7.
Also, as izlesa suggested, you need to sign for x64 windows higher than vista.
Once I've written a sort of a driver for Windows, which had to intercept the interaction of the native display driver with the OS. The native display driver consists of a miniport driver and a DLL loaded by win32k.sys into the session space. My goal was to meddle between the win32k.sys and that DLL. Moreover, the system might have several display drivers, I had to hook them all.
I created a standard WDM driver, which was configured to load at system boot (i.e. before win32k). During its initialization it hooked the ZwSetSystemInformation, by patching the SSDT. This function is called by the OS whenever it loads/unloads a DLL into the session space, which is exactly what I need.
When ZwSetSystemInformation is invoked with SystemLoadImage parameter - one of its parameters is the pointer to a SYSTEM_LOAD_IMAGE structure, and its ModuleBase is the module base mapping address. Then I analyze the mapped image, patch its entry point with my function, and the rest is straightforward.
Now I need to port this driver to a 64-bit Windows. Needless to say it's not a trivial task at all. So far I found the following obstacles:
All drivers must be signed
PatchGuard
SSDT is not directly exported.
If I understand correctly, PatchGuard and driver signing verification may be turned off, the driver should be installed on a dedicated machine, and we may torture it the way we want.
There're tricks to locate the SSDT as well, according to online sources.
However recently I've discovered there exists a function called PsSetLoadImageNotifyRoutine. It may simplify the task considerably, and help avoid dirty tricks.
My question are:
If I use PsSetLoadImageNotifyRoutine, will I receive notifications about DLLs loaded into the session space? The official documentation talks about "system space or user space", but does "system space" also includes the session space?
Do I need to disable the PatchGuard if I'm going to patch the mapped DLL image after it was mapped?
Are there any more potential problems I didn't think about?
Are there any other ways to achieve what I want?
Thanks in advance.
Do I need to disable the PatchGuard if I'm going to patch the mapped DLL image after it was mapped?
To load any driver on x64 it must be signed. With admin rights you can disabled PatchGuard and I personally recommend using DSEO, a GUI application made for this. Or you can bypass PatchGuard by overwriting the MBR (or BIOS), although this is typically considered a bootkit - malware.
I am new to device driver programming. I've followed the available tutorials on the web which has provided helpful information to get started. However now I have embarked on a new project where the exclusive goal is to search for functions which have been hooked by malware or keyloggers. So I think I have sorted out what I need to accomplish this though I still need to be able to locate the load address of the system dll's (i.e. kernel32.dll, user32.dll and the like) that are already loaded in memory. I need the load address so that I can parse their PE to get to the export and import sections. Furthermore adding the load address to the file size will give me a address range to cross reference the addresses of the export functions no ? Cross referencing the the IMPORT address will be a little more involved but it can be done according to my estimates. I thought that building a kernel mode driver would be the right way to go since accessing memory outside the kernel driver's address range would not be an issue for the driver as opposed to a user mode app. How else will I be able to access the addresses located in the EAT and IAT of the target dll ? I know there exist a user mode API that can provide the load address mainly being GetModuleHandle but I would like to find the equivalent in kernel mode. I could write a user mode application that could relay this information to the driver but prefer that this all be done in kernel mode if possible. Any suggestions or comments would be most welcome.
Thanks in advance
Victor
p.s This post has been edited for more clarity. Hopefully it will make it more clear as what I am trying to accomplish.
This is probably not a very good idea to do in kernel mode. When are you going to actually do this and guarantee the process is in a state where you could walk the IAT?
What if the process is in the middle of loading a DLL? If you're executing in-thread (i.e. from a syscall or device IOCTL), what if other threads are executing too? Doing this when you're not the OS is a very difficult proposition to correctly do, and it's very easy to destabilize your customers' machines (hell, it's reasonably hard to do even if you are the OS)
Take a look at LdrGetProcedureAddress and the rest of the gang.
Edit:
MmGetSystemRoutineAddress might also be helpful.
Just wanted to thank everyone for their contribution. I did manage to some further research and discovered that there is a kernel mode API called PsLoadImageNotifyCallback that is able to find the base addresss of any process.
I'm working on a project that will require an application that watches a list of directories the user specifies for changes. Also, I'd like to give the users the option of running the application as a service or on an individual basis. Since users can choose to run it on an individual basis I don't think listening for some operating system event triggered by the addition or deletion of files (if such events exist) would be sufficient. I thought about maybe calculating a checksum for the deepest folder and then building up. I could then compare these checksums on subsequent scans to try and pinpoint where the changes have occurred. Would that be an appropriate solution; if not what would be the best way of doing this in an efficient manner?
Also, I'm not quite sure what to tag this as so if you have any recommendations let me know and I'll as them as I see fit.
EDIT: I'll need this method to work on Windows, OS X, and ideally Linux
On Mac OSX, you can use FSEvent, which is similar to inotify interface on Linux.
There exist several methods for tracking changes.
The simplest is to scan the directory on timer and compare timestamps and file sizes. However this is resource-consuming and some changes can be missed (eg. if the file changed twice between checks, first change will be missed).
Next, one can use FindFirstChangeNotification Windows API function (it has it's own limitations, though).
And the most sophisticated and most reliable method is to use a filesystem filter driver. On Windows our CallbackFilter can be used. On MacOS X it's possible to create a filter driver, but I don't know about any ready-to-use product similar to CallbackFilter. On Linux, one can use inotify.
If the filesystems supports CIFS/SMB protcol, you may consider change notification feature in protocol.
Refer to http://msdn.microsoft.com/en-us/library/aa302188.aspx for CIFS overview.
man kqueue
(at least, that's how i'd do it on my most oft targeted OS - but you should specify this in your post)