diverting from screen to file

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

This may be totally off base, but it's a problem I currently face, and
I don't know where to start. It's not necessarily a Perl problem, but
it seems like something that Perl was designed to handle (at least in

I have a remote application that is a data source but not a RDBMS. I
have a local GUI client that connects with the remote application. I
can use the local client to type in 'queries' which the client relays
to the remote application and displays the results to the screen.
Unfortunately, this is entirely transient and I don't have any means
given by the client to save the results to a file. When I close to
client, there's nothing left on my machine.

I would like to divert the stream coming in from the remote
application to a file. I can confirm that the results are what I want
and then rerun the 'query' to reproduce the results, but I need to
have some persistency. The data does reach my local machine, but I
don't know how to keep it. Any suggestions on where I should start?

The client is an .exe file, and all I know how to get from trying to
read the client is an OD of the code. I even tried to disassemble it
and all I got was an unreadable mess.


Re: GG diverting from screen to file

cartercc wrote:
Quoted text here. Click to load it


1) Use wireshark to capture the data. I often find it's "follow TCP
stream" feature is useful.

2) Create a proxy that sits between the client and server and which
captures the data you want to "persist". This might be a Perl program or
it might be something like socat.


     Writes the transferred data not only to their target streams, but
   also to stderr. The output format is text with some conversions for
   readability, and prefixed with "> " or "< " indicating flow


   socat TCP4-LISTEN:www TCP4:www.domain.org:www

   Installs a simple TCP port forwarder. With TCP4-LISTEN it listens on
   local port "www" until a connection comes in, accepts it, then
   connects to the remote host (TCP4) and starts data transfer. It will
   not accept a second connection.

The docs contain examples for forking proxies and all sorts of
potentially useful options.


Re: diverting from screen to file

In article

Quoted text here. Click to load it

Your choices would seem to be: 1. modify the client to save data, 2.
modify the server to save data, or 3. put a "proxy" between the client
and the server.

If you can't do 1. or 2., then 3. is your only hope. Do you know the
protocol that the client uses to communicate with the server? If so,
you write a proxy program that looks like a server to the client and
looks like a client to the server, and it passes data requests from the
actual client to the actual server, and passes back the responses from
the actual server to the actual client.

If you don't know the protocol, then you can try to reverse engineer it
using some sort of packet sniffer, presuming that the communications
protocol is TCP/IP-based. Or you just use a packet sniffer, such as
tcpdump, to record all traffic between the client and server and figure
out how to extract the pertinent data.

This is not an enviable task. If the client/server protocol is a
proprietary one, it might even violate the terms-of-use to which you
have agreed.

Good luck!

Jim Gibson

Site Timeline