tcpdump: pcap_loop: invalid packet capture length 1698917240, bigger than snaplen of 262144
Aniketh01 opened this issue · comments
I was using FriTap to perform full capture using '-f' and I receive a message such as 'tcpdump: pcap_loop: invalid packet capture length 1698917240, bigger than snaplen of 262144'.
Following is the command used to execute FriTap: python3 friTap.py -m -s -f --pcap mycapture.pcap --keylog=mykeylog.keylog <package_name> -v
Additionally, the full capture pcap when opened in Wireshark indicates that the "_mycapture.pcap" is corrupted. For instance, both src and dst IP address is corrupted and points to localhost. Additionally, in HTTP header field I see messages such as these:
[truncated]l\001\001\001�\000\000\000d\000\000\000�\000\000\000\001\001o\000;\000\000\000/re/frida/AgentMessageSink/137ac7aa76164367af65aff5df041619\000\000\000\000\000\002\001s\000\033\000\000\000re.frida.AgentMessageSink16\000\000\
This makes me wonder if it is because tcpdump is also capturing the communication between frida server and the app? Is the packet size higher and corrupted because friTap is rewriting packets multiple times somewhere?
Finally, one more question: What is the difference between --socket_trace and --full_capture options?
I have attached an example screenshot of the corrupted pcaps that friTap returns. If we can pinpoint the exact problem here, I'm happy to submit patches if required. Thanks.
Thx for reporting this issue, we'll have a look into this.
Regarding your question if friTap is somewhere rewriting packets when running in full packet capture mode (-f). This should normally not the case, because in full packet capture mode tcpdump is used to to do the capture. During runtime all sockets of the target application are traced from friTap. Finally when the capture stops the created PCAP is filtered, in a way that only the application traffic remains in the PCAP. Therefore no rewriting should happen, but maybe there is some sort of logic bug.
The hooks for the plaintext traffic are still applied when friTap is running in full capture mode but not evaluated. Therefore it might be the case that this traffic is also inside the PCAP although this should be filtered away due to the traced sockets.
Internally friTap is invoking precompiled tcpdump binaries from here. Is the tcpdump error still present if you invoke tcpdump directly?
# tcpdump -i any -s 0 -w test_capture.pcap
Which tcpdump version are you invoking? Maybe there is a new release from tcpdump which could resolve this issue.
Regarding your last question. When doing a socket trace -sot its up to the user to do the PCAP capture and friTap is only responsible for tracing the network traffic of the target application and creates from that a Wireshark display filter.
Hi, I tested the latest version of friTap and the issue still persist. Or could it be due to the type of OS and the Device I'm using for testing?
There we actually some bugs in the --full_capture logic. Should be solved in the latest release. If not just reopen it and we will look into this. If possible, than provide us the used app and Android version so we able to reproduce this issue :-)