search

desowin / usbpcap

USB packet capture for Windows
http://desowin.org/usbpcap
896 stars 170 forks source link

Increasing buffer and snap length? #89

Closed voideater closed 4 years ago

voideater commented 4 years ago

From the help menu in the software it seems like this should be a straight forward thing to do using -s and -b , however, when I try to open the pcap files afterwards it seems like passing these arguments don't have any influence on the captured data, thus I wonder, what's the proper way to do this?

I've tried with both USBPcap 1.3.0 and the newest version available on the website, but it's always the same result; 65kB packages, whereas I need to capture 1MB. Is this possible at all, or?

I'm on a Win10 x64 system.

desowin commented 4 years ago

There was a bug #86 in older USBPcap releases related to snaplen that was fixed in USBPcap 1.5.3.0. Are you sure you observe the problem with USBPcapCMD version 1.5.3.0? Does it work when using USBPcapCMD as Wireshark extcap (copy USBPcapCMD to Wireshark/extcap directory, then restart Wireshark)?

voideater commented 4 years ago

Thanks for the quick reply. I left the office right after writing my post so couldn't respond until now.

I tried reinstalling everything now (and rebooting afterwards), also switching to the development build of Wireshark (and manually copying the USBPcapCMD.exe to the extcap folder), but I still can't capture what I need.

I also tried the following command in the command line: USBPcapCMD -d \\.\USBPcap3 -s 1500000 -b 2000000 -A -o DUT.cap but I still end up with a file that can't be opened with either Wireshark or tshark in order to extract the usb.capdata.

When I try to run tshark -r DUT.cap -s 1500000 -B 2000000 -T fields -e usb.capdata > usb.txt I get the following error tshark: The file "DUT.cap" appears to be damaged or corrupt. (pcap: File has 1048603-byte packet, bigger than maximum of 262144), which for me suggests that the capture is faulty to begin with. Also, I don't know why it suddenly says the maximum packet size is 262144, so a lot of things are confusing here.

I assume the order of the arguments on the command line doesn't matter? If I remember correctly, e.g., tshark expects arguments for snaplength and bufferlength that differ from the default values to be provided after the device, but I haven't seen anything like this for USBPcapCMD.

desowin commented 4 years ago

What you written basically confirms that USBPcap is working correctly.

What you are observing is https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15985. With the latest automated Wireshark build you should be able to open files with snaplen up to 1 MiB (1048576). In your case the driver is carrying 1 MiB payloads and thus, when the USBPcap pseudoheader is added, it goes out of the limit. Could you please comment under Wireshark bugzilla issue with some details about the driver and/or device that uses such big payloads?

The 262144 is 256 KiB, which is former limit in libpcap/Wireshark (it was 64 KiB, then it was bumped to 256 KiB and recently to 1 MiB).

voideater commented 4 years ago

Ok, so the data is captured fully, but it's Wireshark/tshark that struggles with processing the file? If so that's a good thing.

I'll write a few words on the Wireshark bugzillaa with some details. It's just an Android phone in fastboot-mode for which I flash various partitions to. I'm trying out a tool for restoring bricked devices and whatnot and I just want to see what kind of data it sends to the device (check for any difference from publicly available firmwares, etc - hence why I need the complete payload), and for some reason it use this payload size.

Since the phone is in fastboot mode I would assume this (payload size) should be a feature of fastboot itself and not related to the tool I'm using, so I suspect this can be reproduced by having an Android phone with unlocked bootloader in fastboot mode and just run fastboot flash <partition> <file.img>.

Anyways, thanks for taking time to answer and help me on the right track.

Update: In case someone else show encounter the same problem and don't want to wait for Wireshark and libpcap to be patched, I bypassed this by downloading the source for Wireshark and libpcap and changing DLT_USBPCAP in libpcap/pcap-common.c and WTAP_MAX_PACKET_SIZE_USBPCAP in wiretap/wtap.h and building over. I can't say for sure if patching libpcap/pcap-common.c is necessary but since it was mentioned in https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15985 I just did it to be on the safe side.