Replies: 2 comments 23 replies
-
|
What I observed and what killed a few hours of my lifetime: when I zipped everything on the same machine and then unzipped again in Downloads/ and copied to /Applications there was never an issue. But downloading triggers the whole (cyber) security cargo culture we all so love. Luckily, I remembered that we just lost a few hours worth of company time on another download quarantine a few weeks ago and luckily someone then remembered that there is an xattr flag. Took some more time to finally nail down the correct flag. |
Beta Was this translation helpful? Give feedback.
-
|
re: title; looking at https://www.wireshark.org/docs/wsug_html_chunked/ChCustCommandLine.html, there isn't anything available from the wireshark CLI args. The extcap definitively hasn't access to this. I would recommend hopping over to Wireshark's discord server and into the "developer den", asking there for this feature. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I am not sure what caused the packetflix-handler.zip to be detected as a malicious download
First, chrome warns a user that this is a malicious download, and then suddenly xattr is required.
None of these steps were necessary for the handler app I initially shared, so I think it makes sense to dig a little bit deeper and see what caused that behavior. siemens/cshargextcap#14
And maybe there is a wireshark option that sets the window title that can also be set in the AppleScript to actually show the contianer/pid name and interface for the captured flow. Right now it is just saying "capturing from packetflix"
Beta Was this translation helpful? Give feedback.
All reactions