Show HN: Stratoshark, a sibling application to Wireshark (stratoshark.org)

321 points by geraldcombs ↗ HN
Hi all, I'm excited to announce Stratoshark, a sibling application to Wireshark that lets you capture and analyze process activity (system calls) and log messages in the same way that Wireshark lets you capture and analyze network packets. If you would like to try it out you can download installers for Windows and macOS and source code for all platforms at https://stratoshark.org.

AMA: I'm the goofball whose name is at the top of the "About" box in both applications, and I'll be happy to answer any questions you might have.

52 comments

[ 2.9 ms ] story [ 101 ms ] thread
having used wireshark since i was a kid... this looks really promising
Being able to use Wireshark in Kubernetes is super exciting. I can't wait to get started!
Long, long time user of Wireshark and I instantly recognize your name. Thank you for all the great work over the years :-)

Looks really awesome! I didn't see Linux installation instructions so clicked on the link to the source code, but it links to the Wireshark source[1]. Is Stratoshark part of the same repo as Wireshark? Is Linux supported by Stratoshark?

[1]: https://gitlab.com/wireshark/wireshark

Can this program do more than just observe and trace what happens?

Can one use it to set up some rule to suppress some of the syscalls sent to a specific process? Or alter them by some logic on the go?

The first section on the homepage doesn’t give me a good sense of what the application does. The references to Wireshark suggest it has something to do with network traffic but that doesn’t seem to be the case. It also talks about cloud but nothing seems to be cloud-specific?
The blog article is a bit more descriptive : https://sysdig.com/blog/stratoshark-extending-wiresharks-leg...

tl;dr version: system calls, but in the wireshark ui. (I've probably oversimplified that!)

Thanks for your work! Been using Wireshark for many years after it was used for a network course in university.

Why do you focus on "what happens in your cloud" when we talk about system calls? It'd seem it's useful for any machine, is it just bad marketing copy or am I missing something?

You're welcome! It was initially developed as part of my day job at Sysdig, a cloud security company. The initial feature set and use cases focus on getting .scaps (system call and log captures) from cloud environments, but you're entirely correct -- this has much more general applications including troubleshooting and education just like Wireshark does on the networking side.
Thanks for confirming and thanks again for the amazing work.
Hey Gerald, It's Chris from the CACE days. Nice to hear from you. I see this is part of wireshark proper, I'll look into getting this into debian
Thanks for the feedback! I'll see if we can make the top of the site more descriptive.

Update: Changed the first sentence to "Stratoshark lets you explore and analyze applications at the system call level using a mature, proven interface based on Wireshark.

So, DTrace with Wireshark UI?
We don't share any code with DTrace, but it's not a bad analogy. As with my other reply about strace, it'd be interesting to see if we can more closely integrate Stratoshark, strace, and DTrace in the same way that Wireshark integrates with tcpdump.
The OP URL has been flagged as grayware by Palo Alto and is thus inaccessible to a large number of people, possibly indicating typosquatting, or being miscategorized?

https://wiki.wireshark.org/Stratoshark is a good link for those who can't reach the stratoshark URL directly. The OP link may get recategorized and become accessible in the meantime.

Well, crap. The domain and site are still fairly new, so maybe that's the issue? Is there anyone here from Palo Alto that can take a look?
Going through their URL filtering site and requesting a recategorization is the best option for now, unless someone from the company sees it.

https://urlfiltering.paloaltonetworks.com/

Done. We've been upgraded from medium-risk "grayware" to low-risk "generally do not contain content that is useful to the end user" which is technically better, I suppose.

Update: We're now Low-Risk / Computer-and-Internet-Info.

Wireshark is to tcpdump as stratoshark is to strace.

Did I get the analogy right?

Pretty much. It's part of the same ecosystem as Sysdig OSS[1], which works much like strace. It uses the same underlying libraries as sysdig and Falco, and you can move capture files between them.

It'd be interesting to see if we can integrate more fully with strace as well, but that might require updating strace itself.

[1]https://github.com/draios/sysdig

Why is it talking about clouds and stratospheres then? strace is pretty far from "the cloud" isn't it?
How does it trace syscalls on macos? Do you need to disable SIP?
Right now the UI runs on Windows, macOS, and Linux but you can only capture system calls on Linux via Falco libs[1]. Expanding local capture to include macOS and Windows is definitely something we'd love to do!

[1]https://github.com/falcosecurity/libs

Awesome! Thanks for your work on this and everything else.

Once you add capture on macOS with something like dtrace, could you concievably capture a system call inside Docker on macOS and watch it trickle down through the linux hypervisor and then to the host darwin kernel and back?

How does it conceptually track the handoff of system calls between hypervisors/VMs/containers/etc?

In this case you would presumably have a capture file that contained syscall events at both the macOS boundary and at the Linux VM boundary. At the present time it would be like capturing traffic on either side of a firewall and loading it into Wireshark (which is something people do!) You'd have to correlate the events visually/manually but adding an automatic correlation feature is well within the realm of possibility.
Yeah I was imagining something like the TLS session tracing feature in Wireshark that lets you see all the packets related to a single TLS connection.

I currently struggle debugging opaque containers and VMs that run lots of concurrent async jobs, having some kind of tool to trace and group syscalls through the stack would be amazing.

(comment deleted)
It is not clear what the architecture for system-call capture is. Is it ptrace, ebpf or some custom thing or some combo? What is the overhead of running this?

The tool looks really cool, hopefully it moves ui state of art beyond windows xperf

Does sysdig (and stratoshark by extension) still require custom out-of-tree kernel module to function?
No, with the parameter '--modern-bpf' you can use eBPF. So, no kmod required any more.
Would I be right in assuming this is like Sysinternals procmon but with a better interface and for Linux?
The tools are similar in many ways, but Stratoshark shares Wireshark's dissection, filtering, and UI code, which provides a more low-level details and a free-form filtering language. Stratoshark is currently limited to capture on Linux (we're hoping to expand to macOS and Windows in the future) and the UI runs on all three platforms. There's an enhancement request[1] to add Procmon file support but I haven't had a chance to investigate what that might require.

[1]https://gitlab.com/wireshark/wireshark/-/issues/20317

I just want to thank you for wireshark. I use it almost every day when I'm troubleshooting why this or that piece of industrial controls hardware springs a leak in its bit plumbing.

You have the rare distinction of developing a tool that will probably outlive us all. So, thanks!

Wow, I've been a wireshark user for many years, this is really exciting.
(comment deleted)
We have a Python application that we develop inside Docker on macOS using the `python:3.11-slim-bullseye` image that it would be great to generate scap files from for viewing with Stratoshark. I tried installing sysdig in that image but ran into kernel module errors when trying to run it. Should we expect that to work? Am I missing an easier method?
You might try passing `--modern-bpf` to sysdig. It has traditionally captured syscalls using a kernel module, and it sounds like that's where your errors are coming from. Newer versions have added eBPF support, which doesn't require a kmod but you have to pass in the `--modern-bpf` flag.
Absolutely nailed it, that worked! Thanks so much for the pointer.