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.
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?
+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
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.
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.
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!
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.
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.
21 comments
[ 3.4 ms ] story [ 64.7 ms ] threadIt's great, more people should do cool stuff with it.
How does it compare to Wireshark' console cousin tshark?
"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 :)
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.
[0] https://tshark.dev/ [1] https://blog.wireshark.org/2014/07/to-infinity-and-beyond-ca...