evtioread and evtiowrite isn't call

Hello. I used this article http://www.osronline.com/article.cfm?article=446 to create a driver filter for usb flash. Installed this driver as the upper filter driver. In windbg, when debugging, the breakpoints in the ioread and oiwrite events do not call when I try to read or write data to the device. The breakpoints on the device addition and retrieval events are triggered. What could be the problem?

This is a question for NTDEV…What class are you filtering? It’s entirely possible that reads/writes aren’t used where you are in the stack. Try filling in EvtIoDeviceControl and EvtIoInternalDeviceControl.

-scott
OSR
@OSRDrivers

The driver is installed for devices in the stack along this path: HLM\System\CurrentControlSet\Enum\USB. The example uses EvtIoDeviceControl and EvtIoInternalDeviceControl. The breakpoint is triggered by EvtIoInternalDeviceControl.

"xxxxx@mail.ru windbg"@lists.osr.com wrote:

Hello. I used this article http://www.osronline.com/article.cfm?article=446 to create a driver filter for usb flash. Installed this driver as the upper filter driver. In windbg, when debugging, the breakpoints in the ioread and oiwrite events do not call when I try to read or write data to the device. The breakpoints on the device addition and retrieval events are triggered. What could be the problem?
The driver is installed for devices in the stack along this path:
HLM\System\CurrentControlSet\Enum\USB. The example uses
EvtIoDeviceControl and EvtIoInternalDeviceControl. The breakpoint is
triggered by EvtIoInternalDeviceControl.

What is the overall goal you are hoping to accomplish?  From your
message, I’m guessing you don’t really understand how drivers are
stacked in Windows.

Writing to a USB flash drive involves 6 or more drivers.  Each one has
its own interfaces in and out, and you need to know where you have to be
to get the information you want.  When you do a WriteFile to a USB flash
device, that request goes to a file system driver, and that file system
driver sees it as an IRP_MJ_WRITE request, which would go to an
EvtIoWrite handler.  That file system driver converts the write into
partition-relative requests, and sends to a volume driver.  That driver
converts the write to disk-relative request, which it sends to a disk
driver.  In this case, that is disk.sys (in the ENUM\USBSTOR tree). 
That driver talks to the storage driver, which is usbstor.sys.  That’s
the driver in Enum\USB.  That driver sends USB requests (URBs) to
usbhub,sys, which talks to the host controller driver.

Below that very top level, almost all inter-driver communication is done
via ioctls or internal ioctls.  It’s quite possible that, by the time
you get to usbstor.sys where your filter driver lives, all of the
requests have been turned into IRP_MJ_SCSI, which is the same as
IRP_MJ_INTERNAL_DEVICE_CONTROL.

So, tell us what you want to learn, and someone here can guide you on
where to filter.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thank you, Tim.
I’m really new to driver development. Therefore, I do not understand much. The main task for me is in cryptographic protection of data. I need to encrypt all the data on the flash drive and decrypt the data when authorizing. From this task and a brief study of the material, I came to the conclusion that I need a upper filter driver. I would be very happy to receive advice.

I think this can be done by creating a filesytem minifilter driver.

On Thu, Apr 12, 2018, 1:11 PM xxxxx@mail.ru
wrote:

> Thank you, Tim.
> I’m really new to driver development. Therefore, I do not understand much.
> The main task for me is in cryptographic protection of data. I need to
> encrypt all the data on the flash drive and decrypt the data when
> authorizing. From this task and a brief study of the material, I came to
> the conclusion that I need a upper filter driver. I would be very happy to
> receive advice.
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
>
> 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&gt;
></http:>

I have an analog of the driver I need, written by a past employee, but it is written on the WDM model. In the driver itself there are a lot of bugs, so I decided to rewrite it to the WDF model. I ran into the problem of choosing which class to include it. In addition to the basic functions of the driver such as encryption and data decryption, there is also the possibility of partitioning the drive into areas for different users, allocating a separate area for storing passwords and information about users. Or does it make sense to try to fix the errors in the old driver?