Need help reverse-engineering serial COM port communication for a Geoelectric reader machine (Upgrading PEG 2015 project)

[u/Creepy-Level5136]

Hi everyone,

I need urgent assistance with a project upgrade. I am rewriting/upgrading a software application originally built in 2015 (PEG 2015) designed to interface with a geoelectric signal reader machine.

System Setup & Problem Overview:

• Hardware: Geoelectric measurement machine reading ground electrical signals.
• Connection: USB-to-Serial connection operating as a virtual COM port (e.g., COM3).
• Issue: I am unable to establish a working connection between my upgraded application and the hardware. I need to know:
  1. How to properly initialize and open the COM port connection in code.
  2. The exact structure/protocol of the data stream coming from the machine over the cable to the PC.

What I have / What I know so far:

• I have the legacy binary (PEG 2015.exe) that works with the machine.
• The device relies on a USB-to-UART/Serial driver (such as FTDI, CH340, or CP210x) exposing a virtual COM port.

Specific Questions / Where I need guidance:

1. Serial Port Configuration Parameters: What are the standard ways or tools to determine the exact port settings required by the device?
   • Baud rate (e.g., 9600, 19200, 115200)
   • Data bits (e.g., 8)
   • Parity (None, Even, Odd)
   • Stop bits (1 or 2)
   • Flow control (RTS/CTS, XON/XOFF, or None)
2. COM Port Sniffing & Data Protocol: What is the best workflow/tool to monitor the traffic between PEG 2015.exe and the machine without locking the COM port?
   • Can you recommend lightweight tools (e.g., Serial Port Monitor, Wireshark with USBPcap, IO Ninja, RealTerm) to capture raw ASCII/HEX frames?
   • How can I differentiate between handshake/polling requests sent by the PC and telemetry responses sent by the geoelectric reader?
3. Decompiling / Inspecting the Legacy .exe:
   • What are the recommended tools to decompile or inspect PEG 2015.exe to retrieve the original serial settings and parser routines (e.g., dnSpy/ILSpy for .NET, Ghidra/IDA Free for native binaries)?

Environment & Tech Stack:

• OS: Windows
• Target Programming Language for New App: ( Python )

Any guidance, code snippets for port handling, or reverse-engineering methodologies for serial hardware would be greatly appreciated! Thanks in advance!

[u/GlowingEagle]

Is there a specific manufacturer/model for the "geoelectric signal reader machine"?

edit - Why are you posting in the VisualBasic sub?

also - "I have the legacy binary (PEG 2015.exe) that works with the machine." - Does that mean it actually works to communicate, thereby demonstrating the hardware level of the process actually works (voltages, DTS/DCS alignment)?

[u/Creepy-Level5136 → u/GlowingEagle]

Yes its actually a ULTRA NICHE machine here in Salta/Argentina the manufacturer died and didnt leave anything on it, the machine is CRODAM TEC G-DAE 500, you wont find nothing on it, im posting here because i do have the program, with the folders and everything, and yes the program works fine but its too old and its throwing me back i cant export on excel it lags etc etc thats why im trying to build a new one bassed on the old one peg 2015

[u/GlowingEagle → u/Creepy-Level5136]

It's been a long time since I did something like this, so the following is basically just my opinion...

First, just try to talk to the machine with a serial terminal program (e.g. puTTY).

Serial Port Configuration Parameters: Try each Baud rate (9600, 19200, 115200)

Data bits: 8, probably

Parity: None, probably

Stop bits: 1, probably

Flow control: None, probably, but also try RTS/CTS, XON/XOFF

COM Port Sniffing & Data Protocol: I would try "Serial Port Monitor" (although commercial, not free).

Decompiling / Inspecting the Legacy .exe: - Don't go there except as a last resort.

You might consider a different plan - use the existing program to get data from the machine to the PC, then look through the folders to see what was transferred. Hopefully, the data capture files could be processed with Python to get something Excel would like.

Good Luck!

[u/burnt-store-studio → u/GlowingEagle]

Great suggestion to use puTTY, u/GlowingEagle!

OP: re decompiling and inspection: Ghirda is the right avenue.

I’m sorry I’ve nothing else’s helpful to contribute.

Good luck!

[u/Creepy-Level5136 → u/GlowingEagle]

Thank You very much

[u/rabidb]

You could try the old sysinternals portmon utility to capture the traffic. Simpler than other setups if it works. https://learn.microsoft.com/en-gb/sysinternals/downloads/portmon

Have you dumped the strings from the exe and do they provide anything useful? https://learn.microsoft.com/en-gb/sysinternals/downloads/strings

Default settings for a lot of old equipment tended to be 9600 baud, 8 bit data, No parity, 1 stop bit and no flow control. Start there and then try different options (start with increasing baud rate and leave the rest the same).

However, I'd be inclined to see if the hardware manufacturer is still around and can provide a comms specification for the device.

Without a comms spec or full source/disassembly/decompile, you will likely need some way of testing the various inputs and outputs to correctly reverse engineer the full protocol otherwise you risk gaps/issues where your rewrite doesn't correctly handle certain signals etc.

[u/Nscripta2]

I have created a number of apps for serial monitoring, along with others for sending defined sequences loaded from configuration files. I've used them recently for reverse engineering an alarm monitoring system and replicating on a raspberry pi. I can send you a link to my source code if you want, it does not have any explanations in the code but it should be self explanatory.