Man-in-the-middle hack of RS232 data stream

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been down a couple of dead-ends trying to develop a work-around for a solar battery project. One option explored was to reflash the ATMEGA325PV within the system. This post refers -

 

https://www.avrfreaks.net/forum/a...

 

I'm back to exploring a MITM hack of the RS232 data stream and would be appreciative of any assistance.

 

To recap: The project consists of a Fronius Solar Battery that I have expanded beyond the manufacturers supported configuration. The most the Fronius supports is 8 battery modules behind the Battery Management System.

I have expanded that to two banks of 8 modules. The system switches alternately between the banks as they become full or empty. This works fine except that the inverter performs an unnecessary calibration charging cycle when it sees new battery serial numbers.

I wish to intercept the serial numbers in the RS232 stream (likely using a Raspberry Pi) and mask the serial numbers of the new battery modules that have been switched in.

 

What I have now is the data stream in an ASCII format (using a program called Termite). I can see repeating characters that would be expected from 8 modules that are all of a very similar state. But the data is effectively unintelligible gibberish.

I also have the JSON output from the inverter that reflects the incoming data.

 

So to summarise, I have the outbound serial data (in an unknown protocol), but I also have the values being sent by the serial data in a human readable JSON format.

 

I need to be able to recognise the serial numbers in the raw serial data before they get to the inverter.

 

Has anyone experience in making sense of a serial data stream with an unknown protocol?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It still all sounds like a Really Bad Idea to me!

 

Tim_C wrote:
the inverter performs an unnecessary (sic) calibration charging cycle when it sees new battery serial numbers.

Surely, it is entirely necessary?

 

The batteries are different, so the calibration will be different - so the inverter has to re-do its calibrarion.

 

The only way to get around that would be to modify the inverter to hold two sets of calibration data.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your input.

 

The calibration charge is unnecessary. I've discussed it with a Fronius subject matter expert. For commercial reasons, Fronius has decided not to offer an expansion option.

 

I'm on my own developing a bespoke solution.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tim_C wrote:

Has anyone experience in making sense of a serial data stream with an unknown protocol?

 

Yes. Get yourself a flask of coffee, a pad of paper, and a hex calculator.

 

The more different, but known good, data you can work with the better. There is no magic way to do this other than by inspection, and trial and error.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Gibberish data may be wrong baud, or inverted signal. Using a scope or logic analyzer may help view serial data, and determine baud, start bit .....

It all starts with a mental vision.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

Yes. Get yourself a flask of coffee, a pad of paper, and a hex calculator.

 

I've tried a little bit of that... but I'm very new to this field. Any guidance on what to look for and how to decipher the relationship is appreciated.

 

The Termite application only saves the data in ASCII format. In particular, there's a unique but reoccurring ASCII superscript character 'TM'. I suspect the ASCII characters are essentially meaningless, but their conversion back to binary represents the true underlying data. Or is that a flawed assumption?

 

As 'TM' is the only 14bit value that presents itself (the remainder are all single bytes), I'm pinning my hopes that somehow this is a good starting point. I've attached a sample of the data stream for info.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tim_C wrote:

The Termite application only saves the data in ASCII format.

 

Time to find something that'll do hex then.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:
Time to find something that'll do hex then.

Obviously!

 

However, since the whole point of the project is a "man-in-the-middle" - aka "drop-and-insert" - the OP must already have the capability in the project to capture the data stream.

 

In such a case, I would just add a feature in the device to spit everything out to a terminal in a "usable" format - and log that.

 

I find Excel[1] invaluable in this kind of exercise.

 

Just be careful to tell it that the data is Text - otherwise it's take hex strings containing only decimal digits as decimal numbers...

 

 

[1] other spreadsheet products are available.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A terminal program that only shows ascii is just about useless in this project, get a copy of RealTerm which can capture and display in multiple formats.

BTW, I would talk to the subject matter expert again and ask them what the protocol is!!!

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So to summarise, I have the outbound serial data (in an unknown protocol), but I also have the values being sent by the serial data in a human readable JSON format.

 

1. Look at the serial data in hex view (ascii is clearly worthless here)

2. Identify what could be start and stops of messages (an oscope may be useful here as the serial log could be too fast)

 

3. Take your known values, convert it back to hex, search for the bytes in either little or big endian form. 

4. Try and identify the patterns until you figure out the protocol

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FYI termite will display data in hex format, you just have to enable it in Termite's settings...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would normally use the Saleae Logic (clone) to decode the serial data. You get to see the timing as well. The clones are around $8-10usd from many inline suppliers. Note: the inputs are 5V only - don’t put it on rs233 levels. If you can probe the cpu pin, then you’re ok. It has 8 channels, so you can look at both rx and tx simultaneously.
A friend wanted to decode the rs485 comms on a solar water heater - no problems with the Logic. We could determine the baud rate, data in hex and timing. We decoded the protocol and knocked up some javascript to interpret it. Job done.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks all for the assistance. That's set me in the right direction....(hoping).

 

I'm sure I'll have more questions in the near term if I can't make any sense of it.