破解设备和应用程序驱动程序之间的 USB 通信？
我有一个 USB 设备，它使用应用程序驱动程序与我的应用程序进行通信。我必须制作一个应用程序来实际模拟与应用程序驱动程序的 USB 通信，这样我就不必连接我的设备进行 USB 通信。
简而言之，我必须使用另一个应用程序破解应用程序驱动程序和设备之间的 USB 通信。应该注意的是，通信所需的数据将包含在这个新应用程序中。
不应为了与此代理 USB 应用程序通信而调整应用程序驱动程序。该驱动程序是根据一些国际标准开发的，不会针对此类应用进行更改。
预期的操作系统将是 Windows XP 和 Windows 7。
我如何模拟 USB 设备，以便在没有任何实际硬件的情况下测试应用程序？
I have a USB device that communicates to my application using an application driver. I have to make an application that actually simulates this USB communication with App Driver so that I don't have to connect my device for USB communication.
In short, I have to hack USB communication between App Driver and the device using another application. It should be noted that data required for communication will be contained with this new application.
App Driver should not be tweaked in order to communicate with this proxy USB application. The driver is developed under some international standards and will not be changed for such applications.
Intended operating system will be Windows XP and Windows 7.
How can I simulate the USB device, so I can test the application without any real hardware?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
硬件设备仿真可以在不同级别上完成。较低级别 - 更好的仿真，但通常低级别仿真很难开发。它也可以是硬件仿真——实现与真实设备相同的通信协议的硬件设备。但我们来谈谈软件模拟。
考虑以下系统结构：高层（UI）-硬件访问Dll-驱动程序-通信端口（USB等）-硬件设备。可以模拟每个级别：从硬件设备本身到硬件访问 Dll。
要模拟硬件设备，您应该与硬件开发人员交谈（我猜不是您的情况）。您想要捕获驱动程序调用，使其对整个软件系统透明。我认为您有更好的机会在 osronline 上获取有关此方式的信息 - 该网站上没有驱动程序专家。
您可以模拟驱动程序，提供另一个驱动程序甚至用户模式库，它导出 DeviceIoControl、ReadFile、WriteFile。这对于硬件访问 Dll 来说几乎是透明的 - 在仿真模式下，它应该调用仿真的 DeviceIoControl 而不是 Win32 DeviceIoControl。
最后，您可以通过在 Dll 本身中提供模拟函数或通过编写具有相同接口的另一个库来模拟硬件访问 Dll。
如您所见，最后两个选项非常简单，并且允许在没有真实设备的情况下进行高级应用程序开发。当然，你想要的方式是最困难的，并且会得到最好的结果。再次尝试在 Windows 驱动程序开发人员网站中获取有关此内容的更多信息。
同样重要的是，这个完整链条（从 UI 到设备）的哪一部分是您的，哪一部分是由您的客户开发的。如果客户提供硬件设备、驱动程序和硬件访问Dll（SDK），你模拟这个SDK就足够了，不需要写复杂的hook东西。
Hardware device emulation can be done at different levels. Lower level - better emulation, but usually low level emulation is difficult to develop. It can be also hardware emulation - hardware device which implements the same communication protocol like real device. But let's talk about software emulation.
Consider the following system structure: Hight level (UI) - hardware access Dll - driver - communication port (USB etc.) - hardware device. It is possible to emulate every level: from hardware device itself to hardware access Dll.
To emulate hardware device you should talk with hardware developers (not your case, I guess). You want to catch driver calls, to make this transparent to the whole software system. I think you have better chance to get information about this way on osronline - there are no driver experts on this site.
You can emulate the driver, providing another driver or even user-mode library, which exports DeviceIoControl, ReadFile, WriteFile. This is almost transparent to hardware access Dll - in emulation mode it should call emulated DeviceIoControl instead of Win32 DeviceIoControl.
Finally, you can emulate hardware access Dll, by providing emulation functions in Dll itself, or by writing another library with the same interface.
As you see, last two options are quite simple, and allow high-level application development without real device. Of course, the way you want to do this is most difficult, and will give the best results. Again, try to get more information about this in Windows drivers developers site.
It is also important, what part of this full chain (from UI to device) is yours, and what part is developed by your customer. If customer supplies hardware device, driver and hardware access Dll (SDK), it is quite enough for you to emulate this SDK, without writing complicated hooking stuff.