Using USB device from inside NDIS filter driver

Arsen

Hi all. I'm trying to use some USB device from an NDIS filter driver. I have a driver for this USB device, but for use from user mode code. Now I want to use this USB device (FTDI) from my driver code. Who can help me. What should I learn, where can I get useful information. Thank you.

Arsen

Please, say Me. I'm right?
A driver for any device consists of 2 parts:

• Kernel mode driver

• Part of user mode (functions)
  I need to bypass the user mode features and use the kernel mode driver for this device directly.
  So I need to find a driver stack for that device, find a suitable device node within that stack, and pass an IRQ to that driver.
  Question:

• How can I find a node for this device.

• How to determine which IRQs to send to this device

Tim_Roberts

Is this the FT600/FT601?

You can't do that. FTDI does not expose the USB interface to their device. The only access is through their user-mode DLL. This annoyed me as well, because on Linux I didn't want to trust their DLL, but that's all there is. You can pipe out to a user-mode helper service, or you can switch to another device. The FT600 is a very simple device that would not be hard to recreate.

Arsen

Thank You, Mr Tim_Roberts. In that case, please help me, how can I work with USB devices from kernel mode, bypassing theire drivers. Well, if we will recreate somting like it, I will need to access to them from my kernel mode program. plese help me to find litrerature, to understand, what I am need to know. USB specifications I have read and understand. But I dont know, how to realize it from my driver.
What it means, when You say " You can pipe out to a user-mode helper service". Now my NDIS driver sends all packets to the user mode programm, via the IRQ, and it uses FT200 (or FT600) device with the help of DLLs, expossed by FTDI. But I want to use FTXXX directly from NDIS driver. I want to pass all packets to that device from inside NDIS driver directly. If I cannot use anything already ready, from what to begin.
What I have to write. Driver for that device or only code for accessing to that device?
Thank You vary much.

Arsen

Can I access this device directly from kernel mode code. What do I need for this? This is just working with computer ports or something else, considering that with this USB port will be attached only one device, without any USB hub.

rob18767

@Arsen said:
how can I work with USB devices from kernel mode, bypassing theire drivers.

By not using FTDI devices.

Microchip do some microcontrollers with USB. They may also grant you written permission to use their VID and PID depending upon the end product.

Tim_Roberts

Look, all you did was ask the exact same question again. The answer hasn't changed. FTDI (foolishly) does not expose their hardware details. So, unless you want to spend time and energy reverse engineering their protocol from USB analyzer traces, what you want is impossible. I did spend part of a week trying to do that reverse engineering (and I have a gift for that), but I gave up.

What I have to write. Driver for that device or only code for accessing to that device?

You can't do either. There isn't enough information. They don't have a driver -- they use libusb, which uses WinUSB.

Arsen

Thank You.

Arsen

Hi all. Can anyone help me?
I want to use some USB device from some driver. Simply write and read to this USB.
I don't want to write a USB device driver. I only want to write something to a USB device or read from a USB.
With Wireshark I can see everything I need to read or write. Wireshark shows me all the transfers between the host and the USB, but how can I implement this conversation inside the driver?
Thank you.
Thank you Mr Tim_Roberts.

Mark_Roddy

The open source usb capture driver used by wireshark is here: https://github.com/desowin/usbpcap

Tim_Roberts

You can't access their device directly, because it is already owned by WinUSB. You could talk to that driver by opening a file handle, just like their user-mode applications, but again you'd have to reverse engineer the transfers to make.

I assume what you have done is design a piece of hardware to help with your filtering, and you put an FTDI 601 chip to talk to it. This was a huge design mistake, and you should have done more investigation before you began. There are many USB interface chips available that are flexible enough to allow your custom usage, but FTDI doesn't make them.

Arsen

Thank you, Mister. Mark_Roddy and Mr. Tim_Roberts.
Yes. You are right. We have some FTDI device and we are referencing this device with D2XXX interface functionality. So far we have interacted with this device from a user mode program. Now I want to interface with this device from inside NDIS driver.
I have code that allows me to do everything in user mode. Now I want to move all this code into my NDIS driver and access this device from within the driver rather than from a user mode program.
I'm ready to study anything, but I don't know where to start.
Thank you.

Arsen

I believe that I should first open the USB device I have, then program that USB, and then write and read to or from it.
I would be very grateful if you help me at least with the first point. How to open this USB device from the NDIS driver code.
From inside of the usermode program I do
1. FT_OpenEx((PVOID)"Some_USB", FT_OPEN_BY_SERIAL_NUMBER, &hUSBDevice);
2. FT_Write(hUSBDevice, pICMPHeader - 3, dataLength + 3, &nBytesW); // I judst copied from my code
3. FT_Read(hUSBDevice, pICMPHeader + GREHDRLEN - 1, (((dataLength + 1) & 0xFFFFFFFE) + PARTKEYLEN + 1), &nBytesR);

I can't understand how to do this from the NDIS driver, given that we have a proprietary driver for this USB device (FTD33...)

Arsen

What is the best approch. To work with already existing USB driver or access it directly. And how to implement the preffered approch.

Tim_Roberts

You keep asking the same question over and over. I've told you the answer three times. Asking it again is not going to change the answer. There is no "best approach". You have made a bad design decision, given your intended use model.

The documented interface from Windows is through FTD3XX.DLL (Linux uses libusb). You obviously cannot use FTD3XX.DLL from kernel mode. Since FTDI has not documented either (a) the USB interface to their device, or (b) the IOCTL interface to their driver, everything you do is going to be hackery. If all you are using is the basics (FT_Create, FT_SetChipConfiguration, FT_ReadPipe, FT_WritePipe), you may be able to disassemble FTD3XX.DLL to figure out how to open the device and which ioctls they are sending, but that's no way to design a product you're going to sell commercially.

The best approach is to change your hardware design to use a chip that you can control. That's not a cheap solution, but it is the RIGHT solution.

Arsen

Sorry and thank You dear mr.Tim_Roberts.

Arsen

Dear Mr.Tim_Roberts. Can I install winUSB.sys as a function driver in driver stack for my device and contrl my device via the winUSB documented functions. Thank You.

Tim_Roberts

If you uninstall the FTDI driver, then you could certainly load WinUSB, but if you did so, what would you send? There is zero documentation on the USB protocol required by the device.

Arsen

Ok, Mr Tim Roberts. My deep gratitude

Arsen

Mr Tim Roberts.
I know that answering my question is not within your competence,
but please answer if possible.
We use an FTDI device to convert text into an unreadable format.
In FTDI I write and read using D2xxx interface functions.
Now I want to add the functions of a regular file flash drive to the device.
And so that when you connect an FTDI device to a computer, the FTDI driver will automatically load and thereby the device becomes what it is intended for.
That is, the FTDI device drivers were loaded automatically from the same device that was previously turned on as a flash drive.
Let me clarify!
When you turn on an FTDI device (flash drive), it should be recognized as a regular file flash drive, from where the FTDI driver will be loaded(autoRun.inf), after which the device will acquire text conversion functions.
Thank you very much Mr. Tim Roberts, even if you don't reply.

Tim_Roberts

Some people have attempted to do that by adding a virtual CD-ROM drive interface to their USB devices, hoping to use the autorun facility to load their custom driver. Most places now run with autorun turned off, because of the enormous security problems it represents.

However, to do that, you have to have a USB interface chip that can be programmed to do this. The USB Mass Storage Class is complicated, and of course it all has to be handled entirely within the device. The FTDI chips are designed to serve a very specific and very narrow purpose, which is why you are in this mess to begin with.

And if you were going to redesign your hardware to add a more capable USB chip, as you need to, then you wouldn't need this hack at all, because you wouldn't use the FTDI DLL. You could have it serve the purpose you need, instead of trying to implement hackery to work around your hardware limitations.

Phil_Barila

Time for the Captain Obvious question, why not put the FTDI DLL inside a helper service and use inverted calls to invoke calls into the DLL?

Arsen

Thank You

Arsen

Mr. Phil_Barila. I have already done what You say. But this doesn't seem like the best approach since we need a program running in user mode to do this, which is not desirable. It will be better to use it from a kernel mod (my NDIS driver).

Tim_Roberts

Why do you think it will be better? Remember, user code and kernel code run at exactly the same speed. What you want is impossible from kernel code but easy from user code. That should be a powerful motivator.

Arsen

Well.

Arsen

Best regards, Mr. Tim_Roberts.
Suppose we have installed a driver for some USB device and a driver for the network (NDIS filter driver).
It is clear that they belong to different driver stacks.
How to pass IRP from network driver to USB device(may be IOCTL).
Thank you very much.

Arsen

I red that WinDDK documentation has a such topic. I installed WinDDK.
Found there 3 files: winddk.chs, winddk.chw, winddk.col. But how open and read that files.
All other files have .chm and .chi extntion. .chm is readable.
But how read winddk.chs, winddk.chw, winddk.col files.

Tim_Roberts

You use IoGetDeviceObjectPointer to open a handle into the other device, just as if you were an application calling CreateFile.

The Windows DDK help is all onlint now, https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/_kernel/ . What you have is the old Windows Help system, which has been inactive for maybe 10 years. Only the .chm can be read. The others are just indexes used internally.

Arsen

Thank You very much, mr.Tim_Roberts.