2017-01-18 15:57 GMT+01:00 Paul Offord <[email protected]>: > Hi, > > > > As suggested, I’ve submitted the Syncro code for consideration. Change > 19664 - https://code.wireshark.org/review/#/c/19664/ >
Hi Paul, such patch, if merged, should be based on master branch: only bugfixes are being backported in master-2.2 branch. Best regards, Pascal. > > Best regards…Paul > > > > *From:* [email protected] [mailto:wireshark-dev-bounces@ > wireshark.org] *On Behalf Of *Alexis La Goutte > *Sent:* 08 January 2017 14:30 > > *To:* Developer support list for Wireshark <[email protected]> > *Subject:* Re: [Wireshark-dev] Remote Control Plugin - Can I submit to > the Wireshark project > > > > Hi Paul (and others) > > for disable when code will be review, we can help you to add this "feature" > > About sharkd for me, it is different because sharkd is for a web wireshark > (like CloudShark) > > Cheers > > > > On Sun, Jan 8, 2017 at 12:03 PM, Paul Offord <[email protected]> > wrote: > > Hi Dario, > > > > At the moment there is an option to limit access by client IP address, the > default being 127.0.0.1. I agree regarding TLS and probably a shared > secret. Disabled by default would be fine. Removable at compile time – > I’m not sure how practical that is but I don’t have a problem with the idea. > > > > Limiting the functions available via the interface would address your > other concerns. > > > > It’s true that I have a very specific reason for building this feature ( > see https://www.youtube.com/watch?v=YAyPyKaxDlY ) but I think if it were > available it would spark ideas in others. > > > > I still need to check out Jakub’s sharkd. It doesn’t do what I need at > this time. I just need to assess if it could be made to do it. > > > > Best regards…Paul > > > > *From:* [email protected] [mailto:wireshark-dev-bounces@ > wireshark.org] *On Behalf Of *Dario Lombardo > *Sent:* 07 January 2017 17:09 > *To:* Developer support list for Wireshark <[email protected]> > *Subject:* Re: [Wireshark-dev] Remote Control Plugin - Can I submit to > the Wireshark project > > > > Is the remote control protected in some way? If not, it would open a new > set of exploitations in wireshark. With this feature unprotected, not only > is an attacker able to send arbitrary data into the network, but they're > also able to control wireshark as they were the user. I'm really concerned > about this feature. While its use in a specific use case, like, > maybe, Paul's one, to make it generally available could pose users open to > attacks or at least to unwanted remote control. > > > > AFAICS to be generally acceptable such a feature should be > > - removable at compile time > > - disabled by default > > - authorized (eg. by a password) > > - channel protected (to avoid the reverse engineering of the communication > protocol, eg through SSL/TLS). > > > > Remember that many users have private, not-routed networks where they > capture packets, but others capture in open networks. > > Dario. > > > > On Fri, Jan 6, 2017 at 2:34 PM, Paul Offord <[email protected]> > wrote: > > Hi, > > > > Some time ago I wrote a Wireshark plugin (called Syncro) that enables a > program to send commands to Wireshark. The command set is based on the > capabilities provided by the Wireshark Plugin IF API (go to frame, apply > filter, etc.). > > > > The commands are sent to Wireshark via a TCP connection, and so there is a > small TCP service running on a separate thread in Wireshark. The TCP > service, multi-threading and thread-to-thread communications are built on > Qt. Note the email trail below, where Roland suggests that it might not be > necessary to use Qt. > > > > I’d like to submit this to the Wireshark project as I think it could form > the basis for a general capability of controlling Wireshark from a loosely > coupled application. Is this code suitable for submission to the project? > > > > Thanks and regards…Paul > > > > *From:* [email protected] [mailto:wireshark-dev-bounces@ > wireshark.org] *On Behalf Of *Roland Knall > *Sent:* 05 August 2016 11:57 > *To:* Developer support list for Wireshark <[email protected]> > *Subject:* Re: [Wireshark-dev] Adding Qt5 libs via VS Additional > Dependencies > > > > This is exactly what I do here with my plugin. Although without the TCP > part. The method to do it without using Qt in the dissector is to implement > a tap interface in the dissector, and register the plugin on that > interface. The plugin than can start the TCP server and monitors the tap > interface and reacts accordingly to the commands. Would work fine for you, > the same way you do it now, but would be far easier to maintain. The > dissector would be stable and does never need to change, and all you would > have to recompile is the plugin. > > > > regards > > Roland > > > > On Fri, Aug 5, 2016 at 12:46 PM, Paul Offord <[email protected]> > wrote: > > Hi Roland, > > No, not really an RPC interface. Some very simple commands and events > flow back and forth, like this: > > Command|GoToFrame|55 > > Response|MovedToFrame|55 > > Event|MovedToFrame|67 > > We needed it to be a dissector to enable us to detect when the user moves > within a trace so that we can generate a suitable asynchronous event. We > also needed the functionality now, and it had to work with standard WS > releases, so it had to be a plugin of some sort. By the way, we are not > planning to submit this to be incorporated into the main stream code. > > You can see Syncro in action here http://www.youtube.com/watch? > v=anEZGfF4P10&t=5m5s if you are interested. > > Best regards…Paul > > > > *From:* [email protected] [mailto:wireshark-dev-bounces@ > wireshark.org] *On Behalf Of *Roland Knall > *Sent:* 05 August 2016 11:10 > > > *To:* Developer support list for Wireshark <[email protected]> > *Subject:* Re: [Wireshark-dev] Adding Qt5 libs via VS Additional > Dependencies > > So, if I understand it correctly, it is a RPC interface? I still think, > implementing this as a dissector is a major overkill, and will also lead to > issues further down the line, if dissectory API changes or similar issues. > I'd implement such an interface via a simple plugin architecture, which > would have the added benefit, that you do not have the need for an active > dissection runnning, to query the instance. A dissection should be mainly > about "How to interpret packet data", which is not the case here. > > regards > > Roland > > > > On Fri, Aug 5, 2016 at 11:33 AM, Paul Offord <[email protected]> > wrote: > > Hi Roland, > > The dissector is called Syncro and it allows a remote process to access > the WS plugin_if extensions through a TCP connection. We wanted to be able > to achieve this without building a custom version of WS and so built it as > a dissector. We don’t use any of the GUI stuff from Qt, just the TCP > server functionality, multi-threading functions and Signals & Slots to > communicate between threads. > > Best regards…Paul > > > > > ______________________________________________________________________ > > This message contains confidential information and is intended only for > the individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. > > Any views or opinions expressed are solely those of the author and do not > necessarily represent those of Advance Seven Ltd. E-mail transmission > cannot be guaranteed to be secure or error-free as information could be > intercepted, corrupted, lost, destroyed, arrive late or incomplete, or > contain viruses. The sender therefore does not accept liability for any > errors or omissions in the contents of this message, which arise as a > result of e-mail transmission. > > Advance Seven Ltd. Registered in England & Wales numbered 2373877 at > Endeavour House, Coopers End Lane, Stansted, Essex CM24 1SJ > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > > ____________________________________________________________ > _______________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject= > unsubscribe > > > > > ______________________________________________________________________ > > This message contains confidential information and is intended only for > the individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. > > Any views or opinions expressed are solely those of the author and do not > necessarily represent those of Advance Seven Ltd. E-mail transmission > cannot be guaranteed to be secure or error-free as information could be > intercepted, corrupted, lost, destroyed, arrive late or incomplete, or > contain viruses. The sender therefore does not accept liability for any > errors or omissions in the contents of this message, which arise as a > result of e-mail transmission. > > Advance Seven Ltd. Registered in England & Wales numbered 2373877 at > Endeavour House, Coopers End Lane, Stansted, Essex CM24 1SJ > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > > ____________________________________________________________ > _______________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject= > unsubscribe > > > > ______________________________________________________________________ > > This message contains confidential information and is intended only for > the individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. > > Any views or opinions expressed are solely those of the author and do not > necessarily represent those of Advance Seven Ltd. E-mail transmission > cannot be guaranteed to be secure or error-free as information could be > intercepted, corrupted, lost, destroyed, arrive late or incomplete, or > contain viruses. The sender therefore does not accept liability for any > errors or omissions in the contents of this message, which arise as a > result of e-mail transmission. > > Advance Seven Ltd. Registered in England & Wales numbered 2373877 at > Endeavour House, Coopers End Lane, Stansted, Essex CM24 1SJ > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > ____________________________________________________________ > _______________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject= > unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
