Author Topic: Reverse Engineering by Serial Bus Analysis  (Read 6195 times)

0 Members and 1 Guest are viewing this topic.

Offline _Sinusoidal

  • Contributor
  • Posts: 17
  • Country: ca
  • EE Student
Reverse Engineering by Serial Bus Analysis
« on: February 06, 2016, 07:59:14 am »
Hey guys,

I'm currently scratching my head after doing some probing on a serial bus that I'm trying to hack. There is a button controlled user interface that communicates to a motor controller unit via 4 wires that I have determined to likely be: ~+7V, DATA, Chip Select, and GND.

Sorry in advance for the horrible screen capture, I had to use my phone as I apparently lost my USB stick.



When the user interface is in power-down or sleep mode, the yellow signal is held high at a constant voltage around 7V. When a button is pressed, the interface turns on and the yellow signal starts oscillating at 1kHz as seen in the photo above. The pink signal goes high and is held high until the device goes to sleep. The blue signal, DATA, looks like a typical serial binary protocol with a logic level of 0-~11V. It is only active when the user interface is awake.

I have a few questions about what is going on here. First, why would the power line be oscillating like that? I can't think of what function it could serve between a user interface and a motor control unit. Pressing buttons on the interface does not change the frequency of the oscillations. Second, I'm assuming that this serial interface is just a one-wire interface, because there is no clock signal. I have never seen a one-wire serial interface that operates at ~11V, has anyone here ever come across something like that before? The data line is likely bi-directional, because the motor control unit is capable of sending error codes back to be displayed on the UI. Also, why on earth would the data line be operating at a higher voltage than the power supply line?

My end goal is to be able to replace the user interface with an Arduino to implement my own control system. I'll have to decode the serial protocol and write my own library to serve as a functional replacement, as well as include the appropriate logic level translators between the arduino and higher voltage serial bus.

Just throwing this post out there in hopes that someone could give me some ideas on how this works. Thanks!
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 11474
  • Country: 00
Re: Reverse Engineering by Serial Bus Analysis
« Reply #1 on: February 06, 2016, 11:24:46 am »
I have a few questions about what is going on here. First, why would the power line be oscillating like that? I can't think of what function it could serve between a user interface and a motor control unit. Pressing buttons on the interface does not change the frequency of the oscillations.

Doesn't make much sense. Are you sure it's a "power" line?

Second, I'm assuming that this serial interface is just a one-wire interface, because there is no clock signal.

Looks like RS232 to me. RS232 is inverted so it goes low for a '1' bit. Turn on your RS232 decoder and have a look. The small groups will be a single byte so you can look for a single bit in there and figure out the baud rate from your time base.

I have never seen a one-wire serial interface that operates at ~11V,
Real RS323 is +/- 12V.
 

Offline lovemb

  • Contributor
  • Posts: 19
  • Country: pt
Re: Reverse Engineering by Serial Bus Analysis
« Reply #2 on: February 06, 2016, 02:48:04 pm »
"one-wire serial interface that operates at ~11V":
Sounds like you are probing: ISO 9141-2
--blue most-likely is K-Line (probably at 9600bps or 10400 if kwp2000)
--pink could be L-Line

Btw, my device of choice to interface with ISO 9141 is L9637D, use it in all my projects. You can directly connect to your arduino and the only external component needed is 510ohms resistor or bit higher.
 

Offline _Sinusoidal

  • Contributor
  • Posts: 17
  • Country: ca
  • EE Student
Re: Reverse Engineering by Serial Bus Analysis
« Reply #3 on: February 06, 2016, 06:01:30 pm »
Doesn't make much sense. Are you sure it's a "power" line?

I'm not sure what other purpose it could serve. I figured that it might be used to power a microcontroller in the UI. Now I'm starting to suspect that the microcontroller is powered by the pink line, and it is only turned on when pressing a button on the UI pulls the yellow signal low and starts the wake-up:



Looks like RS232 to me. RS232 is inverted so it goes low for a '1' bit. Turn on your RS232 decoder and have a look. The small groups will be a single byte so you can look for a single bit in there and figure out the baud rate from your time base.

I believe you are right, it is quite likely RS232. I'm still moderately new to embedded electronics, so I have yet to see all the protocols and standards.

"one-wire serial interface that operates at ~11V":
Sounds like you are probing: ISO 9141-2
--blue most-likely is K-Line (probably at 9600bps or 10400 if kwp2000)
--pink could be L-Line

Btw, my device of choice to interface with ISO 9141 is L9637D, use it in all my projects. You can directly connect to your arduino and the only external component needed is 510ohms resistor or bit higher.

I measured the baud rate and it turned out to be 19200, which is out of the ISO 9141 spec. So I'll have to do some decoding and figure out the protocol.



Anyone have any thoughts on what could be going on with the yellow signal? It seems to have a double duration pulse every 100ms. I have no idea why it is oscillating at 1kHz.

 

Offline uncle_bob

  • Supporter
  • ****
  • Posts: 2437
  • Country: us
Re: Reverse Engineering by Serial Bus Analysis
« Reply #4 on: February 06, 2016, 06:11:32 pm »


Anyone have any thoughts on what could be going on with the yellow signal? It seems to have a double duration pulse every 100ms. I have no idea why it is oscillating at 1kHz.


Hi

Well, a signal going low every milisecond sounds like a clock signal. It could have absolutely no relation at all to the data you are looking at. Since the data is 19.2 serial, it's a pretty good bet. It also could be a keep alive signal.

Since there is no (apparent) information there, you can't look at the signal alone and determine it's purpose. You will have to get into the code to figure out what it does.

Bob
 

Offline _Sinusoidal

  • Contributor
  • Posts: 17
  • Country: ca
  • EE Student
Re: Reverse Engineering by Serial Bus Analysis
« Reply #5 on: February 06, 2016, 06:36:00 pm »
Hi

Well, a signal going low every milisecond sounds like a clock signal. It could have absolutely no relation at all to the data you are looking at. Since the data is 19.2 serial, it's a pretty good bet. It also could be a keep alive signal.

Since there is no (apparent) information there, you can't look at the signal alone and determine it's purpose. You will have to get into the code to figure out what it does.

Bob

Bob, I believe you are right about it being a keep alive signal. Just from looking at it, it seems like the motor control unit is supplying the 1kHz signal and the UI microcontroller holds the line high for a short duration every 100 ms to let it know that it is still there. From this snapshot, it can be seen that the microcontroller does an extra pulse ~50ms after its last pulse to indicate that it is preparing to go to sleep:

 

Offline uncle_bob

  • Supporter
  • ****
  • Posts: 2437
  • Country: us
Re: Reverse Engineering by Serial Bus Analysis
« Reply #6 on: February 06, 2016, 06:55:35 pm »
Hi

Ok, so not "no information", just very little information. One way to verify things would be to nuke the signal and see what happens.

Bob
 

Offline _Sinusoidal

  • Contributor
  • Posts: 17
  • Country: ca
  • EE Student
Re: Reverse Engineering by Serial Bus Analysis
« Reply #7 on: February 06, 2016, 11:45:07 pm »
Currently I am focusing on identifying the serial interface being used here, as it seems that it isn't actually RS232. I am not able to disassemble the devices, just sniff the serial connection between them. It seems to me that there is only 1 DATA line and a GND being used. However, 1-Wire or MicroLan uses <5V logic signals. This interface on the other hand, uses a 0-12V signal (not +/- 12V like RS232). It has me completely stumped on what it could be. Without knowing what serial protocol is being used I have no way of decoding the data.
 

Offline lovemb

  • Contributor
  • Posts: 19
  • Country: pt
Re: Reverse Engineering by Serial Bus Analysis
« Reply #8 on: February 07, 2016, 02:32:28 am »
You know the baudrate and you know the signal level, why do you say you cannot decode the serial?

I would have already put L9637D on there and sniff all of that. Or since you just want to sniff/receive at this moment, a simple logic level converter will do.
 

Offline _Sinusoidal

  • Contributor
  • Posts: 17
  • Country: ca
  • EE Student
Re: Reverse Engineering by Serial Bus Analysis
« Reply #9 on: February 07, 2016, 05:02:32 am »
You know the baudrate and you know the signal level, why do you say you cannot decode the serial?

I would have already put L9637D on there and sniff all of that. Or since you just want to sniff/receive at this moment, a simple logic level converter will do.

I can't decode the serial because I have no idea what packet format is being used. It does not seem to be the standard 8N1. I cant find an instance that it only sends 1 packet at once, so I have no clue about parity bits, stop bits, and data size.
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 476
  • Country: ru
Re: Reverse Engineering by Serial Bus Analysis
« Reply #10 on: February 07, 2016, 07:54:26 am »
Try decoding the bursts to 0/1 sequences, count the bits - are they in multiples of 8 or something other?
Anyway, in the worst case you can record all nessesary commands from existing UI, then just replay them.
 

Offline uncle_bob

  • Supporter
  • ****
  • Posts: 2437
  • Country: us
Re: Reverse Engineering by Serial Bus Analysis
« Reply #11 on: February 08, 2016, 06:11:19 pm »


I can't decode the serial because I have no idea what packet format is being used. It does not seem to be the standard 8N1. I cant find an instance that it only sends 1 packet at once, so I have no clue about parity bits, stop bits, and data size.

Hi

There is no guarantee that serial would be ASCII. In a lot of devices, 8 bit binary data is what is transferred. If you go in looking for characters, a binary data stream will always look like nonsense.

So back to basics:

There *must* be something that indicates when a block of data starts. The end could simply be "hey, 39 bits have gone by". The start could be "pull the line low for 4 bit times".  Find the narrowest pulse on the line and *assume* that is the bit width. Digitize everything for that bit width in your search. Capture a *lot* of data and start looking for patterns. Expect that there will be multiple correlations in the data. The next step will be to make assumptions (guesses) and sort them out.

Bob
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf