[sane-devel] reverse engineering / usbsnoop

Sat, 11 Sep 2004 19:07:01 -0400 (EDT)

On Sat, 11 Sep 2004, Frank Zago wrote:

> Mbosowo I Sampson wrote:
>> After reading reams of documentation, I think I have a grasp on how the 
>> USB protocol works. I started snooping the usb traffic of my hp scanjet 
>> 3970 so I can start writing the backend for it. I have a couple of 
>> questions...
>> 
>> With Snoopy Pro it seems to stop logging information once the actual scan 
>> begins. Someone else posted something on SF page about it stopping once 
>> the bulk transfer began. I was wondering if anyone knew how to get around 
>> this. I tried sniffit, but the documentation says it only works for NT 
>> 2000.
>
> sniffit is not a usb sniffer.
> Try http://benoit.papillault.free.fr/usbsnoop/

sorry, i meant sniff-bin. I tried it on XP using VMware and it complains 
about running it on a local drive. I was wondering if anyone has and any 
sucess with this program under vmware.

>
>> 
>> I was looking at a usb dump,
>> http://reapoff.sourceforge.net/hpscanner/full_scan.dump.gz
>> 
>> posted by this guy,
>> http://reapoff.sourceforge.net/hpscanner/hp4470c.txt
>> 
>> On this page he says that the chipset he was looking at had 244 registers. 
>> How exactly can you tell that by the logs?
>
> May be because 243 is the highest register he saw?
>
>> I'm looking at the logs, and I'm not sure where to start. I was to start 
>> simple by writing a stand alone application that tuns on the lamp, then 
>> build on it from there. I have a session log, but I have no idea how to 
>> find out what register and values are needed to turn on the lamp. Any 
>> tips?
>
> Are you sure your scanner has the same chipset than the 4470c?
>
> You need to get an idea of what your scanner is based on:
> - open it and get the chipset names
> - running "strings" on the windows drivers may yield some data
> - check the windows driver .INF

Sorry, i wasn't clear. The HP 3970 doesn't use the same chipset at the 
4470. I was referring to that as a generic example. Trying to see where 
and how to get started. The 3970 uses the REALTEK RTS8822L. I opened a 
sourceforge page so that I could post a link to the sniff log, but seeing 
as how that won't be ready for a couple of days, i'm going to post a 
small part of the log here.

first questions. Maybe i missed this when i read teh usb spec, but the 
first three packets sent by the host are identical. How does the device 
know to return three different packets?

1	in down	n/a	0.015	GET_DESCRIPTOR_FROM_DEVICE
URB Header (length: 80)
SequenceNumber: 1
Function: 000b (GET_DESCRIPTOR_FROM_DEVICE)
1	in up	n/a	0.062	CONTROL_TRANSFER	12 01 00 02 00 00 
00 40	0x00000000
URB Header (length: 80)
SequenceNumber: 1
Function: 0008 (CONTROL_TRANSFER)
PipeHandle: 80d89f80

SetupPacket:
0000: 80 06 00 01 00 00 12 00
bmRequestType: 80
   DIR: Device-To-Host
   TYPE: Standard
   RECIPIENT: Device
bRequest: 06
   GET_DESCRIPTOR
Descriptor Type: 0x0001
   DEVICE

TransferBuffer: 0x00000012 (18) length
0000: 12 01 00 02 00 00 00 40 f0 03 05 23 00 01 01 02
0010: 03 01
     bLength            : 0x12 (18)
     bDescriptorType    : 0x01 (1)
     bcdUSB             : 0x0200 (512)
     bDeviceClass       : 0x00 (0)
     bDeviceSubClass    : 0x00 (0)
     bDeviceProtocol    : 0x00 (0)
     bMaxPacketSize0    : 0x40 (64)
     idVendor           : 0x03f0 (1008)
     idProduct          : 0x2305 (8965)
     bcdDevice          : 0x0100 (256)
     iManufacturer      : 0x01 (1)
     iProduct           : 0x02 (2)
     iSerialNumber      : 0x03 (3)
     bNumConfigurations : 0x01 (1)
2	in down	n/a	0.062	GET_DESCRIPTOR_FROM_DEVICE
URB Header (length: 80)
SequenceNumber: 2
Function: 000b (GET_DESCRIPTOR_FROM_DEVICE)
2	in up	n/a	0.078	CONTROL_TRANSFER	09 02 27 00 01 01 
00 e0	0x00000000
URB Header (length: 80)
SequenceNumber: 2
Function: 0008 (CONTROL_TRANSFER)
PipeHandle: 80d89f80

SetupPacket:
0000: 80 06 00 02 00 00 09 00
bmRequestType: 80
   DIR: Device-To-Host
   TYPE: Standard
   RECIPIENT: Device
bRequest: 06
   GET_DESCRIPTOR
Descriptor Type: 0x0002
   CONFIGURATION

TransferBuffer: 0x00000009 (9) length
0000: 09 02 27 00 01 01 00 e0 01
     bLength            : 0x09 (9)
     bDescriptorType    : 0x02 (2)
     wTotalLength       : 0x0027 (39)
     bNumInterfaces     : 0x01 (1)
     bConfigurationValue: 0x01 (1)
     iConfiguration     : 0x00 (0)
     bmAttributes       : 0xe0 (224)
     MaxPower           : 0x01 (1)
3	in down	n/a	0.078	GET_DESCRIPTOR_FROM_DEVICE
URB Header (length: 80)
SequenceNumber: 3
Function: 000b (GET_DESCRIPTOR_FROM_DEVICE)
3	in up	n/a	0.093	CONTROL_TRANSFER	09 02 27 00 01 01 
00 e0	0x00000000
URB Header (length: 80)
SequenceNumber: 3
Function: 0008 (CONTROL_TRANSFER)
PipeHandle: 80d89f80

SetupPacket:
0000: 80 06 00 02 00 00 27 00
bmRequestType: 80
   DIR: Device-To-Host
   TYPE: Standard
   RECIPIENT: Device
bRequest: 06
   GET_DESCRIPTOR
Descriptor Type: 0x0002
   CONFIGURATION

TransferBuffer: 0x00000027 (39) length
0000: 09 02 27 00 01 01 00 e0 01 09 04 00 00 03 ff 00
0010: ff 05 07 05 81 02 40 00 00 07 05 02 02 40 00 00
0020: 07 05 83 03 01 00 fa
     bLength            : 0x09 (9)
     bDescriptorType    : 0x02 (2)
     wTotalLength       : 0x0027 (39)
     bNumInterfaces     : 0x01 (1)
     bConfigurationValue: 0x01 (1)
     iConfiguration     : 0x00 (0)
     bmAttributes       : 0xe0 (224)
     MaxPower           : 0x01 (1)
4	??? down	n/a	0.093	SELECT_CONFIGURATION
URB Header (length: 100)