<span id="mailbox-conversation"><div>Thanks or all the responses y’all.   My need for sniffing has been satisfied — partly though your help and partly though some dumb luck / trial an error I determined what I need to about my Sharp TV.</div>
<div><br></div>
<div>cheers,</div>
<div><br></div>
<div>-Darrell</div></span><div class="mailbox_signature">
<br>—<div>http://golliher.net</div>
</div>
<br><br><div class="gmail_quote"><p>On Wed, Aug 12, 2015 at 2:43 PM, Michael B. Trausch <span dir="ltr">&lt;<a href="mailto:mike@trausch.us" target="_blank">mike@trausch.us</a>&gt;</span> wrote:<br></p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>
<div>On Wed, 2015-08-12 at 11:31 -0700, Darrell Golliher wrote:</div>
<blockquote type="cite">
<div>Anybody have a easy to use way to listen in on a network connection that uses a line based text protocol?  In other words something that taps into a telnet connection, but on a custom port.    I’m looking for something to show me exactly what is transpiring between my networked Sharp TV and the Sharp remote control app.   </div>
<div><br></div>
<div>I tried wireshark, though I’m completely unskilled in its use.  What it produces for me does not look like the text based traffic I’m looking for.</div>
</blockquote>
<div><br></div>
<div>If you know the &lt;ip:port&gt; tuple you wish to monitor, just use tcpdump (which you can use to save a file to later analyze in Wireshark).</div>
<div><br></div>
<div>Also, common mistake: Telnet and raw TCP stream are *NOT* the same.  Telnet specifies a network virtual terminal on top of the TCP socket, and a Telnet link isn't wholly binary clean.  A raw TCP stream is just that.  It just so happens that you can often use a telnet client to connect to a raw TCP stream because the Telnet commands are often ignored by ASCII/UTF-8 based layer 7 protocols.  If you want to use a binary-safe method that doesn't inject any extra bytes into the stream, use netcat, socat, or similar tools.</div>
<div><br></div>
<div>However, you should note that you may not find what you're looking for... commands over sockets are typically encoded and/or encrypted.  Many first-screen/second-screen device pairings use HTTPS for the RPC communications.  They often use text-based protocols for the RPC itself, but that information is wrapped in an encrypted session.  In order to analyze that successfully, you'll have to find a way to insert a MITM between the remote and the TV.  Even for an expert that can be difficult to impossible; you have to get both sides to trust your MITM before you can successfully capture and analyze, because in some cases the only way to MITM is to brute-force the ability to forge a CA signature (infeasible) or modify the software on both ends to disregard the trust checks (likely also infeasible).</div>
<div><br></div>
<div>No matter how you go about it, you've quite a bit of learning to do in order to do network taps well, even if you're just looking for a solution to a one-off problem.  Today's operating systems and components are so chatty and much of the traffic is signed, encrypted, or both, meaning you have to have high confidence in what you're looking at before you start making sense of it.  I highly recommend practicing with tcpdump before moving on to Wireshark.  You'll have a much better understanding of the capabilities of Wireshark then, and be able to use it better.</div>
<div><br></div>
<div>
<span class="Apple-tab-span" style="white-space:pre">        </span>— Mike</div>
<div></div>
</div></blockquote></div><br>