1

I have a legacy (20+ y.o) software that has been sunset by its creators. It performs serial port communication with a medical device. I am now in the process of looking into reverse "engineering" the communication and recreating it in a new piece of software.

I have been able to record the serial communication as it happens between the software and the device using Serial Port Monitor.

I can look at the legacy software's data table and see how the received data is stored there. My problem is that I can't make heads nor tail of the received data stream, and I have no previous experience with serial port communication, and thus wanted to see if the great collective of SO might help push me in the right direction (though at this point I have almost given up hope that this is anything as simple as decoding the data in the right way, and beginning to think I'd need the internal workings of the legacy software to be able to understand the stream).

Technical detail:

  • 9600 baud rate
  • 8 word length
  • 0 parity

Payload arrives in two different streams:

[17/05/2017 01:28:30] Written data (COM3) 
16 06 13 06 00 01 00 00 ca                        ........Ê  

[17/05/2017 01:28:30] Read data (COM3) 
16 06 13 06 00 02 00 72 0a a7 03 00 00 04 4b 7a   .......r.§....Kz 
00 70 78 42 00 00 00 00 00 00 00 0f 02 1d 07 e0   .pxB...........à 
04 1b 07 e1 00 9b 0b 1e 00 2e 8d 98 c6 0c 00 00   ...á.›....˜Æ... 
00 00 0b 1b 00 21 00 00 1e b1 1e ae 00 03 00 00   .....!...±.®.... 
61 39 00 00 02 c6 00 57 00 00 00 02 00 00 00 01   a9...Æ.W........ 
00 08 00 03 00 00 4e 4f 50 51 52 53 54 55 56 57   ......NOPQRSTUVW 
58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67   XYZ[\]^_`abcdefg 
68 69 6a 6b 6c 6d 6e 6f b0 71 51                  hijklmno°qQ      

[17/05/2017 01:28:30] Written data (COM3) 
16 06 13 06 04 01 00 00 c6                        ........Æ        

[17/05/2017 01:28:30] Read data (COM3) 
16 06 13 06 04 02 00 ce 00 03 08 1c 11 05 07 e1   .......Î.......á 
00 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00   .2.............. 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 
00 00 00 00 00 00 00 00 00 01 00 03 00 01 00 03   ................ 
00 00 00 00 00 00 00 00 00 32 00 06 00 06 00 08   .........2...... 
00 06 00 06 00 06 00 06 00 06 00 06 00 06 00 07   ................ 
00 07 00 06 00 08 00 07 00 06 00 06 00 00 00 00   ................ 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 
00 00 00 00 00 00 00 00 00 00 00 02 00 03 00 02   ................ 
00 03 00 00 00 00 00 00 00 00 00 2d 00 06 00 07   ...........-.... 
00 06 00 06 00 08 00 06 00 08 00 06 00 06 00 07   ................ 
00 06 00 06 00 06 00 06 00 06 00 06 00 06 00 00   ................ 
00 00 00 00 00 00 56                              ......V

The print out is from Serial Port Monitor, and I do realize that a lot of the control characters are simply set to a 'dot'. They though don't seem to give a clear picture of the what is going on either as far as I can tell.

Note that I have already communicated with the software and device manufacturers and to their credit they have attempted to help, but were unable to dig up any relevant information. I have also attempted to look into complements of the binaries but they make even less sense.

Any and all helpful tips, tricks or points would be appreciated at this point.

Edit:

For clarification; What I am hoping someone with knowledge about serial port communication might know of, and perhaps recognize the usage of, a common compression technique or encoding that I don't know off that might cause the stream to resolve into something matching the data set I can see in the legacy software. No code is being requested

Hrafn
  • 2,867
  • 3
  • 25
  • 44
  • That is some crazy task to crack for a purpose that is better achieved creatively. Write the code yourself. There are plenty of materials around. Starting from this, for example, "Serial Port (RS -232) Connection in C++" - http://stackoverflow.com/questions/15794422/serial-port-rs-232-connection-in-c – SChepurin May 18 '17 at 13:56
  • I can't really see how I can creatively solve the problem if I can't even understand the stream that I am receiving. And I guess you didn't fully grasp my question, since I am indeed writing the code my self. I am however looking for input on the data stream and what it's possible encoding (or other common serial communication data manipulation) might have been applied seeing as I can't seem to be able to match it up with the data output that the legacy software spits out. – Hrafn May 18 '17 at 14:12
  • 1
    What makes you think that "decoding the data in the right way" is necessarily simple?. Using a serial port monitor was an excellent move and it looks like you've successfully dealt with the serial port part of it. It looks like the only thing left (and, yes, it is a big thing) is the device's interface protocol. That's purely defined by the medical device. You're stuck with finding the docs or reverse engineering. You seem to be focused on characters and expecting ASCII chars. This looks more like a binary interface. You probably need to think raw numbers instead and don't forget endianess. – Avi Berger May 18 '17 at 14:25
  • You're right about it not being simple. Bad choice of words on my part. After exhausting my limited pool of knowledge I wanted to see if perhaps someone with more experience might be able to suggest something not obvious to my self. Indeed the thought had occurred to me that I might have to start running multiple slightly modified streams through, looking at the diff in them and matching that with the data table from the legacy software instead of hoping for a easy solution. – Hrafn May 18 '17 at 14:43
  • "I can't really see how I can creatively solve the problem if I can't even understand the stream that I am receiving." - I guess, everyone's first thought was- "You're stuck with finding the docs". Otherwise it seems even more crazy to solve the task of cracking some "black box" using someone's wild (or educative) guess. – SChepurin May 18 '17 at 14:57
  • Sounds like your thoughts are on track. Best & easiest is finding a copy of the devices docs. If you've already contacted the manufacturer, have you searched the net in case some may have posted them somewhere? Sometimes, with luck, inspiration, and aspirin, you can decipher things well enough - but with a medical device involved, you need to be extra cautious. I once created a major bug with a minor bug fix to legacy PC code in a similar, but non-medical & non-critical, situation. "Bug fix" got backed out & comment added to PC code warning not to try that obvious fix. – Avi Berger May 18 '17 at 15:36

1 Answers1

1

Like everyone else said this is a guess work and it is a binary protocol, only the original comms protocol will tell you exact details.

All you could figure out from the data above is that

  • There are some header bytes : 16 06 13 06
  • Then some command bytes : 00 01 or 04 01
  • Followed by some data : '00 00' or '00 .... 00 '
  • Followed by 8 bit CRC with 2's complement at the last byte: CA
Jegan
  • 1,227
  • 9
  • 16
  • I think you're right. Another route will have to be taken. – Hrafn May 23 '17 at 10:06
  • Turns out all these things were correct. By mocking up the medical device, and running that plus the legacy software inside a virtual machine with virtual serial ports connecting the mock and the legacy together I was able to figure out what the binary protocol was. We can now throw the old system out for a new one. – Hrafn Jun 06 '17 at 16:09