Basically I want to send different arbitrary strings from an kmdf. I was thinking to write the strings to a file then let the application read from the same file but I think this is not optimal? especially if there lots of writing to the file.
Anyways, after some research I found that I have to use iotcl interfaces and DeviceIoControl .
Now according to msdn we have
BOOL WINAPI DeviceIoControl( In HANDLE hDevice, In DWORD dwIoControlCode, In_opt LPVOID lpInBuffer, In DWORD nInBufferSize, Out_opt LPVOID lpOutBuffer, In DWORD nOutBufferSize, Out_opt LPDWORD lpBytesReturned, Inout_opt LPOVERLAPPED lpOverlapped
);
So we have lpOutBuffer that should contain the pointer to the string , right? Also according to msdn
lpOutBuffer A pointer to the output buffer that is to receive the data returned by the operation. The format of this data depends on the value of the dwIoControlCode parameter.
dwIoControlCode what is the code to contain strings then ?
If you just want to read and write data you don’t need special IOCTLs, you can use Read and Write requests. Take a look at the Echo sample from the WDK. It shows a simple KMDF driver and a user-mode companion app, with the app and driver exchanging data. Alternatively, the Toaster sample shows you how to use and define your own custom IOCTLs.
Try to build and deploy these samples, and set breakpoints in both the app and driver to see the entire flow of things.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, July 13, 2016 1:22 PM
To: Windows System Software Devs Interest List Subject: [ntdev] Sending an arbitrary string from kmdf to user mode application
Basically I want to send different arbitrary strings from an kmdf. I was thinking to write the strings to a file then let the application read from the same file but I think this is not optimal? especially if there lots of writing to the file. Anyways, after some research I found that I have to use iotcl interfaces and DeviceIoControl . Now according to msdn we have BOOL WINAPI DeviceIoControl( In HANDLE hDevice, In DWORD dwIoControlCode, In_opt LPVOID lpInBuffer, In DWORD nInBufferSize, Out_opt LPVOID lpOutBuffer, In DWORD nOutBufferSize, Out_opt LPDWORD lpBytesReturned, Inout_opt LPOVERLAPPED lpOverlapped );
So we have lpOutBuffer that should contain the pointer to the string , right? Also according to msdn lpOutBuffer A pointer to the output buffer that is to receive the data returned by the operation. The format of this data depends on the value of the dwIoControlCode parameter.
dwIoControlCode what is the code to contain strings then ?
On Wed, Jul 13, 2016 at 1:43 PM -0700, “Alex Margarit” > wrote:
If you just want to read and write data you don’t need special IOCTLs, you can use Read and Write requests. Take a look at the Echo sample from the WDK. It shows a simple KMDF driver and a user-mode companion app, with the app and driver exchanging data. Alternatively, the Toaster sample shows you how to use and define your own custom IOCTLs.
Try to build and deploy these samples, and set breakpoints in both the app and driver to see the entire flow of things.
-----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com Sent: Wednesday, July 13, 2016 1:22 PM To: Windows System Software Devs Interest List Subject: [ntdev] Sending an arbitrary string from kmdf to user mode application
Basically I want to send different arbitrary strings from an kmdf. I was thinking to write the strings to a file then let the application read from the same file but I think this is not optimal? especially if there lots of writing to the file. Anyways, after some research I found that I have to use iotcl interfaces and DeviceIoControl . Now according to msdn we have BOOL WINAPI DeviceIoControl( In HANDLE hDevice, In DWORD dwIoControlCode, In_opt LPVOID lpInBuffer, In DWORD nInBufferSize, Out_opt LPVOID lpOutBuffer, In DWORD nOutBufferSize, Out_opt LPDWORD lpBytesReturned, Inout_opt LPOVERLAPPED lpOverlapped );
So we have lpOutBuffer that should contain the pointer to the string , right? Also according to msdn lpOutBuffer A pointer to the output buffer that is to receive the data returned by the operation. The format of this data depends on the value of the dwIoControlCode parameter.
dwIoControlCode what is the code to contain strings then ?
Basically I want to send different arbitrary strings from an kmdf.
By the way, I just want to correct one potential misunderstanding here.
You cannot SEND anything from kernel mode into user mode. All you can
do is RESPOND to requests that the user-mode application has made.
The output buffer you provide to DeviceIoControl is just a chunk of
empty memory. Your driver can fill it in, and return how much data it
filled in, using the “information” part of
WdfRequestCompleteWithInformation.
Others have already pointed out that you basically make up the ioctl
codes yourself, except that the bottom two bits have to reflect the
transfer type. Probably METHOD_BUFFERED in your case.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
You can also share a memory section between UM and KM. I’ve done this
before and it works quite well.
On Wed, Jul 13, 2016 at 9:52 PM Tim Roberts wrote:
> xxxxx@gmail.com wrote: > > Basically I want to send different arbitrary strings from an kmdf. > > By the way, I just want to correct one potential misunderstanding here. > You cannot SEND anything from kernel mode into user mode. All you can > do is RESPOND to requests that the user-mode application has made. > > The output buffer you provide to DeviceIoControl is just a chunk of > empty memory. Your driver can fill it in, and return how much data it > filled in, using the “information” part of > WdfRequestCompleteWithInformation. > > Others have already pointed out that you basically make up the ioctl > codes yourself, except that the bottom two bits have to reflect the > transfer type. Probably METHOD_BUFFERED in your case. > > – > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > — > NTDEV is sponsored by OSR > > Visit the list online at: < > http://www.osronline.com/showlists.cfm?list=ntdev> > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at < > http://www.osronline.com/page.cfm?name=ListServer> ></http:>
I suspect you are trying to be facetious, and I certainly agree that
Jamey’s shared memory is pretty ridiculous for the original state problem.
But I needed to comment since recently I spent a lot of time explaining to a
customer that what they had implemented after searching NTDEV for solutions
was actually a piece of shit since they had taken what those of us who were
more knowledgeable knew was a joke, and implemented it as a solution.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, July 15, 2016 12:52 PM
To: Windows System Software Devs Interest List Subject: RE:[ntdev] Sending an arbitrary string from kmdf to user mode application
Or, you know, send it on a TCP-connection made from the driver via WSK to the app.
It depends on what kind of strings the OP is talking about. For instance, if these strings are static, the best storage area is probably the registry.
For volatile data, the registry could be usable if the driver “watches” for that registry key read accesses in a monitoring callback. The cost is probably to high in that case.
The problem with the section solution is that the user app must “talk” to the driver to ask for the section to be mapped into its address space and ask for the address where it has been mapped and therefore some data must be written by the driver to a buffer provided by the app.
I’m not sure if the user space address of the KUSER_SHARED_DATA structure that is mapped in tbe address space of every process is a section mapping or a secondary user-mode mapping of a kernel-mode mapping but to share system time (located in the KUSER_SHARED_DATA structure), it looks like the OS uses a kind of section solution. The OS uses a reserved and pre-defined VA range so processes do not need to “talk” to the kernel to obtain the address where the data is stored. The OS is king.
Some may argue that the system time is volatile and it is, but if you look well, nobody can preempt the timer interrupt handler because it has the highest interrupt. So no lock is needed to read system time because there is only one writer and no reader can preempt the writer.
Well I get concerned anytime that someone proposes shared memory with user
space. Unless you are really careful you are likely to open a security
hole.
The biggest problem with shared memory is that you still need to have a
mechanism that indicates new strings are available, and that old strings are
consumed. In almost all cases this is going to involve calls to the
kernel. Considering that a KMDF driver can handle around 100,000+ IOCTL
calls a second on a common system without anything special, and easily hit
500,000 calls with work, one has to ask how many strings the OP is looking
to return?
Bottom line is the inverted call model is still the simplest, and it is well
understood by the industry, so if the initial developer moves on, the next
poor dev who has to look at the code will have a clue.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, July 15, 2016 6:29 PM
To: Windows System Software Devs Interest List Subject: RE:[ntdev] Sending an arbitrary string from kmdf to user mode application
It depends on what kind of strings the OP is talking about. For instance, if these strings are static, the best storage area is probably the registry.
For volatile data, the registry could be usable if the driver “watches” for that registry key read accesses in a monitoring callback. The cost is probably to high in that case.
The problem with the section solution is that the user app must “talk” to the driver to ask for the section to be mapped into its address space and ask for the address where it has been mapped and therefore some data must be written by the driver to a buffer provided by the app.
I’m not sure if the user space address of the KUSER_SHARED_DATA structure that is mapped in tbe address space of every process is a section mapping or a secondary user-mode mapping of a kernel-mode mapping but to share system time (located in the KUSER_SHARED_DATA structure), it looks like the OS uses a kind of section solution. The OS uses a reserved and pre-defined VA range so processes do not need to “talk” to the kernel to obtain the address where the data is stored. The OS is king.
Some may argue that the system time is volatile and it is, but if you look well, nobody can preempt the timer interrupt handler because it has the highest interrupt. So no lock is needed to read system time because there is only one writer and no reader can preempt the writer.
I remember Anton citing the inverted call model as broken and source of lawsuits. Using it could not only cost the dev his shirt but send him to jail. Have a medical device failed because of the inverted call model ?
I don’t know if this was serious but to me, IOCTLs are handy when it comes to share data between user-mode and kernel-mode. Of course this is not the primary meaning of the I/O Manager but drivers don’t have system calls and the only function table drivers have is the dispatch table.
Anyway, inverted call or IOCTLs, you rely on the I/O Manager. Using a pending IRP does not make a lot of difference.
I remember Anton citing the inverted call model as broken and source of lawsuits. Using it could not only cost the dev his shirt but send him to jail.
I doubt that conversation ever occurred. Do you have a reference?
I don’t know if this was serious but to me, IOCTLs are handy when it comes to share data between user-mode and kernel-mode. Of course this is not the primary meaning of the I/O Manager but drivers don’t have system calls and the only function table drivers have is the dispatch table.
I’m not sure what you’re getting at here. Statistically speaking, it’s
likely that most of I/O manager’s requests are ioctls. And ReadFile,
WriteFile and DeviceIoControl certainly are system calls, in exactly the
same sense that Unix uses.
Anyway, inverted call or IOCTLs, you rely on the I/O Manager. Using a pending IRP does not make a lot of difference.
It doesn’t make ANY difference. An inverted call IS a pending ioctl.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, July 15, 2016 7:57 PM
To: Windows System Software Devs Interest List Subject: RE:[ntdev] Sending an arbitrary string from kmdf to user mode application
I remember Anton citing the inverted call model as broken and source of lawsuits. Using it could not only cost the dev his shirt but send him to jail. Have a medical device failed because of the inverted call model ?
I don’t know if this was serious but to me, IOCTLs are handy when it comes to share data between user-mode and kernel-mode. Of course this is not the primary meaning of the I/O Manager but drivers don’t have system calls and the only function table drivers have is the dispatch table.
Anyway, inverted call or IOCTLs, you rely on the I/O Manager. Using a pending IRP does not make a lot of difference.
The analogy of the shared data section by the system for time, is flawed for
this conversation. Time is a single field, that only the current value is
of important, and there is no need for the user processes to communicate
back to the kernel. The OP’s question is how to deliver a number of
arbitrary length strings to a user process, this requires tracking available
space if you try to do it with shared memory, so requires communications
both ways. Bringing up the system shared space for time does nothing but
confuse the person looking for the solution.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, July 15, 2016 6:29 PM
To: Windows System Software Devs Interest List Subject: RE:[ntdev] Sending an arbitrary string from kmdf to user mode application
It depends on what kind of strings the OP is talking about. For instance, if these strings are static, the best storage area is probably the registry.
For volatile data, the registry could be usable if the driver “watches” for that registry key read accesses in a monitoring callback. The cost is probably to high in that case.
The problem with the section solution is that the user app must “talk” to the driver to ask for the section to be mapped into its address space and ask for the address where it has been mapped and therefore some data must be written by the driver to a buffer provided by the app.
I’m not sure if the user space address of the KUSER_SHARED_DATA structure that is mapped in tbe address space of every process is a section mapping or a secondary user-mode mapping of a kernel-mode mapping but to share system time (located in the KUSER_SHARED_DATA structure), it looks like the OS uses a kind of section solution. The OS uses a reserved and pre-defined VA range so processes do not need to “talk” to the kernel to obtain the address where the data is stored. The OS is king.
Some may argue that the system time is volatile and it is, but if you look well, nobody can preempt the timer interrupt handler because it has the highest interrupt. So no lock is needed to read system time because there is only one writer and no reader can preempt the writer.
>As Tim said show us the conversation. I have never heard of such a claim, in the 22 years I’ve been writing Windows drivers
Sorry about this statement. I can’t find the discussion so I take it back.
>I don’t know if this was serious but to me, IOCTLs are handy when it comes to share data between user-mode and kernel-mode. Of course this is not the primary meaning of the I/O Manager but drivers don’t have system calls and the only function table drivers have is the dispatch table.
I’m not sure what you’re getting at here. Statistically speaking, it’s likely that most of I/O manager’s requests are ioctls. And ReadFile, WriteFile and DeviceIoControl certainly are system calls, in exactly the same sense that Unix uses.
I was talking about the special case of running ring 0 code. The goal was not to run a device but just to run ring 0 code for instance to check system data in a security project.
As you know many malwares are ring 0 malwares and they definitely do not run in kernel to run a device. I was wondering if sending data from kernel-mode to user-mode using IOCTLs is legitimate. Can you use I/O although this has nothing to do with I/O ?
The thing is: you have no other choice.
How can an antivirus’s system component communicates with a user-mode companion ? The I/O Manager is the only mean there although this has nothing to do with I/O.
> I remember Anton citing the inverted call model as broken and
> source of lawsuits. Using it could not only cost the dev his shirt
> but send him to jail.
I doubt that conversation ever occurred. Do you have a reference?
How meta. No doubt this is an instance of “I saw something and didn’t realize it was a joke”, not long after, indeed, this exact phenomenon was just warned about…
I was talking about the special case of running ring 0 code. The goal was not to run a device but just to run ring 0 code for instance to check system data in a security project.
You’re trying to create a distinction where there is none. Only a small
fraction of ring 0 code is actually driving a device. Much of it is
specifically to provide services to user mode clients.
As you know many malwares are ring 0 malwares and they definitely do not run in kernel to run a device.
I still don’t know what point you’re trying to make Most ring 0 code is
not there to talk to a device. They use the exact same kernel APIs and
communication mechanisms as all other kernel code.
I was wondering if sending data from kernel-mode to user-mode using IOCTLs is legitimate. Can you use I/O although this has nothing to do with I/O ?
The thing is: you have no other choice.
Right. It’s a pointless question. You communicate to kernel code using
ReadFile, WriteFile, and DeviceIoControl.
How can an antivirus’s system component communicates with a user-mode companion ? The I/O Manager is the only mean there although this has nothing to do with I/O.
Well, that’s semantic nit-picking.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Please show us the thread where I was supposedly saying this bollocks…
Concerning the lawsuits and criminal charges, you seem to be confused - these are definitely not my “wheelhouse” . There is, indeed, a certain NTDEV regular who is fond of speaking about this topic (BTW, he participates in this thread), but even this poster speaks about these things only in context of discussing either “unsupported” techniques( particularly hooking - the very mentioning of this particular technique makes him shout in capitals), or alleged software theft and IP violations (which happens to be his other “fixation”). As you must have noticed, I clash with him over the various issues almost on a regular basis. To make it even more interesting, he is a great fan of the “inverted call” technique, and never misses his chance to mention it whenever it applies.
Therefore, there is a good chance that your claim is somehow based upon your confused and misinterpreted understanding of one of our “exchanges” - you must have mixed up the claims and arguments from the both sides into some incredibly nonsensical “word salad”, and, for the reasons better known to yourself, attributed it to me…