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.
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 have seen many articles on LWN about allowing for dynamically loadable Linux security modules (LSM), but it is impossible to find concrete information on how it can be done. The LSM hooks (I don't know if this is the right term) aren't exported in the kernel anymore, but their addresses can be retrieved with kallsyms_lookup_name and then assigned to function declarations.
There are some mentions of LSM hooks not being unloadable, but is this true? What does it even mean? If a Linux loadable kernel module registers some hooks, is it unable to unregister them later? Why is this case? Is there a workaround or a way to force them to unload?
Do dynamically loadable LSMs have to be written differently than built-in LSMs? Or do both use the same conventions and interfaces?
It's technically possible to hotpatch the kernel to add hooks to anything. https://stackoverflow.com/a/6742086/2079814
Another possibility is to leverage kpatch to inject an LSM.
Neither of these options would be considered best practice, but should work in theory. I haven't seen the latter method (kpatch) done before.
I am programming an activation code for my application, I need to provide the key file with information about the licensed computer, I need to retrieve information about some devices like processor ID and DiskDrive Serial number, and the BIOS Serial as well ,, and so on with some devices, but these are the major ones.
I need to combine the method with another application programmed by another language so I cannot use WMI, but I can use winapi.
is there a way to fetch the physical data using winapi?if so, then how?
If you are able to call Windows API functions, then you can use WMI. After all, the WMI interface is part of the Windows API.
Take a look at the Win32_BIOS class and the PROCESSOR_POWER_INFORMATION structure.
Accessing motherboard information without WMI seems not to be doable with current means. Here you can find a similar question:
Access Motherboard information without using WMI
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.
Right now, my application is using the c-ares asynchronous DNS resolver library on Windows below cURL, and I have users complaining that it behaves differently from other windows apps. One particular user said that "other applications are using the Microsoft DNS client" and experiences no problems.
cURL itself has an asynchronous DNS implementation that uses getaddrinfo() in a thread. My guess is that would be equivalent behavior to using the "DNS Client" and its host of functions (e.g. DnsQuery?)
So, dear Lazyweb, I ask if there is a tangible difference between the behavior of getaddrinfo() vs. using the actual Dns* APIs from the Win32 API.
Looking at the sources it seems ares actually implements the dns protocol for querying host names (and doesn't directly call getaddrinfo) - I'd expect that to miss out on things like WINS lookups, and god knows what other kind of stuff windows can do to look up names.
The easiest way to do DNS queries on Windows is to use DNSQuery (and derivated functions, utf8, wbytes, ansi). Unless you need asynchronous resolution, in this case I would recommend to keep using c-ares or other similar API.
I'm not sure about WINS or other windows specific resolution (not part of DNS specs) not being covered by c-ares. It would help if you can give us some examples, maybe we can get them implemented in c-ares as well.