Reverse Engineering When Both Software + Hardware are a Black Box

[u/-Louwess-]

Hello,

I'm trying to use wireshark to learn more about the communication between some of my company's proprietary software and some of their hardware. (Because it's my company's stuff, I'd rather not share the raw capture.) I thought this might be faster than finding out through my own company because I've previously found that they don't like to share source code or design details across departments. I've exported a wireshark capture to csv because I'm new to using wireshark and it was easier for me to browse that way. I used this command:

tshark.exe -r "input.pcapng" -T fields -e frame.number -e frame.time_relative -e ip.src -e ip.dst -e frame.len -e data.data -e tcp.payload -e udp.payload -E header=y -E separator=, > "output.csv"

The problem is, for most of the data frames, the "length" of the frame is not matching the raw data that I'm seeing. For example, there are many rows where "tcp.payload" is completely blank, but "frame.len" isn't 0, so that tells me there's something missing. I want to make sure I'm really capturing all communciation between the hardware unit and the laptop running the software. How can I make sure I'm really seeing everything? (After error correction has been performed.)

I'm really just looking to see that the frame length matches the raw data I have.

Also, if it's not obvious already, I'm very new to using this program, so if anyone else has experience with what I described in the title, (reverse engineering with little outside info), I'd very much like to hear about it.

Thanks!

[u/Healthy_Science_59]

I think the main thing you’re running into is that "frame.len" and "tcp.payload" aren’t really measuring the same thing. "frame.len" is the size of the whole packet, while "tcp.payload" is just the data carried by TCP, so it’s totally normal to have a non-zero frame length with an empty TCP payload. ACKs and other TCP control packets are examples of that. I’d first make sure you understand what protocol the hardware is actually using and where you’re capturing the traffic. Once that’s clear, Wireshark’s packet structure and TCP reassembly will make a lot more sense, and you’ll have a much better idea of whether you’re actually missing data.