Hey everyone, I'm the original author of this library. This is actually my first software project ever-- I'm a full-time officer in the military who was just messing around. It's extremely flattering to see this shared so publicly, but I feel the need to pre-emptively apologize to readers. This is just a hobby project for now, but I would appreciate feedback.
Keep rolling with it; there's an opportunity for someone to start a memory-safe protocol analyzer written in a higher-level language than C with a decent TUI, and have it snowball into something big. Best of luck!
Thank you for your service and your project! Looks really well done. I have always wanted to make something using the Charm ecosystem.
A question to everyone:
Can anyone explain the networking part of this a bit? I see the `gopacket` package has been used. Is it only capable of "readonly" operations like this?
I'm trying to make a cross-platform system wide URL-based blocker and was wondering if this (gopacket) could achieve that. Any good resources for studying about the same?
I've seen projects do the same for Linux with proxies.
tshark[0][1] has been the go-to standard for CLI packet analysis for a long time. It'd be really nice if Gosniff provided some kind of documentation on how it differentiates itself from tshark.
+1 on termshark. It is pretty sweet. Much simpler to use compared to tshark/tcpdump imo since it avoids most of the cli flags complexity and uses familiar Wireshark filters
Hrm. Interesting point. There have been a fair number of parser CVEs, but GoLang isn't immune to some of the (based on an admittedly cursory look) parser issues.
A protocol analyzer implemented in anything short of formally-verified code is going to be "vulnerable" to logic errors, such that it might print (or not print) the wrong things. But a protocol analyzer implemented in C standard a decent chance of coughing up RCE.
(Playing devil's advocate): What would the RCE accomplish?
"Parse this packet and get a reverse shell on analyst's workstation?"
To be clear: I am not in any way attempting to disparage the project. It is damned cool, and as a neophyte Go practitioner myself, I very much appreciate its existance and utility. Just working through all the edge cases :)
My thoughts as well. Tshark supports a ton of dissectors. How does this project compare? Being in go, can it reuse the Wireshark dissectors that are written in C?
This, for what it's worth, is a side-effect of using gopacket, which is a deceptively powerful library. You essentially have a big chunk of `tcpdump`'s encoding available to you any time you're working with packet buffers in Go, because of that library; for instance, to debug our BPF-based UDP stuff, there's an interface that shuttles packet snapshots over perf buffers and about 30 lines of Go code to read and decode those buffers. I was surprised at how much I got "for free" just by importing gopacket.
It's great, more people should do cool stuff with it.
Looks pretty good! Some suggestions: it should support tcpdump's command line arguments and start with them as defaults. It would be neat if packets from different interfaces can be shown in different windows.