This won't replace an official sdk if it were ever to be released.. but it could serve in the interim.
1:53 am - a little progress
The old Windows 98/XP debug program [SnoopyPro] proved somewhat cranky and difficult to get working. Many people seemed to think it would not run on Windows 7 x64.. turns out it will run.
The caveats come from misunderstanding much of the Microsoft documentation regarding the boot time F8 option to 'disable' signed driver enforcement.
Basically they said to 'disable' enforcement.. not that you could "load" unsigned drivers.
For example, to get Snoopy to work. I had to install the Windows SDK and DDK to get the tools to create a Self-Signed Code Signing Certificate, perform an [embedded] signing of just the USBSnoop.sys and USBSnpys.sys files and [pre-install] them by copying them to windows\system32\drivers.
Then run the [SnoopyPro.exe] separately and choose [not to] Unpack the drivers again.
See in the old days (and today) you had a choice of installing drivers from a binary, or packaging them separately with an INF file so the PnP service could inventory and load them for you when a device was plugged in.. this was not so normal for debugging software.. so they tended to perform the driver "injection" manually and carried the drivers inside themselves.. fast forward to Windows Vista days.. and signed driver enforcements.. and you had to make sure to [embed-sign] drivers that were to be carried inside the binary and deployed "at will" upon a system.
It didn't help the documentation provided [only] alluded to embedded signing requirements and proceeded to "document" in an old Word doc format with an example that did not explicitly demonstrate the signing procedure.. so your left with.. hints and innuendos.. and well.. "typical" ms documentation.
Normal outsiders "assumed" this meant you could disable driver "must-be-signed" enforcement
Microsoft insiders "meant" you could disable enforcement of "properly" signed drivers
The difference being, if you used a self-signed cert, its illegal "normally" but legal if you disable enforcement.
The problem being, if you have a driver that is "improperly" signed, perhaps a bad intermediate or cross sign cert.. you could get that driver to work with F8 or a boot option.. and "think" you got away with something when you really did not. -- the reality being.. it was signed.. just not "properly" signed.
[Next] you have to "Unblock" the [Silent] Executeable "Block" placed on files identified as coming from the Internet.. basically right-click SnoopyPro.exe then Properties and [Unblock].. otherwise running it would silently deny complete access to the system.. even if run as Administrator.
[Finally] you have to run in compatibility mode with [Windows Vista (Service Pack 2)] as Administrator.. and the program will start and be ready to capture packets.
There is no good documentation on how to use the program, but basically you F2 to display currently detected USB devices, select the one that says Czurtek and right-click to Install and Install service.
This preassumes you already installed the Snpys bridge > File > Install service and you [did not Unpack drivers, because you copied the "signed ones" into place]
Also you had already imported the signed certs for CA and self, and rebooted to press F8 and choose not to "enforce" security for improperly signed drivers -- see the "key" is the drivers are "signed", but they are not signed "properly" -- if they were not signed at all.. they are just not loaded and no warning messages are provided.
This all to avoid the $100+ requirement to get a crossed signed code signing certificate and to collect URB packets on my currently installed Window 7 x64 machine with the Czurtek drivers and software communicating with the scanner.
[With all of that "Preamble Ramble" the actual use is, all the setup did was insert a bridge driver for copying packets "sneaked out" from the driver stack for the connected device by the "filter" driver acting as a man-in-the-middle between the device and the operating system].. so once its built.. you basically [unplug/plug] the scanner into the PC with the usb cable and the SnoopyPro program opens a new dialog window inside its parent window and begins "capturing" packets.
I think its suppose to interpret them on the fly.. but it did not for me.. the window remained empty, but the status bar across the top of the new window indicated packets were being captured, a pause button and a stop button. I ran the Czur software then let it capture for a while and stopped it and used the File menu option from SnoopyPro to save the packets to a file. Then re-opened the log in SnoopyPro and it "interpreted the packets" as shown below:
There are two "devices" for the Czur scanner, one is the image device the other is a sound device. Or that is what the Windows Device Manager identifies them as.. how the software communicates with them after they are classified is vendor specific.
I can see that it appears a number of [USB Control] type packets are being exchanged, and witnessed a Bulk transfer.. possibly related to initating a snapshot in the software to capture an image.
But the interpretation of the communications is far from complete.. I am not even sure that SnoopyPro would be the best way of capturing and interpreting the packets.
I had thought to use it with USBrobot to replay the communications to test possible function calls for a users API.. but I have a lot of doubts about the stability and complete-ness of the data capture.. the Bulk transfer seemed to decode somewhat incompletely.
I am beginning to think if this were a Tape Media Changer USBSnoopy might be okay.. but there might be better tools for a more reliable analysis.. USBpcap looks interesting.. and then Wireshark could be used with LUA to intepret the packets.. even added to.. to test and develop an API that could be used in many operating systems.
Mostly this test was for completness sake.. I didn't want to over look a potentially easier way of capturing data and interpreting the results.
