Connecting to Exisitng TCPClient

[JOSheaIV]

So we have this software that we can use a Telnet client to tap into, sending and receiving data in VT220. The software when it initally connects, connects to port 23, and you simple send it an \r command, and which point you are then repointed to a login screen.

That inital connection sits on "localhost:23", however, the second you get to that login screen, you are technically on a differnet address (the LocalEndPoint). Well for my job I want to do something like a Remote Desktop concept. What can happpen is someone is current running this telnet simulator, and I want to be able to view the data they are sending receiving.

I current have a TCPClient that can connect to the "localhost:23" with no problem, but when I try to tap into the user's IP:Port, I get an error like "No connection could be made because the target machine actively refused it". And if I use try to use a TCPListener, and do any sort of AcceptSocket the code just hangs.

Hopefully this makes sense, forgot to each lunch so brain not firing on all cylinder.

To sum it up, I am trying to create a program that can read the VT220 data being transmitted from a telnet simulator that uses a TCPClient (or Socket). Knowing the IP and Port that user is on, I want to be able to tap into the stream of data. Almost like a man in the middle attack you might say (no it's not for malicious sake, it's to allow us to view what people are doing to help them).

[rproffitt]

Since time has passed I'll share our solution. We didn't try to sniff packets and such but added a debug tap/log/output to our setup/control/terminal program so where there was trouble we had the needed output.

I'll take your word that " we have this software " as you are the author and need to add the feature to see all this.

[JOSheaIV]

Ohh so you guys spit the data out into say a log file, and read from that?

While we can do that (I have already developed the code to parse the VT220 output), there are some draw backs. One was we wanted to be able to drive as well, a step in help type thing.

And yes the application is ours, we send data to a telnet type client, and then recieve data back (that data is user inputs, we send up display data)

[rproffitt]

Or... add a port that one can connect to for debugging. We never went that far as the log files were always more than enough.

[JOSheaIV]

Ahhh I see. You that extra port might be a tricky one, since there can easily be 5-100 people running our product at the same time, and it looks like piggybacking on one just ain't going to fly.

That being said, I have started to do research on man in the middle type of attacks, with the hope that I can intercept the data (injecting my own will be the next trick, not sure how I'd go about doing that).