Are there any places where one is preferable to another? Is there a performance impact to using one over the other?
#Alex K.: Small remark: NtFsControlFile is documented in http://msdn.microsoft.com/en-us/library/ff566462(v=VS.85).aspx. Kernel mode application should use ZwFsControlFile function and user mode application can use NtFsControlFile.
#vedang: From you question I would assume that you don't a developer of kernel mode driver. So I will strictly recommend you to use only DeviceIoControl to send FSCTL_XXX codes http://msdn.microsoft.com/en-us/library/aa364230(v=VS.85).aspx.
Only if you plan to write an application which don't use Win32 subsystem and use NT native subsystem only like a small checkdisk application or disk defragmentation application which run at the beginning of the windows start (see session manager registry key) than you will have advantage in using of NtFsControlFile. In all cases of usual work you should use only DeviceIoControl.
I have no idea about implementation, but NtFsControlFile is an undocumented kernel internal and it's use comes with the risk that it will disappear/change implementation at some point in the future, whereas DeviceIoControl is part of the public Win32 API.
Related
EDIT: through another question on the forum, I learned that DeviceIoControl can be async, so question 4 is now just question 2
The extensive Windows driver documentation says little, that I've found, about how a client user-mode app can communicate directly to a specific device. I understand that normally such operations are managed by the Win32 api, but in the case of specific devices or (what I'm interested in) software drivers, I don't know many ways in which it can be done
The docs say that one can use CreateFile, ReadFile, WriteFile etc. to "open" the driver as a "file" and then r/w from/to it, maybe asynchronously if you want. That sounds good but it feels like that can't be the best option for everything, nor is it the only option. DeviceIoControl can have specific control codes and you can command a driver like that, but I can't see any async capabilities in the docs there.
In the driver docs, it's clear a driver must write its callbacks routines for dispatch calls which are sent to it, but I don't understand where these dispatch calls come from, or how a user-mode client might interact with that directly.
Using Valorant's Vanguard as an example software driver, I highly doubt it just r/w'd from a "file" in operation - it seems too abstract to be fast, or not specific enough for a complex system, as all you can do in fileapi.h is read, and write, without any real parametrisation - right?
My questions are:
Must a software driver write routines for all dispatch calls that the docs recommend even though they have nothing to do with hardware?
Are there other techniques than the R/W file api and the DeviceIoControl function to communicate with a specific (software) driver?
Are there efficient, "lean and mean" solutions, when our software driver is entirely custom to the targeted user app, as Vanguard was?
(ignore) Are the async R/W file operations the only way to get this done in a multi-threaded async manner, where the client submits many possibly overlapping calls, or can DeviceIoControl leverage threading and asynchronicity?
To answer your questions
No. Not all dispatch calls needs to be implemented for a software driver. I think only CREATE/CLOSE/DEVICE CONTROL needs to be implemented. You dont even need to implement unload but then you will not be able to unload the driver, which is required for testing. If there are any other required dispatch methods, you can simply return not implemented from those implementation.
Yes. You can use named pipe between driver and application as another way to communicate.
Not sure how much more lean can you get than just implementing the minimum dispatch methods.
You can use multiple threads and synchronous operations OR you can use single thread and asynchronous operation. Depends on what model is best for you.
I am new in Linux and i want to know the internals of drivers and how it is interacting with hardware, so my question is that How the application is interacting with hardware means when the core part will come in picture and what it will do?
When the controller of that driver will come and how it will handle the request generated by the application.
And what is Firmware and when it comes into picture in Linux?
For eg: if i am using usb device like
$ cat /dev/usb0.1
then which is the core of usb(usb_storage.c) and
which is the controller(usb_hub.c)
and how they are related to each other.
Thanks in advance..
Basically linux kernel driver provide interface such as device file node then application can use standard read()/write()/ioctl() to pass parameter to operate hardware. Provide interface in /proc or /sys can be facilities to do that too. Detail implementation how to handle request depends on respective hardware spec.
What is the difference between NtCreateProcess and ZwCreateProcess? In ntdll.dll, both NtCreateProcess and ZwCreateProcess point to exactly the same address
In user-mode the groups of Nt and Zw APIs are identical. In kernel mode they are different. The Nt API contains the actual implementation. The Zw API uses a system-call mechanism and ensures that it is calling in kernel-mode and that there is no need to check the parameters if they contain user-mode addresses. Otherwise you could use the API from user-mode with kernel parameters which would not be good. So it is just a safety mechanism.
Aside from the already given answer (which I don't want to parrot), in my opinion the best answer can be found on OSR Online: here.
Alternatively you can read books on the Native API, such as the one from Gary Nebbett called "Windows NT/2000 Native API Reference", he devotes some space to this very question, or you can use WinDbg (pronounced as "wind-bag") yourself.
There are any advantages or disadvantages of using the WMI instead of Windows API to access to the information of the system? as speed, additional permissions, memory usage.
or depends on the WMI class and how the WMI implements the access to the information?
The main disadvantage of WMI is speed, it is slow to query data and if you are trying to use it during start up it can delay you starting as the WMI service takes a long time to come up.
However, WMI information is richer, as in you need to sometimes make several API calls to get the same amount, some information is a lot easier to get at and the filtering syntax can dramatically reduce the amount code you have to write.
If speed isn't a massive issue, I would always lean towards WMI.
Disadvantage: Speed
Advantage: Wraps the native API, so as API calls change, unless the WMI changed also you will (might) get the benefits. It will also save you some coding.
And richer data. Since programmers can write their own WMI providers, you can get data from third party software. That's what Microsoft is doing in their security center interface-getting data from third-party antivirus and firewall softwares.
Advantage of WMI: Can get info about remote machines as easily as current machine
And impersonation!
You may have your program run with a non-proviledged user, but access a remote machine by specifying credentials.
If it is for system scope
Advantage of WMI:
Do not need to implement additional driver efforts
Disadvantage of WMI:
Need BIOS to wrap code
it is only for Windows. there's no Linux inbox driver.
My company is looking at implementing a new VPN solution, but require that the connection be maintained programatically by our software. The VPN solution consists of a background service that seems to manage the physical connection and a command line/GUI utilty that initiates the request to connect/disconnect. I am looking for a way to "spy" on the API calls between the front-end utilty and back-end service so that our software can make the same calls to the service. Are there any recommended software solutions or methods to do this?
Typically, communications between a front-end application and back-end service are done through some form of IPC (sockets, named pipes, etc.) or through custom messages sent through the Service Control Manager. You'll probably need to find out which method this solution uses, and work from there - though if it's encrypted communication over a socket, this could be difficult.
Like Harper Shelby said, it could be very difficult, but you may start with filemon, which can tell you when certain processes create or write to files, regmon, which can do the same for registry writes and reads, and wireshark to monitor the network traffic. This can get you some data, but even with the data, it may be too difficult to interpret in a manner that would allow you to make the same calls.
I don't understand why you want to replace the utility, instead of simply running the utility from your application.
Anyway, you can run "dumpbin /imports whatevertheutilitynameis.exe" to see the static list of API function names to which the utility is linked; this doesn't show the sequence in which they're called, nor the parameter values.
You can then use a system debugger (e.g. Winice or whatever its more modern equivalent might be) to set breakpoints on these API, so that you break into the debugger (and can then inspect parameter values) when the utility invokes these APIs.
You might be able to glean some information using tools such as Spy++ to look at Windows messages. Debugging/tracing tools (Windbg, or etc.) may allow you to see API calls that are in process. The Sysinternals tools can show you system information to some degree of detail of usage.
Although I would recommend against this for the most part -- is it possible to contact the solution provider and get documentation? One reason for that is fragility -- if a vendor is not expecting users to utilize that aspect of the interface, they are more likely to change it without notice.