Capture Serial Communications

[Fractured]

So an engineer wrote a test program to communicate to one of our black boxes. It configures the unit settings for attenuators and switches in the box. He is no longer here to support the program and since im the defacto test engineer, I was wondering if using one of the various comm udf's if im able to capture the raw serial data so I can reverse engineer his program.

I use the CommAPI udf but I havent been able to figure out a capture method.

 

Thanks!

 

 

[TheXman]

There are numerous serial port monitoring tools available on the web.  Some are even free.  If all you want to do is monitor the communication on a given serial port, why try to "recreate the wheel" in AutoIt?    Just use a utility to monitor and capture the communication on that port.  To be able to understand the conversations, you are still probably going to need the specs that define the protocols and commands for communicating with those devices - especially if some of the data is in binary as opposed to ascii.

I have written several serial port communication scripts in AutoIt.  So can AutoIt communicate with your serial devices?  The answer is most likely yes.  There are several different ways to do it.  If you are going to try to recreate the existing test program, then pick one and go for it.

Edited August 13, 2020 by TheXman
Fixed typos

[Fractured]

I have had no problem communicating with the units so far. Ive written numerous programs with autoit so it can use GBIP, serial and usb connections...I just need to see the commands that are sent to the unit from the program. They are plain ascii so it shouldnt be to hard. The problem is that it is a legacy unit with zero documentation (at least now...there might have been some 15 years ago when it was built!!) I cant download anything on the work computer and IT is being a pain about getting me utils so I figured id write it myself. Just not sure how to get it to capture or moniter the serial connection...thats something ive never tried!! So any help would be outstanding! 

[Earthshine]

a simple search on google returns me a udf. start there, learn it, understand it and adapt it to your needs.

 

 

 

Edited August 13, 2020 by Earthshine

[TheXman]

26 minutes ago, Earthshine said:

a simple search on google returns me a udf. start there, learn it, understand it and adapt it to your needs.

The OP is looking for a way to monitor or "see" the serial conversation to & from the box in order to see what the test program is doing.  The OP is basically looking for a serial man-in-the-middle (MITM) type of tool, or serial port Sniffer.  A tool that can see what is "coming across the wire" without interfering with it.  I don't think the UDF that you suggested has that capability.  Most serial communication tools and UDFs designed to converse with serial devices wont either.  Although, I could be wrong.

Here's another topic that may be a little more relevant:

 

Edited August 13, 2020 by TheXman

[Earthshine]

yeah, that was the SECOND hit.... thanks

[Fractured]

Didnt know its called sniffing....soooooo yeah @Earthshine....

Thanks @TheXman for he heads up....ill read and learn  No problem doing that if you look through my old posts. I like digging around and really only ask for help when im stuck or if im having a hazy brain day!

[TheXman]

If you have an older 32-bit Windows PC or laptop around, you may be able to convince your IT people to allow you to use the SysInternals Portmon utility.  It's free, easy to use, and SysInternals is now a part of, and hosted by, Microsoft.

[jchd]

@Fractured how is your setup?

From what I understand you have a "Master" unit sending commands (a PC or something) and a "Slave" (your "black box").

Often serial protocols involve a 2-way communication for reading currently stored settings, acknowledging receipt of commands and the like. In this case you need to capture two data streams M to S and S to M along with timings. To do that you need two serial ports and create an ad-hoc program (not difficult).

If the com is only one-way (M to S) then one spying port is enough and code is simpler, up to involving using standard spying tools as @TheXman said.

[Fractured]

@jchd Correct...my set-up is PC master/Black Box slave. I really just need to captured the output from the master. I dont really need the ack from the slave, since the program shows that. Its was a just hit a button and match acks to the test procedure. Unfortunately our customer wanted an updated system and since our engineers pushed a firmware update to the box, we cant reconfigure it with out knowing what the program sends out. 

The program 1st - sends configuration commands to the box through serial interface, 2nd - checks RF via GPIB interface to network analyzer.

I have the GPIB interface to network analyzer done, with the expected results to compare to due past results saved but need to know the configuration commands. They mysteriously disappeared when the company moved to where it is now.

Fun Fun!!

 

 

[TheXman]

34 minutes ago, Fractured said:

I have the GPIB interface to network analyzer done, with the expected results to compare to due past results saved but need to know the configuration commands. They mysteriously disappeared when the company moved to where it is now.

Have you tried sending common AT modem commands through the serial port to see if it responds?  For instance AT&V is a common modem command that request the current configuration settings.

I worked with a company that designed and manufactured very small tracking and statistics devices.  They had multiple radios (WiFi, GPS, & GSM) as well as multiple configurable onboard hardware & software like accelerometers, timers, GPIO, etc.  The devices were configured using standard and custom AT commands.  We had custom commands to show additional settings and list config commands, like AT%V and AT?.  If your devices respond to such commands, that may give you an idea about the unknown configuration commands and how to set them.

Edited August 13, 2020 by TheXman

[jchd]

OK. Then if you're allowed to install PortMon on the master you can easily trap and record everything occuring on the serial port.

Else grab another PC which you can fully control, make a simple serial spying cable and use PortMon to record the data stream.

MasterPC                             Slave

TxD─────────┬────────────────────────RxD
            │
            │
            │
            │      ╔═══════════╗
            │      ║           ║
            └──RxD ║   SpyPC   ║
            ┌──Gnd ║  PortMon  ║
            │      ║           ║
            │      ╚═══════════╝
            │
            │
            │
            │
Gnd─────────┴────────────────────────Gnd

The serial levels should allow an extra load (the SpyPC RxD line). In case the two RxD loads exceed the capabilities of the Master TxD driver, it's easy enough to assemble a MAX232 chip with four 1µF tantalum capacitors and a 5V supply (e.g. 3x AA[A] batteries). This chips has 2 TTL -> RS232 drivers and 2 RS232 -> TTL receivers. Loopback one receiver to one driver and you have a restored signal to the other load. RS232 input is enough high-impedance so it's negligible.

Edited August 13, 2020 by jchd

[Nine]

In fact, infinitely drawing infinity, you should say it is a Möbius ring.   

[Fractured]

@TheXman All our boxes are using microcontrollers with serial interface cards. They use standard IEEE 488.2 commands (*idn?, etc) and custom ascii commands (i.e. "SW 4 2"....changes switch 4 to position 2). They units dont accept AT commands and sadly this unit only has a serial connection. If it was ethernet capable I have the stuff to capture that, since all our new units use I.O.T crap.

@jchd Ill give your idea a try since I have easy access to components thanks to the job. Im still in talks with I.T., explaining why I need PortMon. My manager has gotten involved so hopefully I will get word today or Monday that its a green light!

@Nine hehehe Thats fun!🤪

[jchd]

Just in case you need to use it, here's a schema you might have to use if the TxD signal from the PC is too week to meet requirements of 2 receivers.
Can be done in minutes on a cheap little bit of protoboard. Limited to 120k Bps and you may not need to link all handshake lines (RTS, DTR, ...). Keep connections to capacitors as short as possible. Be careful about the supply power: 4.5 to 5.5 V max, few mA, correct polarity. Else put a diode in series and a LM78L05A regulator to avoid ruining the MAX232 one day.

Sniffing serial.pdf

Edited August 14, 2020 by jchd

[rudi]

with the sniffing HW specs given by @jchd just PuTTY might be sufficent as described here:

 

https://www.eye4software.com/hydromagic/documentation/articles-and-howtos/serial-port-logging/